lkml.org 
[lkml]   [2004]   [Jul]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: preliminary conclusions regarding window size issues
On Thu, Jul 08, 2004 at 02:44:43AM +0100, Jamie Lokier wrote:

> An iptable mangle rule would do the trick -- mangle the TTL only on
> packets which match this point in the trace.

Indeed fiddly - not only does the packet have to disappear, we need an ICMP
to confirm that. This is because the packet currently disappears anyhow.

Another thought that ocurred to me is that this might be a window tracking
firewall that says, based on the scaled window size which it misinterprets
because it does not understand window scaling: "I'm not going to let this
packet pass, I've seen that the intended recipient announced a 43 byte
window size".

The idea such a silly firewall would have is that it 'protects' a host from
traffic it can't handle.

This jives with the observed fact that things work up to and including
wscale=2, but breaks with wscale=3. With wscale=3, the scaled window size is
730. With wscale=2, the observed window of 1460 is big enough to let a
packet pass.

We could verify this assumption by checking if lowering the MTU to say 700
allows wscale=3 to work.

Looking at the traceroute to Alessandro, my current suspect is this machine:

(The 1655 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
81/tcp filtered hosts2-ns
135/tcp filtered msrpc
445/tcp filtered microsoft-ds
514/tcp open shell
No exact OS matches for host (If you know what OS is running on it, see
http://www.insecure.org/cgi-bin/nmap-submit.cgi).
TCP/IP fingerprint:
SInfo(V=3.50%P=i686-pc-linux-gnu%D=7/8%Time=40ECDF49%O=514%C=1)
TSeq(Class=TR%IPID=Z%TS=U)
T1(Resp=Y%DF=Y%W=1020%ACK=S++%Flags=AS%Ops=ME)
T2(Resp=N)
T3(Resp=Y%DF=Y%W=1020%ACK=S++%Flags=AS%Ops=ME)
T4(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=)
T5(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=)
T6(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=)
T7(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=)
PU(Resp=N)


TCP Sequence Prediction: Class=truly random
Difficulty=9999999 (Good luck!)
TCP ISN Seq. Numbers: 9D217EAD 78BBFA4A 6C815E49 191A3C0A 2A07597F 8B869DAA
IPID Sequence Generation: All zeros

Nmap run completed -- 1 IP address (1 host up) scanned in 25.593 seconds

TCP port 514 is rsh, but when I try rsh on that port it doesn't work.

--
http://www.PowerDNS.com Open source, database driven DNS Software
http://lartc.org Linux Advanced Routing & Traffic Control HOWTO
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:04    [W:0.051 / U:1.000 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site