Quoting Johnny Hughes <mailing-lists@xxxxxxxxxxxx>:
> 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.
