Hello, We got often abuse reports on hosts that has been involved in DDOS attacks. We contact the owner of the host help them fix the problem. I also would like to start send these abuse report to the ISP of the source. Are there any avaliable tools for this? Is there any plugin for nfsen? Do I need to write my own scripts for this? /Jonas
We used to use a small perl script called tattle that would parse out the /var/log/secure on our *nix boxes, isolate the inbound ssh exploits, lookup the proper abuse contacts and report them. I haven't seen anything similar in years but it would be interesting to do more than null route IPs. The problem we had with the automated reporting was dealing with spoofed sources, we see lots of traffic that is obviously hostile but unless it becomes serious enough to impact performance we rarely report it. An automated system didn't seem to fit anymore due to false positives. A number of providers who aren't exactly interested in the overall good health of the net do a poor job of network ingress filtering that unless I closely examine the traffic and it's origins. Without being able to trust the source address information in the DDOS traffic I run the risk of crying wolf to a provider who is just as much a victim as I am. (Think of my ACK packets piling in his network in response to the bogus SYN packets I'm getting). So we reserve complaints for when there is an actual impact and try to keep the signal to noise ratio in our reports decent. I'm not really happy with this approach and I'm open to ideas! Thanks Sam Moats On 2013-11-12 16:58, Jonas Björklund wrote:
Hello,
We got often abuse reports on hosts that has been involved in DDOS attacks. We contact the owner of the host help them fix the problem.
I also would like to start send these abuse report to the ISP of the source.
Are there any avaliable tools for this? Is there any plugin for nfsen?
Do I need to write my own scripts for this?
/Jonas
On 12 November 2013 22:52, Sam Moats <sam@circlenet.us> wrote:
We used to use a small perl script called tattle that would parse out the /var/log/secure on our *nix boxes, isolate the inbound ssh exploits, lookup the proper abuse contacts and report them. I haven't seen anything similar in years but it would be interesting to do more than null route IPs.
We also used to have a script which did something similar but for more than just inbound ssh, for the most part this was ineffective. D. blaze your trail -- Daniël W. Crompton <daniel.crompton@gmail.com> <http://specialbrands.net/> <http://specialbrands.net/> http://specialbrands.net/ <http://twitter.com/webhat> <http://www.facebook.com/webhat><http://plancast.com/webhat><http://www.linkedin.com/in/redhat>
On Tue, Nov 12, 2013 at 4:52 PM, Sam Moats <sam@circlenet.us> wrote:
We used to use a small perl script called tattle that would parse out the /var/log/secure on our *nix boxes, isolate the inbound ssh exploits, lookup the proper abuse contacts and report them. I haven't seen anything similar in years but it would be interesting to do more than null route IPs.
The problem we had with the automated reporting was dealing with spoofed sources, we see lots of traffic that is obviously hostile but unless it becomes serious enough to impact performance we rarely report it. An automated system didn't seem to fit anymore due to false positives.
Hi Sam, Out of curiosity -- how does one get a false positive on an ssh exploit attempt? Does the origin IP not have to complete a 3-way handshake before it can attempt an exploit? Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
Your right they wouldn't get all of the way through. The three way handshake is great against blind spoofing attacks. That said the original poster was focused on a DOS event,to do that you really don't need the full handshake. I'm not sure if the end goal of whomever we were dealing with was to DOS us or if was some screwed up half open syn scans, or my personnel guess it was to generate enough bogus log traffic to hide which connections were legitimate threats. Either way enough inbound SYN connections on port 22 would tip over the servers, this was LONG ago circa 97~99, so the traffic we saw was an effective DOS. We had inetd calling ssh and also telnet (Change comes slowly and cyrpto was painful to implement for us at the time). In our setup inetd decided to log the sessions both ssh and telnet as soon as the daemon was called. So even if we didn't do the full session setup the machine would still log an event for each tcp session. In hindsight we could have cleaned it up so that it wouldn't log before completing the handshake or tweaked the perl script to filter them out but I was a newbie at that point and placing ACLs in my border router to drop inbound ssh traffic that didn't come from netblocks I expected and moving off of the default port were the easiest solutions at the time. Now it would be trivial to setup syslog and sshd to give only the sessions that complete the handshake, however I'm also not sure how responsive some of the abuse contacts may be. I'll keep my restrictive network settings for the time being. Sam Moats On 2013-11-12 20:43, William Herrin wrote:
On Tue, Nov 12, 2013 at 4:52 PM, Sam Moats <sam@circlenet.us> wrote:
We used to use a small perl script called tattle that would parse out the /var/log/secure on our *nix boxes, isolate the inbound ssh exploits, lookup the proper abuse contacts and report them. I haven't seen anything similar in years but it would be interesting to do more than null route IPs.
The problem we had with the automated reporting was dealing with spoofed sources, we see lots of traffic that is obviously hostile but unless it becomes serious enough to impact performance we rarely report it. An automated system didn't seem to fit anymore due to false positives.
Hi Sam,
Out of curiosity -- how does one get a false positive on an ssh exploit attempt? Does the origin IP not have to complete a 3-way handshake before it can attempt an exploit?
Regards, Bill Herrin
On Tue, Nov 12, 2013 at 9:07 PM, Sam Moats <sam@circlenet.us> wrote:
That said the original poster was focused on a DOS event,to do that you really don't need the full handshake.
Point. Though not all DDOSes are created equal. The simple packet flood is, as likely as not, from forged addresses. But I've also seen DDOSes which make repeated HTTP GET requests. That's tough to do without control of the source address.
Now it would be trivial to setup syslog and sshd to give only the sessions that complete the handshake, however I'm also not sure how responsive some of the abuse contacts may be. I'll keep my restrictive network settings for the time being.
That's the main problem: you can generate the report but if it's about some doofus in Dubai what are the odds of it doing any good? Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Tue, Nov 12, 2013 at 10:03 PM, William Herrin <bill@herrin.us> wrote:
Now it would be trivial to setup syslog and sshd to give only the sessions that complete the handshake, however I'm also not sure how responsive some of the abuse contacts may be. I'll keep my restrictive network settings for the time being.
That's the main problem: you can generate the report but if it's about some doofus in Dubai what are the odds of it doing any good?
And then we're right back to sending the offending packets to a black hole. *sigh*
On Nov 12, 2013, at 9:16 PM, Brandon Galbraith <brandon.galbraith@gmail.com> wrote:
On Tue, Nov 12, 2013 at 10:03 PM, William Herrin <bill@herrin.us> wrote:
Now it would be trivial to setup syslog and sshd to give only the sessions that complete the handshake, however I'm also not sure how responsive some of the abuse contacts may be. I'll keep my restrictive network settings for the time being.
That's the main problem: you can generate the report but if it's about some doofus in Dubai what are the odds of it doing any good?
And then we're right back to sending the offending packets to a black hole. *sigh*
a packet that you can drop quickly is a packet you don’t have to think about.
On 2013-11-12 16:58, Jonas Björklund wrote:
Hello,
We got often abuse reports on hosts that has been involved in DDOS attacks. We contact the owner of the host help them fix the problem.
I also would like to start send these abuse report to the ISP of the source.
Are there any avaliable tools for this? Is there any plugin for nfsen?
Look at anything related to IODEF, specifically the CIF implementation: https://code.google.com/p/collective-intelligence-framework/ Greets, Jeroen
On Nov 12, 2013, at 3:58 PM, Jonas Björklund <jonas@bjorklund.cn> wrote:
Hello,
We got often abuse reports on hosts that has been involved in DDOS attacks. We contact the owner of the host help them fix the problem.
I also would like to start send these abuse report to the ISP of the source.
Are there any avaliable tools for this? Is there any plugin for nfsen?
Do I need to write my own scripts for this?
/Jonas
You could send the info to DSHIELD. Then they might notify the ISP if you enabled “Fightback”. http://dshield.org/howto.html http://dshield.org/fightback.html --- Bruce Curtis bruce.curtis@ndsu.edu Certified NetAnalyst II 701-231-8527 North Dakota State University
participants (9)
-
Brandon Galbraith -
Curtis, Bruce -
Daniël W. Crompton -
Jeroen Massar -
joel jaeggli -
Jonas Björklund -
Randy Bush -
Sam Moats -
William Herrin