On Wed, Jul 28, 2010 at 2:55 PM, Spenst, Aleksej <aleksej.spe...@harman.com> 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. >
Outgoing ports aren't really used as an attack on that system, but as a jump-point to other systems. Say server A allows all outbound traffic. Server B, with sensitive data on it, blocks all inbound access from the Internet but does allow connections from the network where server A is located. Someone hacks server A, and now they have a route to attack server B they didn't have before. Ideally, limiting outgoing traffic to only intended hosts and/or ports is preferred from a security perspective, but you also have to frame it in the context of what the system will be doing. If you have a good knowledge of what the system needs for both inbound and outbound connectivity, it would probably be a good idea to restrict access both ways. I say probably because if the system's outbound traffic profile is intended to change, requiring changes to the firewall ruleset on a regular basis, it wouldn't make much sense. If you know there's outbound traffic you definitely don't need, blocking it isn't a bad idea. For a system with only public IP addresses, denying traffic to RFC1918 space is a good example. -Proto _______________________________________________ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
