Can someone explain this to me?

[Error]

From /var/log/messages

Jun 28 08:54:36 localhost kernel: IN=eth1 OUT=eth1 SRC=64.12.26.158 DST=192.168.3.100 LEN=153 TOS=0x00 PREC=0x00 TTL=103 ID=37981 DF PROTO=TCP SPT=5190 DPT=3513 WINDOW=16384 RES=0x00 ACK PSH URGP=0

My messages log is being over run with this for the last two days.

[Mat]

looks like messages from SuSEFirewall

[eigen]

If that Ip in your log is the real one then ....it is prolly a zombied Ms box.That1234 coudld be subseven. The port 1214 is opened by a lot of p2p.

Here is the dirt.

nmap -sS -sV -O -F -P0 -oN -v 64.12.26.158

PORT STATE SERVICE VERSION
135/tcp filtered msrpc
139/tcp filtered netbios-ssn
445/tcp filtered microsoft-ds
1214/tcp filtered fasttrack
1234/tcp filtered hotline
1388/tcp filtered objective-dbc
3128/tcp filtered squid-http
3141/tcp filtered vmodem
6346/tcp filtered gnutella
6667/tcp filtered irc
6668/tcp filtered irc

They are also a AOL user. zombie.

[crackers]

You're being port-scanned for open ports and the firewall is dropping the packets, like it should. The key is to look at the "DPT=" value - that's the destination port that's being accessed. 3513 is listed (according to a Google search) as the "Adaptec Remote Protocol", which obviously shouldn't be opened in a firewall just by the name of it - it obviously sounds like a network control stack specific to Adaptec devices.

It's definitely coming from an AOL account - whether deliberately or as a "zombie."

$ dig -x 64.12.26.158

; <<>> DiG 9.2.3 <<>> -x 64.12.26.158
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 25842
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;158.26.12.64.in-addr.arpa. IN PTR

;; AUTHORITY SECTION:
26.12.64.in-addr.arpa. 3600 IN SOA dns-01.ns.aol.com. hostmaster.aol.net. 2000052500 1800 300 604800 3600

;; Query time: 81 msec
;; SERVER: 24.93.40.62#53(24.93.40.62)
;; WHEN: Mon Jul 5 12:55:00 2004
;; MSG SIZE rcvd: 114

[eigen]

I just assume It is zombie as the open ports indicate this. I imagine that there is an option to filter out redundant hits, or to not log certain SRC's

[crackers]

