> Date Hits SrcIP SrcPort DstIP DstPort Seq#
> ---- ---- ----- ------- ----- ------- ----
> 0516 0 0 0 0 0 0
> 0517 235 188 212 230 229 230
> 0518 128 114 113 121 121 121
> 0519 146 87 108 119 112 129
> [...]
The increase is similar to the one I'm experiencing, ignoring the different
order of magnitude of my traffic volume (since only one of my hosts is
involved).
> I don't know what, if anything these numbers show, other than an increase
> in traffic volume. Hard to say if it means the number of compromised hosts
> is increasing, although that might be a logical conclusion.
Maybe the number of "compromised" hosts is quite constant and the traffic
increase is due to an increase on the number of "activated" hosts.
If the target application of this traffic is a worm, it doesn't exploits a
direct tcp/ip connection with the victim for spreading itself (like some
recent SMB/CIFS worms) since my host isn't reachable from the internet.
Also an e-mail spreading is unlikely. Maybe the target of the traffic is a
trojan the users installed on their host as a legitimate application, with
network access trust in the personal firewall configuration, like a p2p file
sharing software or something similar. If it isn't a "trojan" network
application, is likely that it's exploiting some personal firewall egress
filtering evasion technique, since no suspect outbound connection attempts
from unauthorized processes were reported by the personal firewall. In the
past few days I changed the personal firewall with a different one and,
again, only legitimate applications, until now, seems to ask for outbound
connection. No need to say that there aren't suspect processes listening on
the host or unknown startup entries.
Well... it's also likely that my host isn't really a node of the trojan/bot
net but that was erroneusly inserted in some ip adresses database.
> Best I can determine, this traffic apparently first showed up here at 00:05
> GMT on May 17. Most (all?) of it is spoofed, with many one-to-one source IP
> probers, eg:
I run the honeypot for several days, then a couple of days ago, I started to
drop the traffic to see which will be the behaviour of the remote senders with
a non responsive destination.
During the uptime of the honeypot:
- I saw SYNs from 27 distinct ip sources.
- 21 of them didn't reply to my SYN/ACK, but...
- at least 8 of these 21 hosts was up and running at the time my SYN/ACK was
sent and they were reachable with tcp packets, but no RST or ACK was received
back. Here's a sample trace of the half open connection and the related
hping probe I did no more than 30 seconds later showing that the host was
responsive over tcp on the port involved.
| 06/10-11:08:27.774904 -> type:0x800 len:0x42
| 213.219.141.140:1025 -> <mioip>:41240 TCP TTL:109
| TOS:0x38 ID:58793 IpLen:20 DgmLen:52
| ******S* Seq: 0x980D2856 Ack: 0x0 Win: 0xDA00 TcpLen: 32
| TCP Options (6) => MSS: 1460 NOP WS: 2 NOP NOP SackOK
|
| =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|
| 06/10-11:08:27.775550 -> type:0x800 len:0x42
| <mioip>:41240 -> 213.219.141.140:1025 TCP TTL:64 TOS:0x0
| ID:0 IpLen:20 DgmLen:52 DF
| ***A**S* Seq: 0x5AC72E48 Ack: 0x980D2857 Win: 0x16D0 TcpLen: 32 TCP
| Options (6) => MSS: 1460 NOP NOP SackOK NOP WS: 0
|
| [no RST or ACK received]
|
| $ hping2 -c 1 -p 1025 -SA 213.219.141.140
| HPING 213.219.141.140 (eth2 213.219.141.140): SA set, 40 headers + 0
| len=46 ip=213.219.141.140 flags=R seq=0 ttl=108 id=33135 win=0
|
| --- 213.219.141.140 hping statistic ---
| 1 packets tramitted, 1 packets received, 0% packet loss
| round-trip min/avg/max = 130.1/130.1/130.1 ms
- the remaining 6 hosts apparently emitted a RST. The RST wasn't elicited by
my SYN/ACK but it was forged. Here's one sample trace. Also look at the TTL
of the RST (sometimes is equal to the one of the SYN, sometimes is one hop
less).
| 06/10-10:28:49.210288 -> type:0x800 len:0x42
| 68.65.241.80:38039 -> <mioip>:41240 TCP TTL:99 TOS:0x38 ID:58793
| IpLen:20 DgmLen:52
| ******S* Seq: 0x980D2856 Ack: 0x0 Win: 0xDA00 TcpLen: 32
| TCP Options (6) => MSS: 1460 NOP WS: 2 NOP NOP SackOK
|
| =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|
| 06/10-10:28:49.210918 -> type:0x800 len:0x42
| <mioip>:41240 -> 68.65.241.80:38039 TCP TTL:64 TOS:0x0 ID:0 IpLen:20
| DgmLen:52 DF
| ***A**S* Seq: 0xC3B06776 Ack: 0x980D2857 Win: 0x16D0 TcpLen: 32
| TCP Options (6) => MSS: 1460 NOP NOP SackOK NOP WS: 0
|
| =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|
| 06/10-10:28:50.969628 -> type:0x800 len:0x3C
| 68.65.241.80:38039 -> <mioip>:41240 TCP TTL:100 TOS:0x38 ID:41823
| IpLen:20 DgmLen:40
| *****R** Seq: 0x980D2857 Ack: 0x980D2857 Win: 0x0 TcpLen: 20
|
| =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
- only 2 of the 27 hosts contacted me a second time: 211.170.36.114 with
two different source ports, and 24.194.101.0, the both times with also
the forged RST.
- every manually probed host showed a TTL related with the one I saw
in the SYN apparently sourced from it. All were windows 2000 or XP with
netbios activated.
- I saw ip 141.153.176.215 for the first time when I started to drop the
traffic instead to reply to it, and two more times in the next 18
hours. This is the only routable ip until now that retried to connect
more than two times. This ip isn't apparently reachable but it can
simply be firewalled or down (I tested it a lot of hours after receiving
the SYN). If I'll see more attempt from this ip, the assertion that this
address isn't spoofed or, at least, that someone is waiting for a response
from my host along the road or in the destination network will become
fairly realistic.
In conclusion, for some of the facts above, at this time I can't definitely
say that _all_ the source ip addresses are spoofed.
126.123.252.5 still send SYNs on a slightly increasing rate.
I noticed a little increase on IPID variations, but almost 90% are always
58793 (at least for my ip destination).
Yesterday I stopped the personal firewall and I replayed the suspect traffic
against my host (the supposed target of the traffic) but nothing happened (no
output traffic elicited). Then I replayed again the packets turning on the
firewall and running tdimon, in order to catch some bind() attempt, again with
no results. I'll try the same technique after starting up some of the more
suspect applications installed on the workstation.
> 0.111.73.86: UNKNOWN [55808:112:64118:0:2:1:1:52].
^^^^^
This p0f log row posted by Golden Faron shows a wss of 64118, one of the
biggest differencies I saw until now in the tcp options field.
Fabio
----------------------------------------------------------------------------
----------------------------------------------------------------------------
This archive was generated by hypermail 2b30 : Fri Jun 13 2003 - 13:47:09 PDT