Hideously out-of-date! This is from about February of 2002 :-/

Anatomy of a hack...

...or a probe, at least.

Incident logs from the FinchHaven datacenter firewall

Several probes, actually..

OK: so I've got the FinchHaven Data Center up and running, and I'm settling down into using them, and one of the main deals was to set up one box as a firewall, and IP masquerade the others boxes behind that, so that any box in the house could get on the Internet through the one dynamic IP address that we get from our dialup to att.worldnet.net.

OK, and so if you say "firewall" that implies that you're keeping someone out, or keeping someone in.

So which am I doing, here?

Keeping someone out.

"Who?" you might well ask, "Are you paranoid, or just nuts?"

(heh.. I'm not paranoid: I know they're after me; and my being nuts is not an issue, here...)

So we have a dialup connection; we're only up intermittently, not up full-time like the new DSL or cable modem services that some people can get, some places, and so we have a dynamic IP address, and it changes (within a certain range) everytime we make a new connection.

So our box(es) should be of very little interest to crackers or script kiddies.

Or so you might think..

So what am I worried about?

I'm worried by the basic fact that script kiddies aren't real bright, and I'm worried by the basic fact that it's a lot more likely that someone's going to port-scan a whole block of IP addresses rather than mess around just trying to hunt out IP's that are up full-time like DSL and cable modems, and any real systems that are up full-time.

And since we're actually up an awful lot lately, I just want to learn about the issue, and be ready.

So how am I going to know if anybody's knocking, and how am I gonna keep 'em out?

I'm not going to go into a lot of detail about how I'm keeping stuff out, 'cause I'm still learning about this myself, and because I don't want to give away any *useful* information.

Suffice it to say that we're using IP chains, blocking certain specific IP ranges that should *never* show up as the origin of any packets, like the 192.168.x.x IP range, which is for private, internal networks only.

And we're blocking certain specific protocols, and certain ranges of ports, and packets with certain flags set...

And we're doing other stuff, like we've got the services running on the firewall turned 'way down to almost nothing, and stuff like that... ;-)

And behind that, we're running PortSentry and LogCheck.

So, what's PortSentry?

            "PortSentry is part of the Abacus Project suite of
             security tools. It is a program designed to detect
             and respond to port scans against a target host in
             real-time." 



            "PortSentry will detect any connection made to a TCP
             or UDP port on your host that you tell it to listen
             to. A configuration file can be made to have it
             listen to dozens of ports at once to detect
             anything from a full-fledged sequential port sweep
             to a random port probing. Because it covers the UDP
             spectrum as well it will alert you to people
             probing for RPC services surreptitiously as well as
             TFTP, SNMP, etc."

And, what about LogCheck?

            "Logcheck is part of the Abacus Project of security
             tools. It is a program created to help in the
             processing of UNIX system logfiles generated by the
             various Abacus Project tools, system daemons,
             Wietse Venema's TCP Wrapper and Log Daemon
             packages, and the Firewall Toolkit® by Trusted
             Information Systems® Inc.(TIS). Logcheck also works
             very well at reporting on other common operating
             system security violations and strange events." 



            "Logcheck helps spot problems and security
             violations in your logfiles automatically and will
             send the results to you in e-mail. This program is
             free to use at any site."

