Re: [opensuse] Intrusion attempt?


On Dec 31 2006 14:51, Jan Engelhardt wrote:

WINDOW=8192
RES=0x00 ACK SYN URGP=0 OPT (02 04 05 98 01 01 08 0A 08 A2 DB AD 01 97 6D 81)

This however is strange. It would mean you got a spurious SYN ACK in
your connection. Which can't be, since the connection is unknown
(INVALID, see above). The option string says: maximum segment size is
0x598 (1432), and some other bits not covered by RFC 793.

Well, it's not so strange. Combining "INVALID" and "SYN ACK" means
the SYN ACK returned _much_ later than the Linux TCP stack expected
it (a minute, hour, day, no idea what the default is) -- unless of
course the below holds true where connections spuriously become
INVALID.

The option string, fully decoded:

0x02040598 TCP MSS: 0x598 = 1432
0x01 noop
0x01 noop
0x080A.. Lifetime of orphaned FIN-WAIT-2 state; you can find
details in /usr/src/linux/net/ipv4/tcp.c line 1643 ("This is a
(useful) BSD violating of the RFC.").

All in all my conclusion is: The packet you received is valid, as part
of _you_ establishing a connection (probably visiting a webpage with
ads), however, for some __strange__ reason, the connection is INVALID.


I have seen similar strange things with iptables/netfilter recently --
established connections just went INVALID for no apparent reason, yet
they continued to be listed as ESTABLISHED in `conntrack -L`.

What you can do in the short term: post the results of `iptables-save`,
it might reveal some oddity I just stumbled over yesterday. In the long
term, upgrading to iptables 1.3.7 (suser-jengelh) might solve the
problem, the more if iptables-save shows what I think it could show.

-`J'
--
--
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx

Relevant Pages

  • Re: [opensuse] Intrusion attempt?
    ... What we see here seems to be matching -m conntrack --ctstate INVALID. ... since the connection is unknown ... What you can do in the short term: post the results of `iptables-save`, ...
    (SuSE)
  • Re: Understanding TCP SYN ACK and discards
    ... SYN ACK ... (Sequence number not within expected range, possible attack) ... Could it be you're using passive FTP? ... use more than one connection. ...
    (comp.security.firewalls)
  • Re: iptables and nimda.
    ... so these look to be syn ack in reply to a connection ... > the previous connection request. ... AFAIK the syn acks are produced by the kernel as ... How do I tune the connection tracking parameters? ...
    (comp.os.linux.security)
  • Re: Oddball Routing Issue
    ... is reduced if there's already a connection in place between boxes? ... less than 100 ms ping to the controller. ... STUN it did not work over the WAN even ... a SYN ACK on the controller service port and the controller comes ...
    (comp.dcom.sys.cisco)
  • Re: advanced routing
    ... > another I don't recall right now). ... > failover when using two ISP's, but it's just not working very well. ... On all TCP connection attempts, send the SYN out on BOTH links. ... > Whichever link responds with SYN ACK the quickest gets the connection and a ...
    (comp.os.linux.networking)