sequence number rewrite
Noah Davids
a connection.
I have traces from both sides of a connection going between 2 systems 5
hops apart. The packets have the same IP addresses, ports, IP ID values,
packet length, and data. The one thing that is different are the
sequence numbers. Each side sees a consistent set of sequence numbers so
the connection progresses without problems but the sequence numbers are
completely different at each host.
It is almost as if there is a proxy between the two but I would expect a
proxy to rewrite the ID values and possibly at least one of the IP
addresses and port numbers.
Any suggestions would be appreciated.
Pascal Hambourg
Noah Davids a ï¿œcrit :
> Can anyone suggest what type of device would rewrite sequence numbers in
> a connection.
Stateful firewalls and NAT devices.
Noah Davids
are unchanged it didn't seem likely. Are you suggesting that a NAT
device might not rewrite addresses and port numbers?
As far as a stateful firewall, I thought of that as well but I couldn't
think of a reason why it would bother to rewrite the sequence numbers
but leave everything else unchanged. Is there a reason?
Pascal Hambourg
>>
>> Noah Davids a ï¿œcrit :
>>> Can anyone suggest what type of device would rewrite sequence numbers in
>>> a connection.
>>
>> Stateful firewalls and NAT devices.
>
> I thought of a NAT device but since the IP addresses and port numbers
> are unchanged it didn't seem likely. Are you suggesting that a NAT
> device might not rewrite addresses and port numbers?
I was just making a general answer. Actually the only reason I can see
for a NAT device to rewrite sequence numbers is when the NAT operation
changes the length of some segments. One example is when the IP address
transmitted in the payload of an FTP control connection is translated
and the length of its ASCII decimal representation changes.
> As far as a stateful firewall, I thought of that as well but I couldn't
> think of a reason why it would bother to rewrite the sequence numbers
> but leave everything else unchanged. Is there a reason?
There is at least one. Some (presumably older) TCP/IP stacks are known
to have an ISN (initial sequence number) generator with poor randomness
that is predictable and could be taken advantage of in some attack
scenarios. Rewriting the sequence numbers with better randomness helps
protecting devices using these stacks from such attacks.
Jorgen Grahn
> Pascal Hambourg wrote:
>> Hello,
>>
Don't know ... Whatever it is, it is stateful, and spends a lot of
resources on this. Your data must be valuable to this third party
somehow ...
Does this happen on "popular" ports only, or on any TCP ports?
(I assume you are not simply misinterpreting the snooped traffic?
Tcpdump/Wireshark/etc often try to be user-friendly by showing the
sequence numbers as if they started on 0.)
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Rick Jones
> Can anyone suggest what type of device would rewrite sequence
> numbers in a connection.
In my opinion, only one that was fundamentally broken, either in
implementation, or design.
rick jones
--
oxymoron n, Hummer H2 with California Save Our Coasts and Oceans plates
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
Philip Paeps
> On Tue, 2009-11-03, Rick Jones wrote:
>> Noah Davids <nd...@cox.net> wrote:
>>> Can anyone suggest what type of device would rewrite sequence
>>> numbers in a connection.
>>
>> In my opinion, only one that was fundamentally broken, either in
>> implementation, or design.
>
Or configuration. :-)
I can imagine a NAT setup with application level "helpers" which are being
helpful even when not needed. For some reason (design, implementation,
purpose or configuration, take your pick) packets are going through the slow
path and being rewritten, rather than through the fast path left alone.
- Philip
--
Philip Paeps Please don't email any replies
phi...@paeps.cx I follow the newsgroup.
Real programmers are secure enough to write readable code,
which they then self-righteously refuse to explain.
Noah Davids
The ports that this was first notice on where not your typical ports. I
was trying to match up packets from both sides of the network to
understand a performance issue. As I test I tried a connection to the
echo port and saw the same behavior starting with the initial SYN packet.
I think I found the performance problem but now I need to figure out why
and what.
Jorgen Grahn
> Jorgen Grahn wrote:
>> On Tue, 2009-11-03, Noah Davids wrote:
>>> Pascal Hambourg wrote:
>>>> Hello,
>>>>
>>>> Noah Davids a �crit :
>>>>> Can anyone suggest what type of device would rewrite sequence numbers in
>>>>> a connection.
>>>> Stateful firewalls and NAT devices.
>>> I thought of a NAT device but since the IP addresses and port numbers
>>> are unchanged it didn't seem likely. Are you suggesting that a NAT
>>> device might not rewrite addresses and port numbers?
>>>
>>> As far as a stateful firewall, I thought of that as well but I couldn't
>>> think of a reason why it would bother to rewrite the sequence numbers
>>> but leave everything else unchanged. Is there a reason?
>>
>> Don't know ... Whatever it is, it is stateful, and spends a lot of
>> resources on this. Your data must be valuable to this third party
>> somehow ...
>>
>> Does this happen on "popular" ports only, or on any TCP ports?
...
> The ports that this was first notice on where not your typical ports. I
> was trying to match up packets from both sides of the network to
> understand a performance issue. As I test I tried a connection to the
> echo port and saw the same behavior starting with the initial SYN packet.
So you haven't tried any of the "popular" ports? I guess I mean HTTP.
I can imagine evil men-in-the-middle to mess with HTTP only
(transparent-proxy-something), or with everything *but* HTTP (punish
people who use IP for more than "surfing the web").
I suppose this means your TCP connections also get broken if they stay
silent for more than N seconds. They must have some kind of timeout
so they don't run out of memory.
Martijn Lievaart
Any firewall that tries to handle SYN floods by spoofing the connection
until the three way handshake is complete. Firewall-1 does this for
instance and I suspect others as well.
HTH,
M4
Rick Jones
> Any firewall that tries to handle SYN floods by spoofing the connection
> until the three way handshake is complete. Firewall-1 does this for
> instance and I suspect others as well.
Each passing day I learn something new that only serves to increase my
amazement that "The Internet" continues to function.
rick jones
--
No need to believe in either side, or any side. There is no cause.
There's only yourself. The belief is in your own precision. - Joubert
Noah Davids
Good point - thank you.
Noah Davids
We haven't noticed a timeout problem.
Rick Jones
> Any firewall that tries to handle SYN floods by spoofing the
> connection until the three way handshake is complete. Firewall-1
> does this for instance and I suspect others as well.
Isn't that somewhat borrowing from Peter to pay Paul? I would think
that space for "state" would be even more limited in a firewall than
it would be in the host(s) behind it.
rick jones
--
web2.0 n, the dot.com reunion tour...
Char Jackson
<m...@rtij.nl.invlalid> wrote:
>Any firewall that tries to handle SYN floods by spoofing the connection
>until the three way handshake is complete. Firewall-1 does this for
>instance and I suspect others as well.
F5 BigIP load balancers do the same thing. Enabling syn flood
protection means new connections are spoofed, (they call it proxying),
until the three way handshake is complete. After a configurable amount
of time or when the buffer reaches a certain point of utilization,
whichever comes first, old syn's without ack's are purged.
I'm in favor of filtering this stuff out sooner rather than later, so
I'm in favor of doing it in a centralized network device such as a
firewall or load balancer rather than allowing the bogus traffic to
reach the individual hosts.
Rick Jones
I see a huge gulf separating dropping a SYN early and an intermediate
device pretending to be the end destination.
rick jones
--
Wisdom Teeth are impacted, people are affected by the effects of events.
Char Jackson
<rick....@hp.com> wrote:
>Char Jackson <no...@none.invalid> wrote:
>> On Wed, 4 Nov 2009 19:25:36 +0100, Martijn Lievaart
>> <m...@rtij.nl.invlalid> wrote:
>
>> >Any firewall that tries to handle SYN floods by spoofing the connection
>> >until the three way handshake is complete. Firewall-1 does this for
>> >instance and I suspect others as well.
>
>> F5 BigIP load balancers do the same thing. Enabling syn flood
>> protection means new connections are spoofed, (they call it
>> proxying), until the three way handshake is complete. After a
>> configurable amount of time or when the buffer reaches a certain
>> point of utilization, whichever comes first, old syn's without ack's
>> are purged.
>
>> I'm in favor of filtering this stuff out sooner rather than later,
>> so I'm in favor of doing it in a centralized network device such as
>> a firewall or load balancer rather than allowing the bogus traffic
>> to reach the individual hosts.
>
>I see a huge gulf separating dropping a SYN early and an intermediate
>device pretending to be the end destination.
I'm not sure I see any easy way to separate the two, or even whether
it's beneficial to separate the two. Do you propose setting a limit,
whether arbitrary or adaptive, on the number of SYN packets you'd
allow through, and any beyond that limit would be dropped? If so, that
might help with this specific DOS attack, but a distributed attack
would be allowed through. I'm not trying to be argumentative, I'm just
trying to see more sides of this and expand my knowledge.
Martijn Lievaart
> Martijn Lievaart <m...@rtij.nl.invlalid> wrote:
>> Any firewall that tries to handle SYN floods by spoofing the connection
>> until the three way handshake is complete. Firewall-1 does this for
>> instance and I suspect others as well.
>
> Isn't that somewhat borrowing from Peter to pay Paul? I would think
> that space for "state" would be even more limited in a firewall than it
> would be in the host(s) behind it.
I haven't completely made up my mind about it. As you note, it's not a
matter of space I think, most current devices probably can handle lots of
half open connections. Especially those firewalls, they were designed for
it, but most device stacks probably can handle lots as well. When this
feature was designed however, many tcp/ip implementations would buckle
under a Syn attack so then it did make sense.
On the plus side, the firewall gives a single point of defense that
behaves predictably for all devices it defends. And it gives you a
defense for devices that do not behave well under a SYN attack.
On the minus side. First, I don't trust most firewall vendors to get even
the most basic stuff right[1][2][3]. Second, I think (but am not sure)
most devices you would want to protect may actually handle Syn attacks
even better.
On the whole, I would not enable it unless under attack to see if that
would give temporary relief.
M4
[1] I've encountered a "professional" firewall that a) assumed classfull
addressing, so any class-C address that ended in .255 was assumed to be
spoofed. And it only checked the destination address, so typically it
blocked the Syn-Ack from the server instead fo the Syn from the client.
It also would allow or deny /ALL/ ICMP, including fragmentation-needed.
What a piece of ****.
[2] (Older) Firewall-1 cannot handle related traffic correctly without
minor brain surgery. And when logging in, it will tell you if it was the
username or the password that was wrong.
[3] So many SOHO routers where the initial version allowed management
from the outside by default. The first update for the firmware would
typically address this.
Rick Jones
> I'm not sure I see any easy way to separate the two, or even whether
> it's beneficial to separate the two. Do you propose setting a limit,
> whether arbitrary or adaptive, on the number of SYN packets you'd
> allow through, and any beyond that limit would be dropped? If so,
> that might help with this specific DOS attack, but a distributed
> attack would be allowed through. I'm not trying to be argumentative,
> I'm just trying to see more sides of this and expand my knowledge.
I _generally_ view standalone firewalls as a sad admission that
end-system designers (OS and App developers) and administrators cannot
get their act together. As such, I hold them in only slightly higher
esteem than NATs. A curmudgeonly old-school point of view perhaps,
but then I keep thinking of one of the chapter quotes from The
Mythical Man-Month:
Adde parvum parvo magnus acervus erit - Ovid
Add little to little and there will be a big pile.
rick jones
--
portable adj, code that compiles under more than one compiler
Char Jackson
<rick....@hp.com> wrote:
>Char Jackson <no...@none.invalid> wrote:
>> I'm not sure I see any easy way to separate the two, or even whether
>> it's beneficial to separate the two. Do you propose setting a limit,
>> whether arbitrary or adaptive, on the number of SYN packets you'd
>> allow through, and any beyond that limit would be dropped? If so,
>> that might help with this specific DOS attack, but a distributed
>> attack would be allowed through. I'm not trying to be argumentative,
>> I'm just trying to see more sides of this and expand my knowledge.
>
>I _generally_ view standalone firewalls as a sad admission that
>end-system designers (OS and App developers) and administrators cannot
>get their act together. As such, I hold them in only slightly higher
>esteem than NATs. A curmudgeonly old-school point of view perhaps,
>but then I keep thinking of one of the chapter quotes from The
>Mythical Man-Month:
>
> Adde parvum parvo magnus acervus erit - Ovid
> Add little to little and there will be a big pile.
>
>rick jones
I see your side, thanks.
David Schwartz
> > Any firewall that tries to handle SYN floods by spoofing the
> > connection until the three way handshake is complete. Firewall-1
> > does this for instance and I suspect others as well.
> Isn't that somewhat borrowing from Peter to pay Paul? I would think
> that space for "state" would be even more limited in a firewall than
> it would be in the host(s) behind it.
No, it need not keep any state because it put the only state it needs
in the rewritten sequence numbers. The firewall only needs to keep any
more state than that *if* it gets a reply. So it can reject invalid
SYNs with no state stored locally.
DS
David Schwartz
> >I see a huge gulf separating dropping a SYN early and an intermediate
> >device pretending to be the end destination.
The problem is that those are your choices in the case of a SYN flood.
Pretending to be the end station is preferable to dropping the SYNs
early. If you know of some third alternative, do tell.
> I'm not sure I see any easy way to separate the two, or even whether
> it's beneficial to separate the two. Do you propose setting a limit,
> whether arbitrary or adaptive, on the number of SYN packets you'd
> allow through, and any beyond that limit would be dropped? If so, that
> might help with this specific DOS attack, but a distributed attack
> would be allowed through. I'm not trying to be argumentative, I'm just
> trying to see more sides of this and expand my knowledge.
Actually, that makes you much more vulnerable to this attack. To
resist the attack, you *must* reply to every SYN. The point of the
attack is to send you so many bogus SYNs that you can't reply to all
of them, thereby preventing you from replying to legitimate SYNs,
denying service.
The solution is to respond to every SYN, but to do so using the
network to hold your state. You put all the state you need into the
outbound SYN ACKs. When you get replies, you then get your state back,
so you didn't need to store it in memory. But this requires
impersonation, otherwise there's no place to keep the state.
DS