I have been receiving some major ssh brute-force attacks coming from random
hosts in the 116.8.0.0 - 116.11.255.255 network. I have sent a complaint to
the e-mail addresses obtained from a whois query on one of the IP Addresses.
My e-mail bounced back from both recipients. Once being rejected by filter
and the other because the e-mail address doesn't exist. I would have
thought that contact details are rather important to be up to date, or not?
Besides just blocking the IP range on my firewall, I was wondering what
others would do in this case?
I have been receiving some major ssh brute-force attacks coming from random
hosts in the 116.8.0.0 - 116.11.255.255 network. I have sent a complaint to
the e-mail addresses obtained from a whois query on one of the IP Addresses.
My e-mail bounced back from both recipients. Once being rejected by filter
and the other because the e-mail address doesn't exist. I would have
thought that contact details are rather important to be up to date, or not?
Besides just blocking the IP range on my firewall, I was wondering what
others would do in this case?
Regards, Gabriel
I no longer try to send notices to network operators that don't publish
a working abuse mail address for the netrange assignment or the SWIP.
For the best-practices-clueless, I just round-file them when I see
attacks above a certain level. Ditto mail attacks, particularly from
netranges/servers that don't have working postmaster@ addresses or MX.
(I'm considering adding a separate network ACL for SMTP/SUBMISSION in my
mail servers, but so far all the verifiable mail abusers have had other
bad habits, too.)
From my firewall generator's "kill network" list:
116.10.191.0/24 china ssh abuser 2014 August
That entry went into the ACL six months ago, but it's only recently that
I started dating the entries.
I now have canaries (tcpwrappers, logwatch) in four systems on widely
separate IP netranges. Those systems have a virtually-everything-closed
firewall (IPTables, logwatch) and the resulting logs show where some of
the most vicious scans are coming from. PLONK!
My e-mail bounced back from both recipients. Once being rejected by filter
and the other because the e-mail address doesn't exist. I would have
thought that contact details are rather important to be up to date, or not?
Opinions vary. Some providers would rather just cash the customers'
checks and not waste valuable staff time on complaints in languages
they can barely read.
After you block all traffic from the network (in my experience, if
they have bogus contacts, they have nothing of interest to say), you
might send a note to APNIC telling them that they might want to note
that those contacts are invalid.
I have been receiving some major ssh brute-force attacks coming from random
hosts in the 116.8.0.0 - 116.11.255.255 network. I have sent a complaint to
the e-mail addresses obtained from a whois query on one of the IP Addresses.
My e-mail bounced back from both recipients. Once being rejected by filter
and the other because the e-mail address doesn't exist. I would have
thought that contact details are rather important to be up to date, or not?
Why?
Besides just blocking the IP range on my firewall, I was wondering what
others would do in this case?
I've been blocking SSH from random IPs for many years. Unless you have to run an open system that customers SSH into (unlikely in these times), my recommendation is block SSH entirely from non-trusted networks and setup some form of port-knocking or similar access controls such that legitimate users can open a window to make their connection, but the rest of the world never sees your sshd.
Playing whack-a-mole with firewall or access log violations is a waste of time.
I mean, a good password will require how many centuries of effort to
brute force? I've never seen a single IP (or even a range of IPs)
trying to brute force the same user account over more than a day, much
less the huge amount of time required the crack the password. Sure,
it fills up your logs, but that's good info to have and pass on (to
DShield, for example).
That’s been debated many times, in most of the RIRs, and has not resulted in any persistent policies that I remember offhand. The tide may turn, as it were, if problems get sufficiently bad, at which point these sorts of policies might receive sufficient support to be passed, and stick.
Which, of course, would not actually cause address space to be magically returned to the RIR. The RIRs are not the Internet Police and attempting to use the Whois database as a stick to beat “bad” ISPs will simply result in the Whois database becoming less and less relevant.
What might work would be for the RIRs to annotate registration data records with stuff like "valid/invalid contact information” (accessible programmatically via RDAP) and allow ISPs to build filters based on that annotation.
But yes, this has been debated many times and nothing ever seems to get done.
It really isn't the RIR's job to withdraw allocations due to bad
behaviour as much as many of us would like it to be. Failure to
maintain valid contact details however is within the purview of the
RIRs.
If you are being attacked, report the attack to your LEA. Let the
LEA's maintain intellegence on which networks are permitting attacks
to be launched from their address space. They can work with LEA
in the network's juristiction to get the attacks stops and offenders
prosecuted. LEA's can in theory also get courts to issue orders
to filter offending address blocks by all ISP's in their juristiction.
i have numerous servers that must have open ssh access to everyone in multiple datacenters for several hundred users from many different and varying origins that change frequently. whitelist/blacklisting would be a nightmare.
i use a PAM module that automatically adds every new ssh connection IP to an xt_recent blacklist, a) if you succeed authenticating, your IP is automatically removed, b) if more packets arrive that exceed the count limit within time limit for your /24, you automatically get blocked for a while.
no point wasting time managing blacklists on IPs when nearly all of them are bots and most of the service providers out there either a) don't care, b) don't have a functioning abuse/security contact, c) ignore reports, or d) helplessly clueless.
Good luck getting action from foreign LE through the mlat system
You might get a response, oh, in the next two years or so. IF you can find
local LE willing to push the case forward.
Beyond that while RIRs are not the internet police they do owe it to the
community to be more vigilant on dud contact addresses, and also do a lot^W
bit more due diligence when allocating IP space, and when appointing LIRs.
I have found the scaling is better if you make it the abusing providers problem to contact you. Whenever a range gets blocked, the bounce message tells the mail originator to take their money and find a new hosting provider that does not support/tolerate spam. When legitimate originators have contacted their provider about that message, the sources that were inadvertently hosting the abuse are happy to find out more so they can resolve the problem, and they provide a working contact in the process, even if the registered one fails.
The down side is that it requires the legitimate originator to pay attention to the bounce and decide they want to take action. The hope is that eventually more money will flow toward those hosting providers that are diligent about resolving issues.
I have found the scaling is better if you make it the abusing providers problem to contact you.
It scales BEAUTIFULLY .. until your peer in support starts to yell at
you about the off the scale ticket volume you've managed to dump on
him with your nullroute.
In other words, your abusing provider isn't as likely to contact you
as your own customers, after they suddenly have a lot of users unable
to access their service.
Whenever a range gets blocked, the bounce message tells the mail originator to take their money and find a new hosting provider that does not support/tolerate spam.
I thought we were actually talking about filtering random ssh
attempts? Oh, ok - so this discussion drifted into SMTP. Good - what
I said earlier applies earlier, in spades - end users will start to
contact your peers on the postmaster desk. So - block by all means,
but be well prepared to handle the ticket volume (and always bear in
mind your role is ALSO to deliver legit mail to your users). And for
god's sake provide proper error messages with a URL that gives
sufficient information as to why there's a block in the first place.
The down side is that it requires the legitimate originator to pay attention to the bounce and decide they want to take action.
The best solution is to enumerate the ranges from which legitimate ssh
connections will originate and firewall *everything* else. Yes, this
means (gasp! horror!) actually looking at your own logs and understanding
what they tell you, but anyone capable of using "grep", "sort", "uniq"
et.al. should be able to do that.
The second-best solution is to enumerate the ranges from which legitimate
ssh connections will never originate and firewall those. The Spamhaus
DROP list is a good starting place for everyone. The Okean listings of
Chinese and Korean network space are good second stops. And ipdeny.com
*was* a good third stop, for which I haven't found an equally-usable
replacement just yet.
Both of these are proactive approaches that -- if used properly and
well-maintained -- may largely eliminate the need to fiddle around
with reactive approaches like fail2ban. They also work with other
ports/protocols/services, e.g., IMAPS.