Security Incidents mailing list archives
Re: Help with an odd log file...
From: "Fabio Panigatti" <ml-panigatti () minerprint it>
Date: Thu, 5 Jun 2003 15:01:35 +0200
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. ---------------------------------------------------------------------------- ----------------------------------------------------------------------------
Current thread:
- Help with an odd log file... sec_slave (Jun 03)
- Re: Help with an odd log file... morning_wood (Jun 04)
- Re: Help with an odd log file... Fabio Panigatti (Jun 05)
- Re: Help with an odd log file... Fabio Panigatti (Jun 10)
- <Possible follow-ups>
- RE: Help with an odd log file... Brad Bemis (Jun 05)
- Re: Help with an odd log file... sec_slave (Jun 05)
- RE: Help with an odd log file... Golden Faron P Contr HQ SSG/SWSN (Jun 09)
- Re(2): Help with an odd log file... Ken Eichman (Jun 09)
- Re: Help with an odd log file... James C. Slora Jr. (Jun 09)
- Re(2): Help with an odd log file... Ken Eichman (Jun 10)
- Re: Help with an odd log file... James C. Slora Jr. (Jun 12)
- Re(2): Help with an odd log file... Ken Eichman (Jun 10)
- Re: Help with an odd log file... James C. Slora Jr. (Jun 10)