For better security: always "block all" or "block in all" is enough?

[Jon Radel]

On 7/28/10 2:55 PM, Spenst, Aleksej wrote:
> Hi All,
>
> I have to provide for my system better security and I guess it would be better to start pf.conf with the "block all" rule opening afterwards only those incoming and outcoming ports that are supposed to be used by the system on external interfaces. However, it would be easier for me to write all pf rules if I start pf.conf with "block in all", i.e. if I block only traffic coming in from the outside and open all ports for outgoing traffic.
>
> - Incoming ports: only udp/68 (for dhcp client) and http/80 (for http server) always open;
> - Outgoing ports: all ports always opened. All traffic going outside from the system has "keep state";
>
> What disadvantages does it have in term of security in comparison with "block all"? In other words, how bad it is to have all outgoing ports always opened and whether someone can use this to hack the sysem?
>
> Thanks a lot for any tips!!
> Aleksej.
>
>    
The only real answer is:  It depends.  :-)

One example of outbound blocking that some find useful:  Block all 
outbound traffic to port 25 that comes from any machine other than 
authorized e-mail servers.  On one network I deal in, this makes sense, 
as the various Windows workstations have no business sending mail to 
anything other than the internal mail servers, and if they try there's a 
good chance it's a trojan of some sort doing the sending.  Obviously, 
there are other networks where this would make no sense.

In a general sort of way, allowing outbound traffic doesn't expose you 
to attacks, but it makes your machine more valuable to an attacker who 
does succeed.  For example, if you allow outbound ssh and telnet, etc., 
etc., it makes it easier to use your machine to stage attacks on other 
machines.  On the other hand, if the firewall is on the server in 
question, rather than being another piece of equipment, anybody who has 
root can rearrange your firewall for you....

-- 

--Jon Radel
jon at radel.com