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

David DeSimone fox at verio.net
Wed Jul 28 19:30:02 UTC 2010


It's all about layers of defense, and whether the reduced convenience is
worthwhile.

Limiting outbound traffic from your system is a hassle, but I like to
think about this scenario:

Suppose an attacker did manage to find an exploitable method on your
system, and was able to open up a shell.  What would they try to do?  I
think a common next step is for the attacker to download his "bag of
tools" onto the system and to try to exploit further, or make himself at
home.  If your outbound policy blocks him from being able to download
his rootkit or exploit tools, you may very well stop him from getting
any further into your system.


Spenst, Aleksej <Aleksej.Spenst at harman.com> wrote:
>
> 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.

-- 
David DeSimone == Network Admin == fox at verio.net
  "I don't like spinach, and I'm glad I don't, because if I
   liked it I'd eat it, and I just hate it." -- Clarence Darrow


This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free.  Thank you.


More information about the freebsd-pf mailing list