> Total Length: 52 > Identification: 0xb82b > Time to live: 118 > Sequence number: 1409168989 > Header length: 32 bytes > .... ..1. = Syn: Set > Window size: 55808 > Options: (12 bytes) > Maximum segment size: 1460 bytes > NOP > Window scale: 2 (multiply by 4) > NOP > NOP > SACK permitted From May 21 I received about 120 packets like this one: May 21 03:00:25 fw kernel: CATCHALL IN=eth2 OUT=eth0 SRC=126.123.252.5 DST=<myip> LEN=52 TOS=0x18 PREC=0x20 TTL=105 ID=58793 PROTO=TCP SPT= 38039 DPT=41240 SEQ=2550999126 ACK=0 WINDOW=55808 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402) Every packet is identical to each other, except for TTL field, which vary from 102 and 108, and IP-ID, always set to 58793 except a couple of times. This kind of SYN packet doesn't belong to any known TCP/IP stack. There are a lot of field in common with the packet you have captured, first of all the tcp windows size, but also the tcp options worth a look. Both are peculiar. I think that are crafted by the same tool. <myip> is a w2k workstation within an ip range protected by a netfilter firewall. NEW sesisons aren't permitted from the internet to the internal net. Until yesterday I received packets only from 126.123.252.5, with a period varying from 5 minutes to 10 hours, but the average rate is growing. All the packets are directed to <myip> and none to other ip's in the same ip range, so the traffic is specifically aimed to <myip>. On Jun 2 I found those two lines: Jun 2 08:25:59 fw kernel: CATCHALL IN=eth2 OUT=eth0 SRC=68.76.86.82 DST=<mioip> LEN=52 TOS=0x18 PREC=0x20 TTL=109 ID=58793 PROTO=TCP SPT= 38039 DPT=41240 SEQ=2550999126 ACK=0 WINDOW=55808 RES=0x00 SYN URGP=0 OPT (020405AC0103030201010402) Jun 2 15:34:58 fw kernel: CATCHALL IN=eth2 OUT=eth0 SRC=207.75.1.254 DST=<mioip> LEN=52 TOS=0x18 PREC=0x20 TTL=104 ID=58793 PROTO=TCP SPT= 23657 DPT=41240 SEQ=4057633743 ACK=0 WINDOW=55808 RES=0x00 SYN URGP=0 OPT (020405640103030201010402) So this is not an unusual misconfigured network appliance trying to talk with the wrong ip address, which was my first thought. 68.76.86.82 is a known blacklisted open proxy, running an obfuscated tcp/ip stack, but the packet above doesn't come from the proxy daemon but it's originated by some tool runned on the host. Also 207.75.1.254 has an obfuscated tcp/ip stack (both have a mangled TTL). 126.123.252.5 is, obviously, a iana-reserved non-routable ip address. Why this kind of address? Maybe because it's the private address of a r00ted server behind a stateful DNAT firewall or load balancer with no SNAT rules for the NEW traffic originated from the server. So, the attacker gained a shell from the outside (the DNAT permit this) but when he try to connect from there to the outside the traffic is sourced from the wrong ip address because of the lack of SNAT in this direction. Actually I'm working on three directions: 1) a trojan/backdor installed on <myip> which sent his haddress (<myip>) to someone (and now someone is trying to connect); 2) a miscoded trojan/backdor (with <myip> ip address hardcoded for a typing error) that is trying to call home to notify his address. The coder erroneusly typed <myip> instead of the real home ip, and so the infected hosts are trying to contact me instead of the real malware owner; 3) a joke by some good guys. <myip> is a w2k workstation within an ip range protected by a netfilter firewall. NEW sessions aren't permitted from the internet to the internal net. The host is also protected by a personal firewall with application based egress filtering, two antivirus (one real-time) updated every 6 hours. The workstation is very hardened, with tight acls on code execution permissions (users and folders) and folder/file access, usually operated by skilled and security conscious users. For all this I think that point one isn't a good choice. Since I log session state for all tcp traffic flowing through the firewall, I parsed the past month logs searching for unusual tcp sessions originated from <myip>, but nothing strange happened. I can't say nothing about udp and icmp. Point 2 and 3 was two good choices until I saw your post. No other bright idea's, now. Since it seems that also routeable address (unlike the first one) are involved, I arranged a simple honeypot, but until now only 126.123.252.5 still try to connect. Fabio PS: sorry for my poor english. ---------------------------------------------------------------------------- ----------------------------------------------------------------------------
This archive was generated by hypermail 2b30 : Thu Jun 05 2003 - 08:57:14 PDT