15

I posted a question on Server Fault, but got downvoted and had the question closed.

One of the comments suggested looking over here, so here goes:

For my senior project, I'm working on an application which works to handle brute force SSH attacks.

I have a VPS which seems to get a few hundred, if not thousand, hits a day, but I'm getting two to three new VPS's just to analyze the attempts.

What's the fastest way to get people to attack my servers?

None of the data will be made public - no IP addresses will be released. It'll be completely consequence free. The servers will have a fresh Ubuntu installation with a python script running, nothing else.

I was thinking:

  • Ask on "hacking" forums
  • Offer reward ($15 Gift Card?) if they manage to break in
  • Honeypot

I don't care if my servers get hit hard - more data the better. There could be 1000 attempts/second for all I care.

I'm not sure if this is the right site to ask on, but I figured I'd try...

As another comment on the original question said, my VPS provider may not be happy if my VPS gets hit hard. If that is the case, I will deal with/talk to them about the issue.

citruspi
  • 315
  • 2
  • 7
  • 4
    What's stopping you from attacking your own server? Or do you want real in-the-wild attacks? Or do you want distributed attacks? – Cristian Dobre Jan 20 '13 at 19:31
  • 1
    @CristianDobre I need random data - my application works with the log data in real time to check stuff like the country of origin, user name used, etc. If I attacked it myself, I simply wouldn't get as varied data and as much of it. I need real people (or botnets) to make an actual attempt to break into my VPS via SSH. – citruspi Jan 20 '13 at 19:34
  • @citruspi, if the application analyzes the log data, why not generate some random data, with random countries, IPs, etc.? – laurent Jan 21 '13 at 03:05
  • 1
    You need to be careful, especially if you are renting VPS's from third parties. If the attacks somehow manage to affect the company you are renting from, and they realize that you have invited the attacks, be prepared to be billed(or worse) if they cause network downtime etc. – Adam McKissock Jan 20 '13 at 21:34
  • Have you looked at previous work for ideas? E.g. a quick search found [A Study of Passwords and Methods Used in Brute-Force SSH Attacks](http://people.clarkson.edu/~owensjp/pubs/leet08.pdf) – sourcejedi Jan 21 '13 at 10:49
  • @Laurent because my script reads from the end of the auth.log file in real time - I want to see if it is capable of handling data in real time, not just accepting a file and parsing it. – citruspi Jan 21 '13 at 18:25
  • @sourcejedi Thanks for the link, I'll take a look. – citruspi Jan 21 '13 at 18:26
  • @citruspi sounds like you're doing something along the lines of PeerBlock - it reads the `auth.log` file and moderates the `hosts.deny` file in real time. Just a note. – lynks Jan 21 '13 at 19:09
  • @lynks my project is similar, but not the same. – citruspi Jan 21 '13 at 23:08

4 Answers4

20

There are mostly two kinds of attackers: the automatic, and the targeted.

Automatic attackers are not humans; they are infected machines, part of various botnets, which try to expand their basis by finding other machines to infect. Their strategy is mostly random: they try random IP address for an open SSH server, then try common passwords for common account names. There is little you can do to increase (or, for that matter, decrease) the amount of connections of this kind you will receive per day. Some network providers try to detect these occurrences and block them or limit their rate, so you could speak with your provider and see if he has such systems in place.

Targeted attackers are humans who want to crack your machine, specifically. To get that kind of attacker, you need to provide some sort of motivation. You could try to boast about some desirable "goods" stored on your server (e.g. tons of pirated copies of gams or music or movies), making it worthwhile to hijack your machine. You could try to host a political-oriented blog with highly controversial positions. Sometimes boasting will by itself attract attackers: everybody loves to shut up an insufferable know-it-all, and hacking his server looks like an efficient way to achieve it. In short words: make some enemies.

Note, though, that brute-forcing passwords is the lowest grade of attacks. If some of your newly acquired enemies are a bit competent, they will try other kinds of attacks, such as exploiting vulnerabilities in your software. Also, some of them could think "out of the box" and not target your server, but you, directly; for instance, if they look up the name of a domain you own, they might obtain your address or phone number, and pay you a visit in person. As a general rule, I advise against making enemies. There is no such thing as "consequence free"; there is only "improbable consequences".

If that is for research, then you could try to approach the sysadmins of some major sites or infrastructures. This is your senior project: therefore, there is potential academic support. With the help of your professor or advisor, you could try to see if an ISP or a big hosting service would agree with collecting data on their system; they might even find some fiscal benefit in collaborating with a scientific project. Alternatively, most sysadmins are addicted to Guinness, and may agree to help a co-drinker, especially after the third pint (your profile state that you are 17 and live in the US, so this solution cannot officially be workable for you).

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
8

Your problem is the placement of a honeypot.

Consider that attackers will scan the internet to look for port 22 open, but they wont scan the whole IP space from start to end. Servers are concentrated in certain parts of the IP space. And similarly, simple internet subscribers are located in other parts of that space. So you have to use the IPs in the right spots for your honeypot.

The problem becomes finding those IP blocks that host a lot of servers to improve your chances. For that I can think of a couple of ways:

  • Buying VPSes from the largest providers because those are going to be scanned the most.
  • Buying MORE cheap VPSes from different providers.
  • Getting the help of other honeypot projects. Maybe Project Honeypot or Honeynet project can help.

Make sure you chose a provider that does not detect and block such brute-force attacks.

Cristian Dobre
  • 9,797
  • 1
  • 30
  • 50
  • Does setting AWS SG Inbound Rule to single IP is enough or setting non-standard SSH port is essential too? For me, obfuscating SSH is redundant here, if only I can connect to instance. – Suncatcher May 09 '18 at 09:37
3

I think you've got the right answer posting on hacking forums, the ones for those more interested in the process than gain. $15 isn't going to interest a for gain hacker, and you've (hopefully) no information worth stealing. Tell them you've built an SSHD that is extra hard to crack, kudos to anyone who can crack it. It may get interest.

Alternatively you may be able to get the for-gain types attacking it if you can make them think there's something on them worth having, which would require concocting some sort of story. You could post on some hacker forum that you broke into these servers that had really interesting stuff on it (credit card lists, plans for some sort of new nuclear reactor, etc), but they patched the hole so you lost your access, does anyone have a way in? See what happens.

GdD
  • 17,291
  • 2
  • 41
  • 63
3

I think a wide variety of hosts will be the key for you. I just checked the few hosts I run that have port 22 open to the world and they all saw in the range of thousands of attempts per day. I haven't seen more than 15,000 in one day. That seems fairly normal.

I checked three hosts at three different hosting providers: AWS EC2, OVH and iomart. All in different countries but all centred around Europe.

I do see distinctly different strategies from different bots. Sometimes a single IP will make thousands of attempts at the root user and never any other user. Other bots will make 5 - 10 attempts at common users such as ftp and postgres and one attempt each at a bunch of less common usernames such as test1, test2, test3, test4.

Most bots I see always have the source port above 30,000 but there's at least one bot that always chooses a source port of four digits and, assuming that it is attacking other hosts simultaneously, each new attempt increments the source port by one until it wraps around to about 1000 after hitting 9999. Actually, now that I look more closely, the 5-digit-source-port bot wraps at 61,000 down to 33,000. This should give you a good way to estimate how many other attempts a bot is making on other hosts in parallel to the ones you see.

I don't know if there's going to be a difference in how many and what kind of attacks there are between providers or countries but that would be an interesting aspect to add to your research. It wouldn't surprise me if American hosts were targeted more.

It might be worth also not only focusing on port 22. I remember years ago I ran a box that had ssh on port 10000. We saw thousands of Webmin login attempts hitting our ssh port. I was struck by how many attempts there were at what I considered to be a far less common port to be open. Now I realise that Sysadmins who use Webmin are also far more likely to have a default or easy password and to not notice that their box is under someone else's control, hence the success ratio may have been much higher on that sort of port. You may get a lot of login attempts on ports 21 and 23. Also maybe ports 110 (POP), 143 (IMAP) and 3389 (RDP).

Amazon EC2 instances might be a very good plan. You can get Micro Instances on the free tier and you get 750 instance hours a month free, which can be spent as a single instance which is switched on all month or 30 instances that are all on for a single day each month. 30 instances should get you 30x as many attempts per day but roughly the same number per month. Placing your instances in different regions should give you different IP networks and hopefully different kinds of attack traffic.

Ladadadada
  • 5,163
  • 1
  • 24
  • 41
  • Does setting AWS SG Inbound Rule to single IP is enough or setting non-standard SSH port is essential too? For me, obfuscating SSH is redundant here, if only I can connect to instance. – Suncatcher May 09 '18 at 09:37