Quoting Johnny Hughes mailing-lists@hughesjr.com:

On Wed, 2005-11-30 at 21:16 +0900, Mark Sargent wrote:

...

whilst not being an expert on iptables, the below ouput of iptables -L seems too insecure to me. Does anyone agree.? Perhaps I'm not understanding it as well as I think I am.? Please give your thoughts on this. Cheers.

Mark, I don't find it particullary secure. It is way better than no firewall at all, however it is too open for my taste.

Does it not block everything inbound except connections you initiate and the couple things that they included by default?

ACCEPT icmp -- anywhere anywhere icmp any ACCEPT ipv6-crypt-- anywhere anywhere ACCEPT ipv6-auth-- anywhere anywhere ACCEPT udp -- anywhere 224.0.0.251 udp dpt:5353 ACCEPT udp -- anywhere anywhere udp dpt:ipp

Johnny (and Mark too), there is couple of problems here.

First of all, when you allow something using Red Hat supplied tools, you are allowing it from *everywhere*. For some services it is what you wanted (example, some web and mail servers). For some (like Cups) you usually only want to allow your internal network, not entire known world (including international space station).

Any bug in cups, and your system might get compromised. Any bug in IPSec implementation and your system might get compromised (the ipv6-auth and ipv6-crypt are actually AH and ESP protocols for IPSec, so they are valid protocols in IPv4 world too). The multicast DNS thingie is not that much of an issue (most systems don't run service on that port, they just act like an client, but still).

The default config uses same set of rules for both INPUT and FORWARD chains. That's just braindead. You allow SSH into your firewall for example, and you allowed forwarding of it into your network too.

There's that dreaded "RELATED" rule. It allows any connection that might look like related to any existing connection. To exploit it, a bit of social engineering might be needed (or sometimes not, depending on actuall configuration). Some Netfilter modules were known for stamping as related almost everything (or at least way too much). What you really want to do is accept related ICMP packets (if you want to be really tight, only subset that is actually used for connection signaling) and than have rules for other related packets that match specific module. For example, the correct way to allow active FTP data connection, you would allow packet in only if it is sent from port 20 (-p tcp --sport 20), *and* it is connection to high port (preferrably in 49152-65534 range, although some broken FTP servers use entire 1024-65534 range, but definettely high port) (--dport 49152:65534) *and* related to existing FTP control channel (-m state --state RELATED) *and* it was marked as related by ftp helper module (-m helper --helper ftp). You really don't want to allow it if it gets marked as related by IRC helper module for example. Connection from port 20 that gets marked as related by anything other than ftp helper module, or to some low port (22 for example) is 100% ill-intended.

I could probably go on and on and on...

To make this long story shorter, I'll go to the point. Either write your rules yourself (don't use system supplied firewall config tool). Or use some 3rd party program if you are not really confident in this area. There's many around that do much better job than what you get by default with the distribution (like fwbuilder for example). Or send me a nice check that matches $[1-9][0-9]{2,} regex, and I'll write them for you ;-) (just kidding)

I just hope Red Hat is going to ditch the simplistic firewall tool they have in favour of something better.

---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

Kai Schaetzl wrote:

Aleksandar Milivojevic wrote on Wed, 30 Nov 2005 09:16:34 -0600:

...

marked as related by ftp helper module (-m helper --helper ftp).

Is that "helper" identical with the ip_conntrack_ftp module or is this something different?

"Helper" option means that particular helper module marked the packet as related. In this case that module would be ip_conntrack_ftp indeed. Note that the option does not trigger loading of the module. It simply checks what placed packet into related state.

Mark Sargent wrote on Thu, 01 Dec 2005 15:35:37 +0900:

CLASS_D_MULTICAST="224.0.0.0/4" CLASS_E_RESERVED_NET="240.0.0.0/4"

I do have 5 for the latter in my rules. I didn't invent them, though ;-)

Kai