Dealing with abuse complaints to non-existent contacts
Hi Nanog I'm curious. 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
It would appear you've done your part in trying to reach out (and subsequently failed), so the next step to go is dropping all traffic from it. Nothing wrong with trying to protect your own customer from people who cannot be bothered to do their own due diligence. On 8/11/2014 午前 12:19, Gabriel Marais wrote:
Hi Nanog
I'm curious.
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
On Mon, 11 Aug 2014, Paul S. wrote:
It would appear you've done your part in trying to reach out (and subsequently failed), so the next step to go is dropping all traffic from it.
Nothing wrong with trying to protect your own customer from people who cannot be bothered to do their own due diligence.
It would be nice if allocations would be revoked due to invalid/fake contact info. -Dan
On Aug 10, 2014, at 1:28 PM, goemon@anime.net wrote:
On Mon, 11 Aug 2014, Paul S. wrote:
It would appear you've done your part in trying to reach out (and subsequently failed), so the next step to go is dropping all traffic from it.
Nothing wrong with trying to protect your own customer from people who cannot be bothered to do their own due diligence.
It would be nice if allocations would be revoked due to invalid/fake contact info.
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. -Bill
On Aug 10, 2014, at 2:05 PM, Bill Woodcock <woody@pch.net> wrote:
It would be nice if allocations would be revoked due to invalid/fake contact info.
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. Regards, -drc
On Sun, 10 Aug 2014, David Conrad wrote:
On Aug 10, 2014, at 2:05 PM, Bill Woodcock <woody@pch.net> wrote:
It would be nice if allocations would be revoked due to invalid/fake contact info. 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.
RBL / BGP blackholes based on bad registration info? Could work. -Dan
On Aug 10, 2014, at 1:28 PM, goemon@anime.net wrote:
On Mon, 11 Aug 2014, Paul S. wrote:
It would appear you've done your part in trying to reach out (and subsequently failed), so the next step to go is dropping all traffic from it.
Nothing wrong with trying to protect your own customer from people who cannot be bothered to do their own due diligence.
It would be nice if allocations would be revoked due to invalid/fake contact info.
-Dan
I kind of agree, but past efforts in this regard have not met with consensus from the ARIN community. If you believe this to be the case, I suggest putting it into template format and submitting to policy@arin.net. I’m happy to help if you would like. Subscribing to arin-ppml will allow you to participate in the community discussion of the policy proposal. Owen
In message <CB3CA09E-B16F-4101-AEC2-AEE12C982400@delong.com>, Owen DeLong writes:
On Aug 10, 2014, at 1:28 PM, goemon@anime.net wrote:
On Mon, 11 Aug 2014, Paul S. wrote:
It would appear you've done your part in trying to reach out (and subsequently failed), so the next step to go is dropping all traffic from it.
Nothing wrong with trying to protect your own customer from people who cannot be bothered to do their own due diligence.
It would be nice if allocations would be revoked due to invalid/fake contact info.
-Dan
I kind of agree, but past efforts in this regard have not met with consensus from the ARIN community.
If you believe this to be the case, I suggest putting it into template format and submitting to policy@arin.net.
I'm happy to help if you would like. Subscribing to arin-ppml will allow you to participate in the community discussion of the policy proposal.
Owen
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. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
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. On 11-Aug-2014 6:37 am, "Mark Andrews" <marka@isc.org> wrote:
In message <CB3CA09E-B16F-4101-AEC2-AEE12C982400@delong.com>, Owen DeLong writes:
On Aug 10, 2014, at 1:28 PM, goemon@anime.net wrote:
On Mon, 11 Aug 2014, Paul S. wrote:
It would appear you've done your part in trying to reach out (and subsequently failed), so the next step to go is dropping all traffic
from
it.
Nothing wrong with trying to protect your own customer from people who cannot be bothered to do their own due diligence.
It would be nice if allocations would be revoked due to invalid/fake contact info.
-Dan
I kind of agree, but past efforts in this regard have not met with consensus from the ARIN community.
If you believe this to be the case, I suggest putting it into template format and submitting to policy@arin.net.
I'm happy to help if you would like. Subscribing to arin-ppml will allow you to participate in the community discussion of the policy proposal.
Owen
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.
Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
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. Tony
-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Suresh Ramasubramanian Sent: Monday, August 11, 2014 11:04 AM To: Mark Andrews Cc: goemon@anime.net; nanog@nanog.org Subject: Re: Dealing with abuse complaints to non-existent contacts
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. On 11-Aug-2014 6:37 am, "Mark Andrews" <marka@isc.org> wrote:
In message <CB3CA09E-B16F-4101-AEC2-AEE12C982400@delong.com>,
DeLong writes:
On Aug 10, 2014, at 1:28 PM, goemon@anime.net wrote:
On Mon, 11 Aug 2014, Paul S. wrote:
It would appear you've done your part in trying to reach out (and subsequently failed), so the next step to go is dropping all traffic
from
it.
Nothing wrong with trying to protect your own customer from people who cannot be bothered to do their own due diligence.
It would be nice if allocations would be revoked due to invalid/fake contact info.
-Dan
I kind of agree, but past efforts in this regard have not met with consensus from the ARIN community.
If you believe this to be the case, I suggest putting it into template format and submitting to policy@arin.net.
I'm happy to help if you would like. Subscribing to arin-ppml will allow you to participate in the community discussion of the policy
Owen proposal.
Owen
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.
Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Mon, Aug 11, 2014 at 9:06 AM, Tony Hain <alh-ietf@tndh.net> wrote:
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.
I would suggest a trip to a future MAAWG meeting. --srs -- Suresh Ramasubramanian (ops.lists@gmail.com)
On 08/10/2014 08:19 AM, Gabriel Marais wrote:
Hi Nanog
I'm curious.
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. R's, John
On Sun, 10 Aug 2014, Gabriel Marais wrote:
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. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
http://www.fail2ban.org/ 2014-08-10 10:18 GMT-07:00 Jon Lewis <jlewis@lewis.org>:
On Sun, 10 Aug 2014, Gabriel Marais wrote:
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.
---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
Move ssh to a non-standart port + fail2ban - best solution. On 10 Aug 2014, at 22:20, Christopher Rogers <phiber@phiber.org> wrote:
2014-08-10 10:18 GMT-07:00 Jon Lewis <jlewis@lewis.org>:
On Sun, 10 Aug 2014, Gabriel Marais wrote:
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.
---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
Well...is it really a problem though? 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). On Sun, Aug 10, 2014 at 11:25 AM, Alexander Merniy <alexmern@xi.uz> wrote:
Move ssh to a non-standart port + fail2ban - best solution.
On 10 Aug 2014, at 22:20, Christopher Rogers <phiber@phiber.org> wrote:
2014-08-10 10:18 GMT-07:00 Jon Lewis <jlewis@lewis.org>:
On Sun, 10 Aug 2014, Gabriel Marais wrote:
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.
---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
-- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
On Sun, Aug 10, 2014 at 11:25:36PM +0500, Alexander Merniy wrote:
Move ssh to a non-standart port + fail2ban - best solution.
No, it is not. 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. ---rsk
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. -d On Sun, 10 Aug 2014, Gabriel Marais wrote:
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.
On 2014-08-10 10:19, Gabriel Marais wrote:
Hi Nanog
I'm curious.
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.
Did they have a dedicated abuse e-mail? Did you receive an automated confirmation (which generally means the communication went into some sort of ticket queue as opposed to $random_employee_malbox_who_has_moved_on . How did you format the e-mail? What information did you provide? (Folks here, what do you look for in an abuse complaint to take it seriously)? I imagine many here have template/ticket systems for abuse communications? What info do you ask for in those communications?
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?
Yes. For operators who actually care about running their networks and being good citizens. At least that's my opinion.
Besides just blocking the IP range on my firewall, I was wondering what others would do in this case?
Well of course fail2ban is always good. My personal preference is only expose HTTPS/SMTPS/IMAPS to the world. Zero management traffic on the front channel. SSH is only possible once you have connected to the VPN (which is running on 443 on another IP and is accessible without any firewall restrictions).
On Aug 10, 2014, at 8:19 AM, Gabriel Marais <gabriel.j.marais@gmail.com> wrote:
Hi Nanog
I'm curious.
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?
$ host -t txt 0.0.8.116.abuse-contacts.abusix.org 0.0.8.116.abuse-contacts.abusix.org descriptive text "18977164171@189.cn" However, I don’t see an mnt-irt: field which is mandatory for APNIC records updated/created after 2010 (unfortunately this object was last updated in 2007). So I would start by pointing to APNIC that no such entry exist and as this network is of importance for the community, the addition of an abuse/IRT POC would be beneficial for everyone and if they could help, this would be greatly appreciated. https://www.apnic.net/services/manage-resources/abuse-contacts But that’s the theory...
participants (19)
-
Alexander Merniy -
Bill Woodcock -
charles＠thefnf.org -
Christopher Rogers -
David Conrad -
David Ford -
Franck Martin -
Gabriel Marais -
goemon＠anime.net -
John Levine -
Jon Lewis -
Mark Andrews -
Mike Hale -
Owen DeLong -
Paul S. -
Rich Kulawiec -
Stephen Satchell -
Suresh Ramasubramanian -
Tony Hain