Since I've not used IPTABLES directly, I cant' tell you exactly what to do, but using GuardDog (http://www.simonzone.com/software/guarddog) in the past, I've made certain ports just "disappear" (drop packets, not reject them, which makes that port a "black-hole") and not logging them. I got too tired of seeing the internal Windows broadcasts trying to get out! (This was when my wife was still using Windows, of course.)

[bradthemad]

What open ports? That nmap scan only printed out a few ports that were filtered, and zero that were open. Filtered means there was something preventing nmap from getting an adequate response to determine whether the port was open or closed; it is sufficient to demonstrate that you can't reach those ports, though.

What's so suspicious about a return (ACK) packet from AOL address space on the port AOL Instant Messenger uses? I'm running gaim and have three such connections open to hosts in that 64.12.0.0/16 netblock right now:


% netstat -an --inet|grep 5190
tcp 0 0 10.0.0.100:39395 64.12.25.13:5190 ESTABLISHED
tcp 0 0 10.0.0.100:39396 64.12.28.9:5190 ESTABLISHED
tcp 0 0 10.0.0.100:39394 64.12.25.160:5190 ESTABLISHED

[crackers]

The port number showing in Error's log is as I listed above. It's not open - but it's being scanned, apparently regularly. Since this port is associated with a known vendor-protocol, it's unlikely it's being used for legitimate purposes. The downside to Error's firewall setup is that, even though the port is being scanned, the "perpetrator(s)" know there's a computer at that address because they're getting a "reject" packet, instead of it simply disappearing (being dropped).

When I was running a Linux-based firewall/router, I was continually being scanned on the Kazaa port - and I don't and never have run anything on that port. The scanning gradually stopped when I started dropping the packets instead of rejecting them (but I still logged them).

[bradthemad]

You completely missed my whole point. Drat!

For one, the portscan I was referring to was the one done by eigen, which just turned up a bunch of filtered ports on the AOL host. That's an easy oversight to make, too; you run nmap, it spits out a bunch of ports, and you think "A-ha! Look at all those ports!" but it takes a second look to realize it said they were filtered, not open. The point being that there was nothing shown to indicate any zombie running at AOL, just a host that didn't tell nmap very much.

On to the main topic. Look at the source address of the packet: 64.12.26.158, allocated to AOL. Look at the source port of the packet: 5190, used by AOL's AIM and ICQ instant messengers. Look at the destination port: 3513, unprivileged, and not widely used by any common service. Look at the TCP flags, particularly that it's an ACK. Think about basic TCP/IP networking concepts. What is the simplest explanation for seeing such a packet?

If you're running an AOL/ICQ Instant Messenger client, the first thing it does when you sign on is send off a SYN to port 5190 on whatever server(s) at AOL is handling AIM/ICQ, which seems to vary among hosts in the 64.12.0.0/16 range; I usually get connected to something between 64.12.25.0 and 64.12.28.0 (look familiar?). Anyway, this packet will originate from an unprivileged "ephemeral" port on your machine, which could be any port from 1024 on up to 65535 (the range is configurable in gaim), such as 1234, for example:

your_machine:1234 SYN -> AIM_server:5190

The AIM/ICQ server replies with a SYN/ACK, from its port 5190 back to your machine.

AIM_server:5190 SYN/ACK -> your_machine:1234

Your machine completes the 3-way handshake by sending an ACK back to port 5190 at AOL. Everything after that is all ACK packets between the ephemeral port on your machine and 5190 on the AOL machine, as you get logged on and send and receive messages all day, until you log off and the connection is torn down.

your_machine:1234 ACK -> AIM_server:5190
AIM_server:5190 ACK -> your_machine:1234
your_machine:1234 ACK -> AIM_server:5190
AIM_server:5190 ACK -> your_machine:1234
your_machine:1234 ACK -> AIM_server:5190
...etc.

Networking-101 stuff here. If you don't believe me, fire up `tcpdump port 5190`, sign on to AIM or ICQ, and watch it happen for yourself. Back to the packet from Error's log, with the extra details trimmed out:

SRC=64.12.26.158 DST=192.168.3.100 PROTO=TCP SPT=5190 DPT=3513 ACK

In other words:

AIM_server:5190 ACK -> error's_machine:3513

Where have we seen that kind of thing before?

If this is really just benign AIM/ICQ traffic, then why is it getting dropped and logged? Well, in the other place (http://www.fedoraforum.org/forum/showthread.php?t=18463) Error where posed this same question and followed up with some more detail, a look at his firewall rules tells you that the rule that would normally allow in legitimate return traffic (ACKs) is:

$IPTABLES -A FORWARD -i $EXTIF -o $INTIF -m state --state ESTABLISHED,RELATED -j ACCEPT

Incoming traffic that doesn't match that rule gets logged and hits the FORWARD chain's default policy of DROP. It would appear, then, that for whatever reason, the AIM connection was no longer considered ESTABLISHED or RELATED. That happens. I've got a bunch of logs very similar to Error's, usually from when our DSL craps out and the Linux firewall loses its connection table, which is where it keeps track of what's NEW and what's ESTABLISHED or RELATED. Or it could be a buggy or misconfigured IM client. It's really not easy to tell, having seen only one of the logged packets. You don't see the corresponding outgoing traffic in the logs because all outbound traffic is accepted.

That's my simple, yet grotesquely drawn out answer.

*Could* it be AOL portscanning Error's machine? It's possible that some rogue machine at AOL is scanning for people running whatever the heck uses "Adaptec Remote Protocol", and that it's just a coincidence that it's in the same netblock as the AIM/ICQ servers, and came from the same port those use, but that seems pretty far fetched to me. Dshield (http://dshield.org/port_report.php?port=3513) doesn't indicate anything notable or widespread happening on that port. Even Google only had about 20 results for "Adaptec Remote Protocol" (http://www.google.com/search?q=%22Adaptec+Remote+Protocol%22), and all but one of those were just lists of ports and service names; nothing about any known vulnerabilities associated with the port, and only one result to confirm that there's anything in existence that actually uses it.

[crackers]

Ah, I didn't get that you were referring to eigen's post - you are entirely (well, almost) correct. The part I would at least agree to disagree on was why port 3513? I certainly doubt that GAIM or any other IM app would start using a port that's already assigned to a "known" (if unused) protocol. (I wouldn't know for sure, since I don't use IM - just a supposition and I could be "smoking crack" as one of my co-workers would describe it.)

I've watched this behavior before - typically if it were a port-scan, you'd see a series of attempts at these odd, unused ports. Then you'd see the scan jump to another one. Personally, when I see that pattern, I'm pretty sure it's some no-brain script kiddie running a package he knows absolutely nothing about and is just looking for the "easy way in."

[bradthemad]

A typical TCP/IP stack doesn't really care about whether a port has been reserved by IANA for a certain use or not. There's usually a specific range of local ports to use in outgoing connections, which differs from OS to OS, but out of that range, if it's not in use, it's fair game when opening a new socket. The stack will start at the low end of that range and increment up for each new connection. If something's already using a port, it's skipped over. It's much the same way PID numbers are assigned to processes.

In Linux, this range is tunable via /proc/sys/net/ipv4/ip_local_port_range. On systems with less than 128MB of RAM, this range defaults to 1024-4999; more memory, and the range jumps up to 32768-61000. And it's pretty standard on most systems to reserve ports 0-1023 for privileged use.