I believe the receiving system will send back an error notice. This tells
the attacker that the system exists and possibly what type of device it is.
>From there the attacker can try more specific probes and attacks.
Thanks-
-Craig
-----Original Message-----
From: Jim Johnson [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, April 18, 2000 8:42 AM
To: '[EMAIL PROTECTED]'
Subject: Why is a forged ACK bit packet bad? (was Re: Packet Filtering
vs. Proxy)
If I understand the below email correctly, it's saying that if you forge a
packet with the ACK bit set it will get by the packet filter. The only way
to prevent this is by using a stateful packet filter that "remembers"
connections. I understand all of this ok, but what I don't understand is
why letting a packet with a forged ACK bit through is such a bad thing.
According to the book "Building Internet Firewalls" (published by Oreilly)
it says in the last paragraph on page 188 that a packet with a forged ACK
bit isn't a problem. To quote them, here's the last paragraph:
"Why can't an attacker get around this by simply setting the ACK bit on the
first packet? If he does, the packet will get past the filters, but the
destination will believe the packet belongs to an existing connection
(instead of the one with which the packet is trying to establish a new
connection). When the destination tries to match the packet up with the
supposed existing connection, it will fail because there isn't one, and the
packet will be ignored."
So can someone tell me what the problem is with letting a packet that
contains a forged ACK bit in?
>Date: 13 Apr 2000 15:43:46 -0000
>From: [EMAIL PROTECTED] (Lorens Kockum)
>Subject: Re: Packet Filtering vs. Proxy
>
>On the GNAC firewall list [EMAIL PROTECTED] wrote:
> >At 05:44 PM 4/13/00 +0930, you wrote:
> >
> >>Strictly speaking, a stateful packet filter only keeps state (duh). This
> >>means that an SPF is supposed to know everything about the TCP/IP rules
> >>for the flow of data between the internal and external hosts.
> >
> >What then, is "state"? By your message, I don't see the difference
between
>
> >this and a "normal" packet filter.
>
>A normal packet filter will allow an established TCP packet from
>the bad outside to the feeble inside even if there never was a
>connection opened from the inside.
>
>I.E. on a non-stateful Cisco, neglecting antispoofing, in order
>to permit only outgoing web and dns requests, you write:
>
>inside -> outside
>
> permit tcp any any eq 80
> permit udp any any eq 53
>
>outside -> inside
>
> permit tcp any eq 80 any established
> permit tcp any eq 53 any
>
>This permits any outsider to forge incoming packets, using his
>own IP, without the need to listen to your traffic. He can
>send spoofed established packets to any machine that can do
>outgoing http providing he sets his source port to 80, and he
>can initiate an UDP conversation with any machine that can do
>outbound DNS providing he sets his source port to 53.
>
>First line of defense is to decree that services are located on
>ports <1024 and requests should come from >=1024. That actually
>helps a lot. It still has gaping holes, of course.
>
>On a stateful filtering device such as a Cisco IOS with stateful
>filtering, a PIX, an ipfilter, etc., you are able to completely
>squeeze the second access list (you may have to specify in the
>firstzt that return communications are accepted, but that's
>minor).
>
>Not only the filter lists are easier to read, but people who
>are not contacted by you cannot initatiate communications
>with you by pretending to be part of an already established
>communication, because the filtering device keeps a constantly
>updated list (state) about who is talking to whom.
>
>Hope I was clear enough, HTH.
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
