SysAdmin tasks - fending off crackers
April 7, 2017
My sysadmin work can probably be boiled down to three or four categories. Of course there is software upgrades and rebooting, as well as researching things like email problems and configuration problems, but the two biggest daily chores are dealing with crackers and spammers. I will deal with the other subjects in other posts, but for this post, I will concentrate on attempted cracks on my and my clients’ servers.
My primary tool for dealing with crackers is
works by monitoring specific logs for authentication failures. If a
machine at a given IP tries and fails to authenticate N times in X
minutes, it is blocked (usually using iptables) for y minutes, and if
so configured, sends me an email about it. The email contains the
results of a
whois query for that IP. I have a script that I use to
scan the related log for that IP and then sends a boilerplate
complaint to the applicable network admin.
One of the nicest features in Fail2Ban is the “recidive” jail. Many cracker bots get blocked the first time, and then wait for the f2b block to timeout, and then hit it again. If allowed to continue, they will go on until the world looks level or they guess a username/password. If recidive detection is turned on, the blighter will be put in the recidive jail and be blocked for a week.
The skeptic will say that’s like peeing in the ocean. Sometimes I get back an auto-reply, sometimes a response like, “We have shut down the offending machine”, sometimes an NDR (non-delivery report), sometimes nothing. When I get an NDR indicating that there is no working POC email, I block that whole network for a month if it’s outside the US and Canada. If it’s inside the US or Canada, and there is a telephone contact, I will call them to advise them of the crack attempt and that the email notification failed. If it’s still a working ISP, I usually get an alternate email address to send the information. Sometimes the ISP has changed hands and not changed their contact information, or simply gone under. If I get no satisfaction there, I block them for a month.
A few registries, APNIC in particular, have a link where you can report inaccurate whois information. I use that for NDRs reporting “lost connection” or “recipient unknown”, but never for “mailbox full”. There are several POCs in China whose mailboxes are perennially full. I don’t report them. I just block their networks, again, just for a month.
In the case of NDRs with “recipient unknown”, sometimes I forward the NDR to the postmaster address they are supposed to have with the note:
Please fix your mail server. Internet standards (RFC-2142) say you should have an advertised, working “abuse” mailbox.
But of course, those frequently bounce back with “recipient unknown” NDRs. A working postmaster email is one of the other things strongly recommended by RFC-2142. Well, it’s worth a shot.
Let’s talk about whois contact email addresses. These should always be generic “firstname.lastname@example.org” and “email@example.com”, plus other generic terms like “noc” or “admin” and the like. It should never be the specific individual’s address for several reasons. First, the abuse and postmaster addresses should be aliased to two or more real admins in your mail server. That way, if one of them goes on vacation, someone will get the email. Don’t get me started on vacation autoresponders. Second, personnel may come and go. If you have firstname.lastname@example.org listed in your whois, and he moves on, you now need to update your whois information which is likely much more difficult than modifying the aliases file in your mail server.
I hope these tips are helpful to you either as a consumer of whois
information, or as an IT person in your company. As always, send me
an email with any questions or comments. And, of course, flames and