Date: Tue, 30 Oct 2001 20:15:57 +0100 (CET) From: Krzysztof Zaraska <kzaraska@student.uci.agh.edu.pl> To: Ralph Huntington <rjh@mohawk.net> Cc: Michael Scheidell <scheidell@fdma.com>, freebsd-security@FreeBSD.ORG Subject: Re: can I use keep-state for icmp rules? Message-ID: <Pine.BSF.4.21.0110301848550.454-100000@lhotse.zaraska.dhs.org> In-Reply-To: <20011030102625.U73979-100000@mohegan.mohawk.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 30 Oct 2001, Ralph Huntington wrote:
> > > ipfw(8) doesn't know anything about TCP handshakes. You may be under
> > > the impression that ipfw(8) actually tracks the state of TCP
> > > connections. It doesn't really. The flags in TCP packets can affect
> > > the lifetime of the rule, but it doesn't really track the state.
> >
> > You mean if I send email to your system, you can immediatly connect to
> > my internal tcp ports that might not normally have external access
> > available?
>
> ipfw does not really track the state, but ipfilter (ipf) does. My
> understanding (please correct me if I'm wrong!) is that ipfw could be
> fooled by incoming packets spoofing the state of the connection, whereas
> ipf keeps its own table and relies on that instead of the incoming
> packets' assertions. -=r=-
Both ipf and ipfw can do both stateful and stateless inspection, however,
stateful inspection in ipf is more advanced. Nevertheless is you are not
planning to have a very advanced firewall ipfw is enough.
As of "fooling" the firewall with incoming packets: yes this is possible,
although the impact is limited. ipf has internal TCP state table, but
_may_ be forced to rely on packet's TCP flags. ipfw relies on packet's
flags, but this doesn't imply the situation as one poster suggested -- "if
you connect to me to send me e-mail, you may connect to any my port".
"Standard" ipfw setup contains:
(1) add pass tcp from any to any established
(2) add pass tcp from any to ${oip} 25 setup
According to 'man ipfw':
'established' matches packet with ACK (or RST) flag set
'setup' matched packet with _only_ SYN flag set
Please note that this is a non-statefull behavior -- no "keep-state"!
Establishing TCP connection involves the following handshake procedure:
i) client sends SYN packet
ii) server replies with SYN|ACK
iii) client replies with ACK
All subsequent packets carrying data for the connection have the ACK flag
set.
Rule (1) matches all packets except for the initial SYN, which is
controlled by rule (2).
As you can see, this provides effective control of incoming
connections: by dropping or not the initial SYN packet with rule (2) we
decide whether the handshake succeeds or not.
This arises question: can attacker "fool" the firewall by sending us ACK
packet without preceding SYN packet? Yes.
However, if our TCP stack receives an ACK packet (stage iii and later
above) which is not the part of an existing connection (= a connection
which handshake had been successfully completed before) it will reply
with RST packet regardless of the state of the port (opened or closed).
So although she may hit us with ACK packets (so-called ACK scan) she will
not succeed in connecting to any service. She may, however, gather some
knowledge regarding the fact that host is alive, what OS are we
running (by analizing the RST packet, or "passive fingerprinting" though
this method is inaccurate), and that our firewall blocks incoming
SYNs. IMVHO, however, this information is of value only to a quite skilled
attacker.
It seems to me that this attack may be prevented by dropping rule(1) and
combining setup with keep-state in rule (2).
I'll deal with the subject now.
The problem with ICMP is that there's no 'state'; actually there's no
connection at all. One side sends a packet, the other relies. No
handshaking, no acknowledgements, nothing. There are even no port numbers.
What we (for example) want is to be able is to ping (=send ICMP ECHO
REQUEST to) other hosts and see the results (=get back ICMP ECHO REPLY).
If we do
ipfw add pass icmp from ourip to any keep-state
and ping target.host.com then according to the manual (unfortunately I
can't do testing right now) we'll end up with dynamic rule matching _any_
ICMP packet from target.host.com to us. This would make sense (we may
expect not only ICMP ECHO RESPONSE, but also ICMP HOST UNREACHABLE, for
example) but will also allow target.host.com to ping us until the rule
expires. This is something we may not like.
Fortunately, there's something nice about ipfw: we may filter basing on
ICMP type. Furthermore, every host on the internet is required not to send
response to an ICMP packet that is not a request (e.g. host may respond to
ICMP ECHO REQUEST, but is NOT allowed to reply to ICMP ECHO REPLY or ICMP
HOST UNREACHABLE). Therefore, if attacker "pings" a host with say, ICMP
ECHO REPLY's she won't get anything back. So all you need to do is use
this knowledge: pass these ICMP types that you consider useful and
harmless and block those you don't like (mainly all request types).
Hope this helps. All comments welcome.
Krzysztof
P.S. I feel there's a need for throwing together a small FAQ or whatever
regarding these aspects of ipfw. What do you think?
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0110301848550.454-100000>