Forgot your password?
typodupeerror
Security Network The Internet IT Technology

Ask Slashdot: Where To Report Script Kiddies and Other System Attacks? 241

Posted by timothy
from the needs-a-good-whippin' dept.
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.
This discussion has been archived. No new comments can be posted.

Ask Slashdot: Where To Report Script Kiddies and Other System Attacks?

Comments Filter:
  • by Bill, Shooter of Bul (629286) on Thursday August 30, 2012 @02:42PM (#41181235) Journal

    I have a vpn like most sane people. Leaving port 22 open is just asking for abuse.

    • by Anonymous Coward on Thursday August 30, 2012 @02:44PM (#41181267)

      And which protocol/port does your VPN listen on?
      Because that's just asking for abuse...

      Captcha: insults

      • by Bill, Shooter of Bul (629286) on Thursday August 30, 2012 @02:50PM (#41181359) Journal

        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.

        • by Anonymous Coward on Thursday August 30, 2012 @02:56PM (#41181453)

          Yes, security through obscurity is the best method.

          • by localman57 (1340533) on Thursday August 30, 2012 @03:01PM (#41181533)
            Obscurity can be a layer in layered security plan. As long as the other layers aren't compromised by it in any way, it can't do any harm, and could do some good. But the other layers need to be trusted on their own. A good safe can withstand an attack for a rated amount of time even if the theives have the blueprints of the safe. But that doesn't mean you don't guard the blueprints to the safe.
          • by Spazmania (174582)

            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)

            by Desler (1608317)

            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)

            by JustOK (667959)

            Security thru absurdity is just crazy enough to work

          • by mikael_j (106439) on Friday August 31, 2012 @01:35AM (#41186849)

            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.

        • by TheLink (130905) on Thursday August 30, 2012 @03:01PM (#41181531) Journal

          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.

          • by Desler (1608317) on Thursday August 30, 2012 @03:15PM (#41181749)

            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.

          • by SecurityGuy (217807) on Thursday August 30, 2012 @03:16PM (#41181767)

            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.

            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)

            by Anonymous Coward

            "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.

            • by tehcyder (746570)

              "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.

          • by mcrbids (148650)

            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)

          by Githaron (2462596)
          Also, port knocking [wikipedia.org] can help defeat rudimentary scans for open ports.
          • by Spazmania (174582) on Thursday August 30, 2012 @03:29PM (#41181949) Homepage

            Port knocking is less useful now that many corporate environments restrict outbound tcp ports.

        • by Midnight_Falcon (2432802) on Thursday August 30, 2012 @03:46PM (#41182221)
          fail2ban + SSH-key only access FTW

          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...

        • by spazdor (902907)

          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

        • by antdude (79039)

          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.

        • by sl4shd0rk (755837)

          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

        • by Lehk228 (705449)
          Sure they know about them, but unless you in particular are a high profile target there is far more to be had checking 1 port on 65535 machines than checking every port on one machine just in case the owner is simultaniously smart enough to use a non default port and dumb enough to use '12345', 'password', or 'penis' as a password
      • by fearlezz (594718) on Thursday August 30, 2012 @02:58PM (#41181483) Homepage

        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.

      • 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).

    • by Anonymous Coward on Thursday August 30, 2012 @02:58PM (#41181489)

      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.

    • by logicassasin (318009) on Thursday August 30, 2012 @03:02PM (#41181543)

      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.

      • I used to do this, email abuse at their isp, back when I had the time and desire to read through my firewall logs. I would often get responses thanking me for sending the relevant logs or at least informing me that they were looking in to it.
    • by gandhi_2 (1108023)

      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.

    • by MrSenile (759314) on Thursday August 30, 2012 @03:20PM (#41181835)

      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.

      • by Pieroxy (222434)

        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.

    • 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

    • by Jonner (189691)

      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.

    • 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.

  • Pointless (Score:5, Insightful)

    by Hentes (2461350) on Thursday August 30, 2012 @02:43PM (#41181241)

    The attackers are most likely using other infested machines.

    • by fearlezz (594718)

      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.

  • by chemicaldave (1776600) on Thursday August 30, 2012 @02:43PM (#41181243)
    There's nothing anyone can legally do with that information. Weak attempts at breaking in and port scanning are just background noise.
  • by stevegee58 (1179505) on Thursday August 30, 2012 @02:45PM (#41181281) Journal
    Backtrace them and report them to the cyber police!
  • by eudaemon (320983) on Thursday August 30, 2012 @02:46PM (#41181283)
    As long as you use key-only authentication you should be fine. I wouldn't leave password-only access open to the internet. Having said that, your best bet is to slowly stall connections in order to waste the other guy's resources. Any system with pf and probably ipf have allowances for that, along with logging and blocking the most abusive IPs altogether.
  • by UnderAttack (311872) * on Thursday August 30, 2012 @02:46PM (#41181289) Homepage

    "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.

  • by scorp1us (235526) on Thursday August 30, 2012 @02:46PM (#41181299) Journal

    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.

    • by TheCarp (96830)

      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

    • 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

  • by Anonymous Coward on Thursday August 30, 2012 @02:47PM (#41181311)

    http://www.dhs.gov/how-do-i/report-cyber-incidents

    • 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

  • by Sam Nitzberg (242911) on Thursday August 30, 2012 @02:48PM (#41181339)

    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

  • Or you can figure out the ISP of the person attempting to break in. A phone call to the ISP's admin at 3AM their time with relevent details seems to be quite effective especially if it is a reoccuring problem resulting in repeat 3AM phonecalls to the opposite side of the globe.
  • Have you considered running DenyHosts on your machine? That might help filter out some repeat offenders.
    • 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.

  • by mseeger (40923) on Thursday August 30, 2012 @02:54PM (#41181425)

    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.

  • by PolygamousRanchKid (1290638) on Thursday August 30, 2012 @02:57PM (#41181479)

    . . . the FBI are the ones trying to break into your system.

    • It becomes even more complicated when the IP connecting to you belongs to a honeynet hosted by some investigatory body.

  • Most of the time - at least from my experience - the attacks are coming either from systems that are in foreign countries that don't give a shit about you and your system, or they are distributed attacks that would require you to contact dozens (or more) of ISPs.

    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)

    by msauve (701917) on Thursday August 30, 2012 @02:59PM (#41181507)
    you're not going to make a dent. Most reports are simply ignored, and for every attacker you see, there are thousands more who simply haven't gotten to you yet.

    Make sure you have good passwords, know what ports are exposed, and run something like fail2ban [fail2ban.org].
  • /dev/null (Score:5, Funny)

    by yourdog (709870) on Thursday August 30, 2012 @03:02PM (#41181545)
    Most UNIX systems automatically subscribe to the Network Users List of Lamers. Just write up your complaint to a text file, then send the complaint to NULL, using the command 'cat $REPORT > /dev/null'
  • by adriccom (44869) on Thursday August 30, 2012 @03:05PM (#41181595) Homepage

    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.

  • Really, no government agency is going to give a red cent about some 14 year old running scripts against your machines unless you're a major contributor or hold government office.
  • by ibsteve2u (1184603) on Thursday August 30, 2012 @03:16PM (#41181777)

    Where to report script kiddies...

    Their mothers. Duh.

  • 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)

    by inode_buddha (576844) on Thursday August 30, 2012 @03:29PM (#41181967) Journal

    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]

  • ...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

  • by router (28432) <a@r.gmail@com> on Thursday August 30, 2012 @03:38PM (#41182089) Homepage Journal

    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

  • by Opportunist (166417) on Thursday August 30, 2012 @03:56PM (#41182379)

    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.

  • Attempted script kiddie attacks are automatically reported to the same place that failed sudo attempts are reported to.

  • 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)

    by dropadrop (1057046) on Thursday August 30, 2012 @04:37PM (#41182961)
    The FBI don't care. We've had cases where somebody has phished hundreds of accounts and we've had clear logs to show how they have been profiting from it financially, but can't manage to get them to do anything. A few years ago we did have a contact there who did something, but he was moved to some other agency...

    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.

  • by subreality (157447) on Thursday August 30, 2012 @05:15PM (#41183563)

    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.

  • by bmo (77928) on Thursday August 30, 2012 @05:45PM (#41183913)

    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

  • by geekoid (135745) <dadinportland@@@yahoo...com> on Thursday August 30, 2012 @07:33PM (#41185123) Homepage Journal

    that's the equivalent of asking where you report someone who ding dong ditched you house, right?

  • by dweller_below (136040) on Thursday August 30, 2012 @07:58PM (#41185277)
    The security group at USU documents, blocks and reports attack. It is part of our security response. We feel it is a cost effective part of our security posture. We have been doing it for 5 years.

    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:

    • * It creates memory of how USU is attacked. We need to know how we are attacked, so our defenses are anchored in reality.
    • * It blocks attacking IPs at the USU border. We can specify a duration that is appropriate to the occasion.
    • * It notifies the owner/ISP of the computer that they are attacking USU. Usually they are also innocent victims.

    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:

    • * Once a week, summary reports go out to our peers across the state, and to the FBI.
    • * It keeps USU IT Security from developing the habit of ignoring attack.
    • * Blocking attackers gives us a great deal of satisfaction. (Normally, we can't get no.)
    • * It sends a message to attackers, that USU is not cheap, soft pickings.
    • * We have demonstrated a couple times that the number of attacks drop off sharply a couple weeks after we begin religiously reporting attacking IPs.

    Finally, we are convinced that reporting of compromise/attack is one of the few pathways that can lead to a more secure internet.

    • * Computer owners/admins must know about their compromise to make sound decisions.
    • * The current hacking environment is controlled by the economics of hacking. Reporting attack/compromise increases the risk/cost of hacking and decreases the reward.
    • * If we help others to know they have problems, maybe someday, somebody will have similar mercy on us.

    Miles

For every bloke who makes his mark, there's half a dozen waiting to rub it out. -- Andy Capp

Working...