Monday, January 02, 2006
Tar pits, legal and otherwise
Now that I more or less run my own DSL connection, I'm able to have more than a single static IP address. Because of that, I've given my main home system a public IP address so that I no longer have to log into my firewall/NAT system to get to it.
One thing about sitting next to a server is that over time, you get used
to the various patterns of noise the harddrive makes. It starts quickly
grinding, I know that a load of spam is coming in via my backup email server
(a common tactic of spammers—send spam to the backup servers which have less
information about valid users so they can “honestly” say they delivered the
email). The grinding that starts at 4:00 am are various cron
jobs rotating logs, clearing out temporary files and what not.
But over the holiday weekend linus (the machine in question)
started making some disk noises I'm unfamiliar with. A constant “click click”
noise, perhaps a second apart. I start poking around the system and it's a
scripted attack, attempting to log into my system:
Jan 1 13:57:50 linus sshd[24760]: Failed password for root from XXX.XXX.XXX.198 port 43440 ssh2 Jan 1 13:58:05 linus sshd[24784]: Failed password for nobody from XXX.XXX.XXX.198 port 45220 ssh2 Jan 1 13:58:06 linus sshd[24786]: Failed password for root from XXX.XXX.XXX.198 port 45351 ssh2 Jan 1 13:58:14 linus sshd[24799]: Failed password for www from XXX.XXX.XXX.198 port 46207 ssh2 Jan 1 13:58:27 linus sshd[24819]: Failed password for news from XXX.XXX.XXX.198 port 47673 ssh2 Jan 1 13:58:29 linus sshd[24823]: Failed password for games from XXX.XXX.XXX.198 port 47977 ssh2 Jan 1 13:58:33 linus sshd[24829]: Failed password for mail from XXX.XXX.XXX.198 port 48413 ssh2 Jan 1 13:58:34 linus sshd[24831]: Failed password for adm from XXX.XXX.XXX.198 port 48563 ssh2 Jan 1 13:59:03 linus sshd[24877]: Failed password for operator from XXX.XXX.XXX.198 port 51355 ssh2 Jan 1 13:59:12 linus sshd[24891]: Failed password for sshd from XXX.XXX.XXX.198 port 51947 ssh2
Hundreds of attempts.
Now, I could block them on the sever:
GenericUnitRootPrompt# route add -host XXX.XXX.XXX.198 reject
But that would only block them from my one server. And besides, there's this firewall between the internet and the DSL router at the office. Cut off the traffic a bit upstream so they can't scan any of the DSL connections:
GenericUnixRootPrompt# iptables --table filter --insert FORWARD --source XXX.XXX.XXX.198 --jump REJECT
And boom, the traffic stops dead.
For a few hours.
“Click click click click”
Yet another brute force attempt to log into my server. Previous one was from Germany. This one from the Netherlands. Another one a few hours later from Korea. One from Lakeland, Florida!
I ended up stopping eight of these attempts over the weekend—not because my system was particularly vulnerable, but the “click click click” of the disk drive was rather annoying (I should note that the drive itself is not going bad—it's just the sounds the heads make when seeking across the platters).
“Click click click click”
In fact, there's an attempt right now going on as I type this, from Korea— or rather, there was an attack.
And the servers at The Office get scanned constantly. I should know, I get the multithousand line log summaries daily.
So with all that in mind, I'm trying to cobble up a LeBrea Tarpit system at The Office. Legal disclaimers on the site aside, it's still available and in checking the rather loathsome Florida's Super DMCA Act, I think legally we can run it—we're not a “cable operator” (¶ (1)(a) §1 §812.15, F.S.), nor are we a “communications service provider” under the definition given (¶ (1)(e) §1 §812.15, F.S.), nor do we provide a “communications service” under the given definition (¶ (1)(d) §1 §812.15, F.S.). And even if we are classified as a “cable operator” (and really, the definition screams “television broadcasting”), then it falls under ¶ (2)(a) §1 §812.15, F.S.:
(2)(a) A person may not knowingly intercept, receive, decrypt, disrupt, transmit, retransmit, or acquire access to any communications service without the express authorization of the cable operator or other communications service provider, as stated in a contract or otherwise, with the intent to defraud the cable operator or communications service provider, or to knowingly assist others in doing those acts with the intent to defraud the cable operator or other communications provider.
See … we are the communications service provider in that case. We're not out to defraud ourselves! We gave ourselves permission!
And it's not entrapment. LeBrea isn't simulated a poorly administered
system just waiting to be hacked. It just accepts TCP connections and keeps them on hold (as it were)
indefinitely. It's not violating the letter of the TCP specification (it could be argued it's
violating the spirit of the TCP specification, but really, what jury will want to spend
time listening to geeks pontificate about the finer points of dogmatic
religious theology TCP connection semantics?