So PortSentry is listening for any weird stuff, and LogCheck watches the system logs (which includes the logging of packets that are DENY'ed by IP chains) and like that..

Fine, you say, big deal, you're systems's a tiny little fish in a great big pond, does anything ever happen?

In a word, Yes.

We've been seriously port-scanned once, from an IP address that I traced back to a web page in Korea, a port-scan that was attempting to connect to tcp port 109, which is a well-known port for pop-2 email.

It looks like this, from PortSentry and the resulting email to me as sysadmin, via LogCheck:

    Active System Attack Alerts
    =-=-=-=-=-=-=-=-=-=-=-=-=-=
    Jul 16 17:09:54 [localhost] portsentry[13985]: attackalert: Unknown Type:
    Packet Flags: SYN: 1 FIN: 1 ACK: 0 PSH: 0 URG: 0 RST: 0
    from host: 211.34.146.65/211.34.146.65 to TCP port: 109

    Jul 16 17:09:54 [localhost] portsentry[13985]: attackalert: Host 211.34.146.65 has
    been blocked via wrappers with string: "ALL: 211.34.146.65"

So, now that IP address (211.34.146.65) is blocked in /etc/hosts.deny

Other kinda weird stuff has happened, too, stuff that's maybe less conclusive, but still stuff that I'm not going to let in:

    Security Violations
    =-=-=-=-=-=-=-=-=-=
    Aug 12 11:54:07 [localhost] kernel: Packet log: input DENY ppp0 PROTO=6
    61.143.75.103:1734 12.82.141.38:80 L=48 S=0x00 I=26135 F=0x4000 T=109 SYN (#7)

    Aug 12 11:54:07 [localhost] kernel: Packet log: input DENY ppp0 PROTO=6
    61.143.75.103:1735 12.82.141.38:8080 L=48 S=0x00 I=26391 F=0x4000 T=109 SYN (#7)

    Aug 12 11:54:08 [localhost] kernel: Packet log: input DENY ppp0 PROTO=6
    61.143.75.103:1736 12.82.141.38:3218 L=48 S=0x00 I=45079 F=0x4000 T=109 SYN (#7)

    Aug 12 11:54:10 [localhost] kernel: Packet log: input DENY ppp0 PROTO=6
    61.143.75.103:1735 12.82.141.38:8080 L=48 S=0x00 I=792 F=0x4000 T=109 SYN (#7)

    Aug 12 11:54:10 [localhost] kernel: Packet log: input DENY ppp0 PROTO=6
    61.143.75.103:1734 12.82.141.38:80 L=48 S=0x00 I=1560 F=0x4000 T=109 SYN (#7)

    Aug 12 11:54:12 [localhost] kernel: Packet log: input DENY ppp0 PROTO=6
    61.143.75.103:1736 12.82.141.38:3218 L=48 S=0x00 I=14104 F=0x4000 T=109 SYN (#7)

This shows up in the logs because the packets were DENY'ed by IP chains.

The IP address 61.143.75.103 didn't resolve to a domain name; using NeoTrace back on our Win98 box, I was able to trace to it, and it came back with a host name "Computer_6"

The closest identifiable IP address was 4 hops earlier as 202.105.2.14, the Registrant for which is
Data Communication Bureau, A21, Xin-Jie-Kou-Wai-Da-Jie, Beijing, 100088, CN

So, this was probably from someplace in the People's Republic of China...

Fun, huh?

What was going on here was, they were trying to connect to us (12.82.141.38) on well-known ports 80 and 8080 which are for WWW servers, and WWW proxy servers, neither of which we offer publicly, and also trying to connect to port 3218 which I haven't identified yet, except to see it mentioned on an email list digest, in German, that had something to do with the game Quake...

And a quick translation of what happened:

    Aug 12 11:54:07 [localhost] kernel: Packet log: input DENY ppp0 PROTO=6
    61.143.75.103:1735 12.82.141.38:8080 L=48 S=0x00 I=26391 F=0x4000 T=109 SYN (#7)

From the kernel daemon, through LogCheck: Aug 12 11:54:07 [localhost] kernel: Packet log:,

the packet was DENY'ed on the INPUT chain coming in on device ppp0, which is the virtual device set up by the Point-to-Point protocol when we dial into att.worldnet.net: input DENY ppp0,

the packet was a tcp packet: PROTO=6,

and the connection attempt was coming from 61.143.75.103:1735, his port 1735

and was trying to connect to us 12.82.141.38:8080, on our port 8080, which would be a WWW proxy, which of course we don't have..

and the packet was 48 bytes long (L=48), had no particular Type-of-Service set (S=0x00), had an IP id of 26391, had the Don't Fragment bit set (F=0x4000), had a Time-to-Live of 109, had the SYN flag set, meaning it was attempting to establish a connection to us, and, finally, was DENY'ed by Rule #7 on the input chain: L=48 S=0x00 I=26391 F=0x4000 T=109 SYN (#7)

Why did this poor little packet get DENY'ed?

Because of the SYN flag being set: we flat-out don't allow any connections to our firewall box, period, so we DENY'ed it!

The IP chains rule that does this says:

ipchains -A input -i $extint -p tcp -y -l -j DENY

which, in human, says:

"Append (-A) to the input chain a new rule which states: look for any packets coming in on the external interface (-i $extint -- ppp0), of protocol tcp (-p tcp) and *with* the SYN flag set (-y), and if you see one of these packets, log it (-l), and jump (-j) to the DENY rule."

Cool, huh?

Here's another one:

    Security Violations
    =-=-=-=-=-=-=-=-=-=
    Jul 24 15:05:07 [localhost] kernel: Packet log: input DENY ppp0 PROTO=1
    10.0.0.14:11 12.73.96.95:0 L=56 S=0x00 I=32586 F=0x0000 T=241 (#3)

    Jul 24 15:05:13 [localhost] kernel: Packet log: input DENY ppp0 PROTO=1
    10.0.0.14:11 12.73.96.95:0 L=56 S=0x00 I=32588 F=0x0000 T=241 (#3)

So what's the deal here?

The deal here is these packets are spoofed in some way: they say they're from 10.0.0.14 port 11, which, number one, is an IP address that can't exist out on the real Internet: it's from the reserved block 10.x.x.x which is only for use on private, class A internal networks, and it's from port 11, which is systat.

Here's some more:

    Security Violations
    =-=-=-=-=-=-=-=-=-=
    Jul 24 15:58:30 [localhost] kernel: Packet log: input DENY ppp0 PROTO=1
    172.167.87.26:0 12.73.96.95:0 L=37 S=0x00 I=3074 F=0x0000 T=115 (#4)

    Jul 24 16:02:00 [localhost] kernel: Packet log: input DENY ppp0 PROTO=1
    10.0.220.150:11 12.73.96.95:0 L=56 S=0x00 I=0 F=0x0000 T=250 (#3)

The first one's from an AOL dialup (!) 172.167.87.26, the second one's another one of those packets from the 10.x.x.x Class A private netblock...

And so it goes..

More, later...

OK: ...it's later

This has been an interesting one; We've seen this several times...

    Security Violations
    =-=-=-=-=-=-=-=-=-=
    Oct 11 19:19:08 [localhost] kernel: Packet log: input DENY ppp0 PROTO=17
    128.39.216.10:53 12.82.137.201:1024 L=253 S=0x00 I=60966 F=0x0000 T=38 (#5)

This is a udp packet (PROTO=17) from his port :53 (domain) attempting to connect to our port :1024. I've DENY'ed this IP completely because we've received a lot of icmp echo-requests and other stuff from it, and I'm not interested in finding out what they're up to..

    Oct 11 19:19:08 [localhost] kernel: Packet log: input DENY ppp0 PROTO=1
    128.39.216.10:8 12.82.137.201:0 L=1500 S=0x00 I=60965 F=0x4000 T=229 (#5)

This one's an icmp packet (PROTO=1) of type 8 (echo-request) -- we're now being pinged..

128.39.216.10 is fenrix.si.sintef.no -- something related to www.sintef.no? Who knows.. I don't *want* to know.

Here's one evening's worth, Wednesday, October 17, 2000 - the night the Mariners lost to the Yankees in game 6:

    Security Violations
    =-=-=-=-=-=-=-=-=-=
    Oct 17 20:13:12 [localhost] kernel: Packet log: input DENY ppp0 PROTO=6
    12.82.131.43:1083 12.82.131.34:139 L=48 S=0x00 I=31748 F=0x4000 T=127 SYN (#15)
    Oct 17 20:13:15 [localhost] kernel: Packet log: input DENY ppp0 PROTO=6
    12.82.131.43:1083 12.82.131.34:139 L=48 S=0x00 I=33284 F=0x4000 T=127 SYN (#15)

These are tcp packets (PROTO=6) with the SYN flag set (an attempt to establish a connection to us) from his port :1083 (who knows.. it's not in /etc/services) to our port :139 (netBIOS session service) -- this has been *really* common lately. These were DENY'ed by our rule #15.

12.82.131.43 is another dialup to worldnet.att.net here in metro Seattle! I haven't taken the time to figure out whether this is something malicious (a major port scan exploit is to the netBIOS ports :137 :138 or :139) or whether this is some clown on a mis-configured Window$ box that's just spraying packets when ever he logs on...

And then 24 minutes later we had:

    Security Violations
    =-=-=-=-=-=-=-=-=-=
    Oct 17 20:37:26 [localhost] kernel: Packet log: input DENY ppp0 PROTO=6
    208.241.48.242:2678 12.82.131.34:111 L=60 S=0x00 I=9124 F=0x4000 T=50 SYN (#17)
    Oct 17 20:37:29 [localhost] kernel: Packet log: input DENY ppp0 PROTO=6
    208.241.48.242:2678 12.82.131.34:111 L=60 S=0x00 I=9713 F=0x4000 T=50 SYN (#17)

These are tcp (PROTO=6) packets with the SYN flag set (an attempt to establish connection..) from his port :2678 (who knows..) to our port :111 (sunrpc portmapper) DENY'ed by our rule #17.

208.241.48.242 is buffniag.org -- "The Buffalo Niagara Partnership is a regional chamber of commerce for the Niagara marketplace, representing employers from the eight counties of Western New York and the southern peninsula of Ontario, Canada."

What? So, either the IP is spoofed, or somebody's screwing around on their computer system after-hours.. Maybe it's the janitor..

And then 43 minutes later we had:

    Security Violations
    =-=-=-=-=-=-=-=-=-=
    Oct 17 21:30:31 [localhost] kernel: Packet log: input DENY ppp0 PROTO=1
    128.39.216.10:8 12.82.131.34:0 L=1500 S=0x00 I=57634 F=0x4000 T=228 (#5)
    Oct 17 21:30:31 [localhost] kernel: Packet log: input DENY ppp0 PROTO=17
    128.39.216.10:53 12.82.131.34:1024 L=253 S=0x00 I=57635 F=0x0000 T=37 (#5)

128.39.216.10 is fenrix.si.sintef.no again, and the same pattern: one icmp echo-request followed by something *from* his domain port :53

Is this the internet equilvalent of dust-bunnies, just stray packets floating around? I don't know..

And then we get this clown again:

    Security Violations
    =-=-=-=-=-=-=-=-=-=
    Oct 17 21:51:40 [localhost] kernel: Packet log: input DENY ppp0 PROTO=6
    12.82.131.175:1201 12.82.131.34:139 L=48 S=0x00 I=55561 F=0x4000 T=126 SYN (#15)
    Oct 17 21:51:43 [localhost] kernel: Packet log: input DENY ppp0 PROTO=6
    12.82.131.175:1201 12.82.131.34:139 L=48 S=0x00 I=1290 F=0x4000 T=126 SYN (#15)

This is the guy on the metro-Seattle worldnet dialup, always poking at port :139 netBIOS session service; notice how *his* IP changes each time he reconnects; ours does too..

And then we get this guy *again*!!

    Security Violations
    =-=-=-=-=-=-=-=-=-=
    Oct 17 22:09:20 [localhost] kernel: Packet log: input DENY ppp0 PROTO=6
    12.82.131.105:1060 12.82.131.34:139 L=48 S=0x00 I=523 F=0x4000 T=127 SYN (#15)
    Oct 17 22:09:23 [localhost] kernel: Packet log: input DENY ppp0 PROTO=6
    12.82.131.105:1060 12.82.131.34:139 L=48 S=0x00 I=524 F=0x4000 T=127 SYN (#15)

There's not really a lot I can do about this; because he's a dialup with a dynamic IP, there's no firm way to identify just who this is without getting a sysadmin at worldnet to go through their logs and figure out who dialed in and was assigned that IP at that particular point in time...

Hideously out-of-date! This is from about February of 2002 :-/

GoTo the top

	All my digital photography copyright John D Sage/FinchHaven 1999, 2000, 2001, 2002
Any and all e-mail addresses associated with this domain in any way are located in the State of Washington, and as such may not, by law, be harvested for spam.
This page preened using GNU Emacs 20.5.1 at www.FinchHaven.com by Webmaster Last modified: Sun Nov 12 06:50:37 2006	counter 2, 3, 4

Goto the Top