Ask Slashdot: Where To Report Script Kiddies and Other System Attacks? 241
First time accepted submitter tomscott writes "So I've been using using Linux for over ten years now and I'm sure like most Linux users I've got SSH running on my box and port 22 open on my cable modem so that I can access my system no matter where I am. Over the years I've seen people try to gain access to my system but — knock on wood — I've never had a breach. What I am wondering: Is there a website where I can report these attempts and even supply the details of where the break-in attempt originated from?" The FBI is interested, but probably only if you've actually suffered a loss.
Not like most linux users! (Score:3, Informative)
I have a vpn like most sane people. Leaving port 22 open is just asking for abuse.
Re:Not like most linux users! (Score:5, Insightful)
And which protocol/port does your VPN listen on?
Because that's just asking for abuse...
Captcha: insults
Re:Not like most linux users! (Score:5, Insightful)
Wouldn't you like to know...
Seriously, don't use the default port for any service you don't have to. It will drastically drop the number of attempts. Most kiddes out there seemingly don't know about more sophisticated scripts that can identify services on non default ports.
Re:Not like most linux users! (Score:4, Funny)
Yes, security through obscurity is the best method.
Re:Not like most linux users! (Score:5, Insightful)
Re:Not like most linux users! (Score:4, Funny)
Nuh uh!!! He parroted the 'security through obscurity' soundbite and automatically wins the debate!! Just like saying 'correlation is not causation' soundbite. He fucking pwned j00!!!
On the other hand, in the real world like you mention secrecy can be a good line of defense as long as it is not the only line of defense.
Re:Not like most linux users! (Score:5, Insightful)
No one is owned until Godwin comes out. Only Hitler would say differently.
And yes, "security through obscurity" is a layer in a sound defensive strategy. If no one knows you are there, they don't know to start trying to attack you. If anything, it shrinks the size of your logs.
Unfortunately, if an attacker is looking for you and already knows your service is there, you'd better have a more reliable defensive plan available.
Re: (Score:3)
Re:Not like most linux users! (Score:4, Insightful)
This. I mean, you could argue that even passwords are, in a way, security through obscurity.
Re:Not like most linux users! (Score:4, Insightful)
Re: (Score:3)
Re: (Score:2)
Security through obscurity is "necessary but not sufficient" in many real world defense-in-depth strategies. It's one layer in a strategy that is adequately secure without it but more secure with it.
In OP's case, putting ssh on a different port reduces his effective attack surface. Most attackers don't even find the port let alone send ssh protocol packets, reducing the probability of breach.
Re: (Score:3, Insightful)
In Bruce Schneier's own words [schneier.com]:
Just because security does not require something be kept secret, it doesn't mean that it is automatically smart to publicize it.
You might want to actually read and digest the first article on that page before spouting off again.
Re: (Score:3, Informative)
Security thru absurdity is just crazy enough to work
Re:Not like most linux users! (Score:4, Insightful)
Not to mention that if you do what some people do and move services like sshd to another port you may actually create a security problem.
If you've got sshd running on any port > 1024 then an attacker who can gain regular unprivileged user access to the system and is able to crash your sshd can replace it with his own sshd. If it's running on port 22 (since you should never "steal" a port under 1024) then the attacker needs root access to accomplish the same trick.
Besides, it's not particularly hard for an attacker to scan a system from multiple hosts, there's a finite number of ports for you to "hide" your services on and all it takes is a bit of patience to find your "hidden" services.
Re:Not like most linux users! (Score:5, Informative)
Most kiddes out there seemingly don't know about more sophisticated scripts that can identify services on non default ports.
I doubt they care, there are enough exploitable targets. The automated scripts scan _many_ IPs for a few ports. Having them scan more ports would take longer and slow the spread.
Despite what many say, there is some security through obscurity. It's a case of only having to outrun your neighbour and not the bear.
The other advantage is if you use an obscure port, if someone does try it and brute force etc, you can consider it more seriously - someone might actually be trying to hack you specifically.
Re:Not like most linux users! (Score:5, Interesting)
Most idiots just parrot the 'security through obscurity' thinking it's some compelling argument when it's really not. If the basis of your security is entirely reliant on the obscurity of your algorithms, etc. being private then it is bad. But using some level of secrecy as a first line of defense can be quite useful in preventing attacks.
Even Bruce Schneier does not take the black-and-white stance that the Internet 'experts' do. He is actually quite pragmatic about acknowledging that there is a continuum of secrecy requirements based on the system at hand, but mentions that relying too much on secrecy makes the security of the system more fragile. These Internet 'experts' need to actual read what people like Bruce say rather than just repeating stupid sound bite pieces.
Re:Not like most linux users! (Score:5, Interesting)
Duh? In this case, since he is being port scanned by what is most likely Chinese script kiddies moving the port will stop probably 99% of them. No one said such things will prevent any possible intrusion, but it's an easy and cheap way to prevent the vast majority and causes no compromising to the underlying system. For the determined people who get arou d that you layer on top other defenses such as ony allowing a certain amount of attempts before locking out/banning, only allowing retries after some certain length of time, etc. If all these fail, you still haven't compromised the underlying system but you've severely limited the amount of people who would be successful in attacking you.
Re:Not like most linux users! (Score:5, Insightful)
No, it's not at all alike because the bear is going to eat one of you: whichever one it catches first. The script isn't going to compromise one box, it's going to compromise every single one that's vulnerable to whatever exploit(s) it's using in the IP ranges it's scanning.
To put it another way, it's not the bullet with your name on it you have to worry about. It's the 20,000 or so odd rounds labelled "Occupant".
Re: (Score:3, Informative)
"t's a case of only having to outrun your neighbour and not the bear."
Grizzlies alone can run up to an hour at 30MPH, no way in hell any human outrun a bear. Just needed to point that one out.
Re: (Score:3)
"t's a case of only having to outrun your neighbour and not the bear."
Grizzlies alone can run up to an hour at 30MPH, no way in hell any human outrun a bear. Just needed to point that one out.
Er, the point is that if the grizzly catches your neighbur, he will presumably stop and have a bit of quality snack time, by which time you have a head start, and can find shelter, a big gun or something.
Re: (Score:2)
I wish I could mod you +1 more!
So often, people say "security through obscurity" as though it were somehow diseased. True, you should *never* rely on security through obscurity, but it *is* a form of a secret, and secrets are fundamental to the concept of security. Granted, you should never count on this as your ONLY form of security, but using non-standard ports for important services is a useful first step to mitigating security vulnerability as part of a continued process to minimize your security footpr
Re: (Score:2, Informative)
Re:Not like most linux users! (Score:4, Informative)
Port knocking is less useful now that many corporate environments restrict outbound tcp ports.
Re:Not like most linux users! (Score:4, Insightful)
Nope. Defeating port knocking is easy - just knock all the ports a few times and it opens up. (Alternatively, if your knock scheme demands a specific order, I can keep you out indefinitely by knocking some wrong port continously.)
And even when it works, the obscurity is only equivalent to a few more characters in the password.
Since there are 2^16 ports, each port is equivalent to 16 bits of password entropy (depending on how long it takes to test a port versus test a password).
If it takes 3 knocks to get in (i.e. knock 2 ports, then find the open port for the service you're looking for), that's equivalent to 48 bits of password entropy, or around 8 additional alphanumeric password characters.
Lock out an IP from unlocking the port after a few unsuccessful knocks and you pretty much eliminate any chance of brute force attack. You can try to attack from different IP addresses through a botnet or spoofing, but with 48 bits of entropy and less than 32 bits of IPv4 addressess to choose from, there aren't enough IP's to brute force.
Re:Not like most linux users! (Score:5, Informative)
Why?
Fail2ban will block these bots (usually, ssh bruteforce attacks are the result of worms rather than actual script kiddies manually running them) from sshing into your system after a few failed attempts.
SSH-key only access will increase security by an order of magnitude. A bruteforce against a public-key only SSH server is untenable. Their script likely doesn't even support ssh keys and will just get kicked out with a protocol mismatch error. These attempts are meant to get in via password authentication, default credentials or weak passwords.
If you have SSH on any port exposed to the internet w/o fail2ban and/or ssh-key only access, you're asking for trouble. I've seen it happen on numbers of boxes with strong passwords for users -- eventually, they get in...
Re: (Score:2)
Most kiddes out there seemingly don't know about more sophisticated scripts that can identify services on non default ports.
Or they're scanning entire class-B's at a time, and don't find your network interesting enough to slow down their scan to make an exhaustive search for exploitable services, on the reasoning that anyone clever enough to put them on non-standard ports is probably also updating your packages on a somewhat regular schedule?
If there's any particular reason to want to compromise your box instead of someone else's then perhaps a full portscan and protocol probe is in order, but doing that to every host you scan w
Re: (Score:2)
I use port 22 because some places block that port and don't want have to go to another box, or set up proxies. I do use DenyHosts [sourceforge.net] to block attackers after three failed attempts.
Re: (Score:2)
It will drastically drop the number of attempts.
Although this is a nice practice to keep your service off-the-beaten-path, it is still wise to monitor the connection logs and be able to recognize when an attack is happening. Too many people run their services on 5 digit ports expecting them to be "hidden" and it just doesn't work that way. Oftentimes, attackers will log connection banners and log them, only to come back later with a known exploit or 0-day. In this case it doesn't matter what port you listen on.
Attackers have all the time in the world
Re: (Score:2)
Re:Not like most linux users! (Score:4, Insightful)
Run OpenVPN on any udp port using the tls-auth option to drop unsigned packages. Use iptables to drop all other 65534 ports. Good luck finding out which port is the VPN server.
Re: (Score:3)
And which protocol/port does your VPN listen on?
Because that's just asking for abuse...
Captcha: insults
I get the best of both worlds: my ssh tunnel listens on port 1723 :) It requires a key-based login and doesn't announce.
My firewall still logs connection attempts on port 22 however; they just don't get anywhere (I redirect port 22 to an internal computer on a port that isn't listening, so the router gets all the information, but the attacker gets zilch -- this allows me to easily set up a honeypot from time to time when I'm curious what the script kiddies/bots are really after).
Re:Not like most linux users! (Score:4, Informative)
I have a vpn like most sane people. Leaving port 22 open is just asking for abuse.
Just configure SSHD to accept only SSH Keys (no password login) and 99% of the problem is solved.
Re:Not like most linux users! (Score:4, Informative)
Put something like denyhosts or fail2ban on top of that and you're even more safe.
This is what I was going to post... (Score:4, Informative)
I run OpenVPN on one of my OpenBSD machines on a non-standard port, it's the only way to get in through my firewall (another OpenBSD machine). Once I've made my vpn connection, I can then ssh to the other machines on the network.
To the question at hand, if you can identify the ip address that the breach originated from, plug it into Network Solutions' whois lookup and you can usually find the ISP the ip is connected to. They usually have an abuse email account listed in their whois info. If they don't have info, try plugging the ip into RIPE or APNIC's whois database and report accordingly.
Re: (Score:2)
Re: (Score:2)
Ok, how how about moving whatever service you are using to an obscure port, then using iptables to log all attempts at the default port.
The question remains the same, your answer isn't helpful.
Re:Not like most linux users! (Score:4, Interesting)
Leaving port 22 open is just asking for abuse.
Not really, no. If you lock down SSH sufficiently, then it's pretty much bulletproof.
1. Lock down specific users@ip to be able to ssh in.
2. Enforce privilege separation and all the other paranoid protection in the sshd_config.
3. Put in some type of brute force protection like fail2ban.
4. Enforce non-dictionary passwords.
Problem solved.
Re: (Score:2)
I have also disabled password based logins but for one user. You never know when you're going to need to get in without a key at hand.
This user has a 18chars password that is nowhere near containing anything in any dictionary I know of. Punctuation, digits, letters, etc.
Re: (Score:2)
All this does is discourage the lower-level bots, and decent passwords thwart those. A directed attacker will still find it, and is more of a threat anyways.
It's not a bad idea - just don't rely on it.
Re: (Score:3)
All this does is discourage the lower-level bots, and decent passwords thwart those. A directed attacker will still find it, and is more of a threat anyways.
It's not a bad idea - just don't rely on it.
Actually it does more than discourage lower-level bots - it keeps your logs clear enough so that when you do get something in your logs you can be pretty sure it's not a bot.
Re: (Score:2)
I have a vpn like most sane people.
Does your VPN have PPTP enabled, like most sane VPNs? FYI, Sanity is relative. [theregister.co.uk]
I had my doubts as to the security after I read MS's shitty MS-CHAP2 protocol, and now it's completely broken. If I have a question like, "Wait, how secure is that really?" I don't use said "security".
If you don't understand cryptography at an intimate level you're just making guesses as to what's secure or not. You might as well just have port 22 open, it's not like most folks even understand how their VPN or SSH security
Re: (Score:2)
I have a vpn like most sane people. Leaving port 22 open is just asking for abuse.
I think actively blocking attackers with something like fail2ban [fail2ban.org] is at least as good as an additional standard VPN or using non standard ports.
Re: (Score:2)
That is preposterous. You are implying that a VPN is more secure than SSH ... and considering the best way to setup a vpn-like environment is to tunnel it over SSH, your argument is obviously invalid. Pay attention: SSH is the most secure service to have ever existed, and statistics are on my side. If you want to avoid all the unwanted traffic from scripts testing default passwords, switch ssh to another port.
BTW: VPNs suck. If your setup requires a VPN, then it's time to rethink your architecture.
Re: (Score:2)
This can also be rigged up in iptables using an ipset/recent/etc. Works pretty well, and keeps less state.
Re: (Score:2)
Denyhosts does it via /etc/hosts.deny though - leaving the firewall alone and squishing them with tcpwrappers.
If you've got a cumbersome iptables, this may be more performance friendly than constantly adding/removing rules.
Re: (Score:2)
Fail2ban is quite flexible - but I prefer denyhosts myself.
Pointless (Score:5, Insightful)
The attackers are most likely using other infested machines.
Re: (Score:3)
Indeed, most attackers are. But even then, you can report them to the IP block owner, so they can fix the problem.
Unfortunately, most providers are part of the problem instead of part of the solution: they do nothing with abuse reports. At least the ones i've contacted.
From my understanding (Score:5, Informative)
The cyber police! (Score:5, Funny)
Re:The cyber police! (Score:5, Funny)
To do that, he'd have to write a GUI in Visual Basic.
Re: (Score:2)
You just talked me out of it.
Re: (Score:2)
Re: (Score:2)
or he could just use the "hack /off" command at the DOS prompt.
Re: (Score:3)
The consequences will never be the same!
Re: (Score:2)
Dude, I am so NOT going down that tubes!
Use key-based security (Score:5, Informative)
Re: (Score:2)
It's also dangerous in that any theft of your plaintext key from one of your clients could go quite unnoticed. So then you have to password protect your key, making it no more convenient, or you just accept risk equivalent to putting your password in a text file on a networked machine named HERE_ARE_MY_PASSWORDS.txt.
Compared to just choosing a very good password, and changing it once in a while, I find that to be an inferior strategy.
Report it to DShield.org (Score:5, Informative)
"Random" attacks can be reported to DShield.org . They have a number of scripts to automatically submit firewall logs (including from Linux firewalls). See http://www.dshield.org/howto.html [dshield.org] . Once set up, it just "runs" and DShield aggregates the data, uses it for research and reports worst offenders to ISPs and other contacts.
Re:Report it to DShield.org (Score:5, Funny)
Well, after looking at your post, your sig, and your usename, I conclude that you likely wept with joy when you saw this particular ask slashdot. Must feel good to finally hit that perfect slot of relevance.
These days, the attackers are innocent (Score:5, Insightful)
I think (I have no actual numbers) most of those are compromised boxes running distributed attack scripts. It makes sense to run the C&C, and let your zombies to the work that way it doesn't get tracked back to you.
That was the case I saw twice on two boxes I had - one fell to a BIND exploit, and rather than reboot, I investigated why DNS stopped working. I uncovered a IRC C&C (with over 60 clients) and went about informing people (by the IPs of the irc clients) about what had happened. Most rebooted and never noticed a thing. All were happy to hear I was letting them know what happened.
Based on that you're more likely to report innocent people whose only crime is being unpatched.
Re: (Score:2)
These days? I think this has been true for quite a while. I have found similar things. Hell, one of the first tasks in my entire career was to investigate a similar incident...
We found that a professor, who was known to telnet in from international IPs while on break, had SOMEHOW had his password stolen (gee I wonder if it could have been because he used telnet even though we had ssh available? sigh...)
Someone had installed an IRC proxy, and so I got the job of running packet sniffers and watching the IRC c
Re: (Score:2)
I run a web forum. Our admin control panel is constantly being bombarded with attempted logins (none of them successful so far, knock on wood)
Our logs show the attacker's IP plus the user account they tried to log in as. They are all valid forum administrator/moderator names. So the attacker isn't some random distributed script, somebody actually read the forum and gleaned our staff member names.
The attackers' IPs don't match anything in our database, so it's most likely not a disgruntled user. A lot of it
You can report them to DHS (Score:3, Informative)
http://www.dhs.gov/how-do-i/report-cyber-incidents
Re: (Score:2)
http://www.dhs.gov/how-do-i/report-cyber-incidents
I wouldn't hold your breath for a response. Let's use a car analogy. Last year, my car got stolen. I filed a report with the police department. They put it in a database. Eventually, my car turned up in a parking lot missing a few parts with a high value to removal effort ratio. And they called me because the apartment manager called them. But they didn't look for the car. And they didn't look for whomever took it after it was recovered. Because they don't give a shit. Because they don't even have
abuse@organizationname.com (Score:4, Informative)
It's been years, but a few times I found the organization sending traffic and sent an email to abuse@
the domain name and had positive results.
You can look up the whois online registry information on where the traffic is coming from, and there can be additional contact information there.
Regards,
Sam
If you know where the breaking occured from (Score:2)
A thought (Score:2)
Re: (Score:3)
Yep easy and very effective if set up properly. A big mistake a lot of people make though is to allow a differing number of attempts for existing and nonexistent users. This makes it possible to brute-force valid usernames.
What is your goal? (Score:3)
The answer depends on what you do hope to achieve by reporting.
If you hope the people to stop:
In case the origin is a company within you country, contacting them may you do some good. They will pull the plug on their malware infested machine. Attacker will use others.
In all other cases the only chance to have any kind of effect is to report dramatic damages to the law enforcement. Other than that, nobody cares enough ;-). Even with dramatic damages, the chances for any effect are slim to none.
IMHO: In 90+% of all cases the answer is /dev/null the economical best answer.
Reporting to the FBI gets complicated, when . . . (Score:5, Funny)
. . . the FBI are the ones trying to break into your system.
Re: (Score:2)
It becomes even more complicated when the IP connecting to you belongs to a honeynet hosted by some investigatory body.
Generally, nowhere (Score:3)
The one exception I make is if it comes from an American IP address. Most American ISPs do a pretty good job of tracking who is using what IP address and can do something about it. Generally, they won't do much - and they seldom tell you what they do - but they'll at least look at it. And of course if it is from a university in the US, they'll usually track it to a college freshman who either thinks he's clever or is running a compromised windows PC.
But in general, your complaints will fall on deaf ears. Just keep checking your logs periodically to make sure nobody succeeds and that you are making the right responses to new methods. You could set up a tarpit if you like...
Waste of time... (Score:5, Informative)
Make sure you have good passwords, know what ports are exposed, and run something like fail2ban [fail2ban.org].
/dev/null (Score:5, Funny)
Share your logs with the community (Score:3)
Join and contribute ssh/firewall logs to DShield or another collaboration system so that others can benefit from the information you are collecting.
http://dshield.org/howto.html [dshield.org]
If you want to report unwanted activity against your network your ISP may be able to help. Try opening a ticket with their Abuse team.
Report them to your black list.. (Score:2)
Where to report script kiddies? (Score:3)
Where to report script kiddies...
Their mothers. Duh.
How to secure your system (Score:2)
Use something like blockhosts to deny connections to addresses that have repeated unsuccessful attempts.
Use public key/private key pairs for authentication and disable password authentication completely.
Use a non-standard port for the ssh service.
Who to report them to? Unless you're actually compromised and suffer harm, there really isn't anyone who is going to look into it; seriously, reporting every potential attacker results in nothing more than a very large scale game of whack-a-mole.
Try this (Score:4, Informative)
Try psad. I've been running it for years, in addition to selinux and iptables. It auto-drops all kinds of connection attempts based on parameters you can set, but the defaults are very reasonable. Works for all connections, not just ssh. It can report to D-Shield.org and ISC (internet storm center), and you can script attack responses with your normal shell. *very* highly recommended.
I test it from time to time with nmap and nope, it doesn't allow nmap to get anything.
http://cipherdyne.org/psad/ [cipherdyne.org]
Report to... (Score:2)
...Anonymous. Enjoy watching one group of puerile script kiddies attack another group of puerile script kiddies.
Alternate answer #1 ...nowhere. If they get in, they just did you a favor by exposing your weaknesses.
Or so goes the argument as to why Anonymous is/are heroes. Hey, what's good for banks is good for individuals, right?
Alternate answer #2 ...nowhere. Who cares? All they're going to do is copy information off of your hard drive - it's not like it actually means anything, you still have your origina
Email to the netblock owner (Score:3)
Worked well when we used it. Email to the network owner, log excerpts, etc; they found machine and fixed it. One was in Italy at some university, they were really cool, emailed us back and everything. Didn't work all the time, but you would be amazed how well a nice note to the network folks works. They don't want to pollute the net; they are much like you in that way.
andy
Short answer: Nowhere (Score:3)
Long answer: Even if you did report them to someone, no action whatsoever will come out of it. Face it, as long as people are not responsible for their traffic (unless, of course, said traffic constitutes a copyright infringement) nothing will happen.
Don't worry... (Score:2)
Attempted script kiddie attacks are automatically reported to the same place that failed sudo attempts are reported to.
I now only report the perisistent idiots (Score:2)
Automate it i run failtoban which can be nicely configured, kiddies probing the websites for php_my_admin thing get mod_spamhaus checks who if reported get no site. Html form scanners get botscout checks and also a humorous email address in the html to send drugs deals to us which does not work. Occasionally we change that just for a laugh when we see it in use.
We still report spam to spamcop.
Yes i will cancel your air travel arrangements if you put the wrong address in the airline booking system. Airline
Almost nobody cares (Score:5, Informative)
Not that other countries agencies are any better. We had big trouble with a guy in New Zealand disrupting services, phishing accounts etc. We managed to start an investigation (or so they said) by phone but it took several hours and help from the CERT team in Australia. After a month nothing had happened, and I was there on vacation. I spent a day on the phone trying to find somebody who knew about the case, but even with the reference number they could not do anything. CERT Australia tried for a few days, and finally gave up.
We had a guy in the Netherlands who phished hundreds of accounts, and still nobody down there would pick the ball. Then he and a friend found a hole in a third party system and managed to suck out data for hundreds of (dutch) people. The web frontend was in Germany and the third party application in the US (A lot more US citizens data was also stolen). Dutch police said they won't do anything because the data was abroad. German police said they won't do anything because the guy is in the Netherlands. The FBI said they'll look into it, but never did anything despite us trying to get back to all of them countless times. We found both hackers identities and had the second guy on the phone, admitting everything and promising he'd testify... Still nobody was interested.
You have to work in a big corporation to get the authorities to do anything. They don't care if somebody phishes thousands of accounts unless it's in the news or a corporation they recognize. It's almost as if they want all the script kiddies to be able to practice in peace until they really learn how to cover up their tracks and move to juicier targets if they won't take a case when it's handed to them on a platter with clear logs and a confession. It does work a lot better when the hacker is in the same country as you and you are working with a local law enforcement agency though. I also had good experiences with the Metropolitan Police in the UK.
The FBI is not interested. (Score:3)
They really don't care unless you can show significant damages. For $500, they will just ignore you. For $5000 in documented damages they'll take a report and file it somewhere never to be seen again. For $50k they'll actually keep your information around in case they can use you as a part of a larger case. For $500k they may take you seriously.
Citation: my own experience calling the feds when cleaning up messes.
This is probably redundant but... (Score:3)
Who to complain to: complain to the upstream. You have the IP address. Do a nslookup and traceroute and write to abuse@foo.com. However, if it's just the standard "checking default passwords" deal, then it's a botnet and you shouldn't bother.
Here's what you do in sshd.conf
Take sshd off port 22 and put it on a high port above 1024. I use HF radio frequencies to remember.
Port 3898 (or whatever)
Turn off password authentication. You should be using keys.
PasswordAuthentication no
Use protocol 2
Protocol 2
Turn off root login.
DenyUsers root
PermitRootLogin no
??????
Profit. You're done. Really.
If you want full paranoia mode belt-and-braces so your pants don't fall down, install fail2ban, but if you have done the above, you don't really need it.
The logs go silent and they have to do a full portscan to even find ssh. Brute force ssh bots are fire and forget. The bots move along to the next guy whose sshd is on 22.
--
BMO
You doknow (Score:3)
that's the equivalent of asking where you report someone who ding dong ditched you house, right?
Reporting attack can be a useful security layer. (Score:3)
We provide instructions to our users to help them setup and manage their SSH servers: https://it.wiki.usu.edu/ssh_description [usu.edu]
We detect, document, block and report SSH portscans and SSH password guessing. We also have several SSH honeypots setup to collect lists of attack credentials. We check the honeypots to see if a USU credential has been exposed. A while ago, the FBI came by and asked about 9 IP addresses used in a hostile government sponsored attack. We were able to document that they had been detected and blocked. We were also able to provide the credentials that the attackers used.
When we first started reporting attack, the response was very poor. But now, about 1/3 of the abuse reports (to non-Chinese sources) result in confirmed, remote resolution. Now, almost all ISP's, CERTs, and large organizations are eager to receive a polite, accurate, and detailed abuse report. It is the easiest (and most common) way to learn that you have a compromised system.
As you have noticed, the hardest part is determining the proper point of contact. Most of the time, we can find one by carefully searching the whois and DNS information.
Our rational for documenting and reporting attack is given at: https://it.wiki.usu.edu/SingSingRational [usu.edu] It includes:
USU IT Security attempts to document all attacking IPs on Singsing. This accomplishes 3 primary goals:
Lately (March 2012), at least 1/3 of the abuse reports (to non-Chinese sources) appear to result in remote resolution.
In addition, documenting/blocking/reporting has important secondary benefits:
Finally, we are convinced that reporting of compromise/attack is one of the few pathways that can lead to a more secure internet.
Miles
Re: (Score:2)
Re: (Score:2, Funny)
Great Motherland of Scripted Attacks, the PRC.
Professional Rodeo Clowns? I know they're scary, but I never knew they were so evil. Or that they had a motherland, although it makes sense. They're clearly not of this world.
Re: (Score:2)
For whatever reason I haven't seen a port scan on one of my systems in a long time. But back when I did get them occasionally I'd track down the originating ISP and send their Administrator an email with the details of the incident. I usually would get an email back within a day or two saying they were looking into it.
Re: (Score:2)
Most of my attacks have come from zombies in India and Korea. I'd have to break into those compromised computers to see where the next step up in the chain is... which would make me one of the bad guys. I'm also not about to phone their ISPs (useful for places on the same continent as me though, especially if they have small netblock reservations (small company).
Re: (Score:2)
I don't get a lot of unwanted traffic.
Re: (Score:2)
IPDeny [ipdeny.com] sounds right up your alley!
Re: (Score:2)
until you try to log in using a public wifi hotspot.
Re: (Score:3)
I run some canned attacks on the offending IP if I'm bored (and not at work). Worth a shot.
Re: (Score:2)
Or at least a tarpit. Everyone should do their part by making the scripts work those few extra few seconds. At the very least it will make the coders writing them learn to do asyncronous event loops, so maybe they can go get a real job.