[SOLVED] Enabled remote SSH on my local server, immediately random IPs try to login

wh33t · 09-05-2016, 03:39 PM

Just realized this is exact issue was posted on this same forum. I'll read those responses in there.

So I knew as soon as I opened my machine up to the raw internet that there would most likely be bots sooner or later that attempted to login with known usernames and password but I wasn't expecting this high of a volume.

Apart from changing the port number to something else (say 2222?) what else could I do to minimize these attempts on my machine. And would changing the port to 2222 even make that much of a difference? My understanding is that some bot is using nmap or something to port scan what ports are open and then going from there. Also curious, if I moved to a port that is never associated with SSH, say 55555, is there a way for would-be-hackers to identify that 55555 is being listened to for SSH?

How about auto adding in a deny rule for UFW when these attempts happen? I'm open to suggestions.

Code:

Sep  4 06:36:25 wh33tserv sshd[7464]: Failed password for invalid user admin from 104.199.183.239 port 62552 ssh2
Sep  4 06:36:29 wh33tserv sshd[7466]: Failed password for invalid user ubnt from 104.199.183.239 port 63456 ssh2
Sep  4 06:36:55 wh33tserv sshd[7468]: Failed password for invalid user test from 104.199.183.239 port 63759 ssh2
Sep  4 06:37:21 wh33tserv sshd[7470]: Failed password for invalid user guest from 104.199.183.239 port 65231 ssh2
Sep  4 06:37:33 wh33tserv sshd[7472]: Failed password for invalid user user from 104.199.183.239 port 50298 ssh2
Sep  4 06:37:37 wh33tserv sshd[7474]: Failed password for invalid user support from 104.199.183.239 port 50961 ssh2
Sep  4 06:37:47 wh33tserv sshd[7476]: Failed password for uucp from 104.199.183.239 port 51238 ssh2
Sep  4 06:37:50 wh33tserv sshd[7478]: Failed password for invalid user default from 104.199.183.239 port 51758 ssh2
Sep  4 06:38:02 wh33tserv sshd[7480]: Failed password for invalid user info from 104.199.183.239 port 51953 ssh2
Sep  4 06:38:34 wh33tserv sshd[7482]: Failed password for root from 104.199.183.239 port 52924 ssh2
Sep  4 06:38:37 wh33tserv sshd[7484]: Failed password for invalid user admin from 104.199.183.239 port 54329 ssh2
Sep  4 06:39:02 wh33tserv sshd[7486]: Failed password for invalid user plcmSpIp from 104.199.183.239 port 54562 ssh2
Sep  4 06:39:32 wh33tserv sshd[7531]: Failed password for mysql from 104.199.183.239 port 55971 ssh2
Sep  4 06:39:44 wh33tserv sshd[7534]: Failed password for invalid user ftp from 104.199.183.239 port 57684 ssh2
Sep  4 06:40:07 wh33tserv sshd[7536]: Failed password for invalid user pi from 104.199.183.239 port 58393 ssh2
Sep  4 06:57:56 wh33tserv sshd[7564]: Failed password for invalid user ubnt from 1.54.214.68 port 16744 ssh2
Sep  4 06:58:28 wh33tserv sshd[7567]: Failed password for invalid user admin from 1.54.214.68 port 14471 ssh2
Sep  4 06:58:47 wh33tserv sshd[7569]: Failed password for invalid user admin from 1.54.214.68 port 61655 ssh2
Sep  4 06:59:18 wh33tserv sshd[7571]: Failed password for invalid user support from 1.54.214.68 port 61183 ssh2
Sep  4 06:59:44 wh33tserv sshd[7576]: Failed password for invalid user admin from 1.54.214.68 port 28294 ssh2
Sep  4 07:00:10 wh33tserv sshd[7578]: Failed password for root from 1.54.214.68 port 30732 ssh2
Sep  4 07:00:29 wh33tserv sshd[7580]: Failed password for invalid user guest from 1.54.214.68 port 60840 ssh2
Sep  4 07:00:40 wh33tserv sshd[7582]: Failed password for invalid user support from 1.54.214.68 port 29235 ssh2
Sep  4 07:01:26 wh33tserv sshd[7584]: Failed password for invalid user test from 1.54.214.68 port 16573 ssh2
Sep  4 07:01:46 wh33tserv sshd[7587]: Failed password for invalid user ftpuser from 1.54.214.68 port 46107 ssh2
Sep  4 07:02:08 wh33tserv sshd[7589]: Failed password for invalid user vyatta from 1.54.214.68 port 54682 ssh2
Sep  4 07:02:31 wh33tserv sshd[7591]: Failed password for invalid user pi from 1.54.214.68 port 14206 ssh2
Sep  4 07:03:26 wh33tserv sshd[7593]: Failed password for invalid user user from 1.54.214.68 port 40825 ssh2
Sep  4 07:03:43 wh33tserv sshd[7595]: Failed password for invalid user www from 1.54.214.68 port 54077 ssh2
Sep  4 07:04:09 wh33tserv sshd[7597]: Failed password for invalid user PlcmSpIp from 1.54.214.68 port 7504 ssh2
Sep  4 07:04:45 wh33tserv sshd[7599]: Failed password for root from 1.54.214.68 port 42405 ssh2
Sep  4 07:05:10 wh33tserv sshd[7601]: Failed password for root from 1.54.214.68 port 64554 ssh2
Sep  4 07:05:24 wh33tserv sshd[7606]: Failed password for root from 1.54.214.68 port 60423 ssh2
Sep  4 07:05:42 wh33tserv sshd[7608]: Failed password for root from 1.54.214.68 port 60958 ssh2
Sep  4 07:06:07 wh33tserv sshd[7610]: Failed password for root from 1.54.214.68 port 9511 ssh2
Sep  4 07:06:29 wh33tserv sshd[7612]: Failed password for invalid user admin from 1.54.214.68 port 9379 ssh2
Sep  4 07:07:00 wh33tserv sshd[7614]: Failed password for invalid user Administrator from 1.54.214.68 port 17285 ssh2
Sep  4 07:07:20 wh33tserv sshd[7616]: Failed password for invalid user Administrator from 1.54.214.68 port 28890 ssh2
Sep  4 07:07:45 wh33tserv sshd[7618]: Failed password for invalid user micros from 1.54.214.68 port 31968 ssh2
Sep  4 07:08:13 wh33tserv sshd[7621]: Failed password for invalid user pos from 1.54.214.68 port 7847 ssh2
Sep  4 07:08:37 wh33tserv sshd[7623]: Failed password for invalid user administrator from 1.54.214.68 port 10877 ssh2
Sep  4 08:51:39 wh33tserv sshd[7835]: Failed password for invalid user user from 103.207.36.249 port 52726 ssh2
Sep  4 09:28:31 wh33tserv sshd[7894]: Failed password for invalid user support from 103.207.37.234 port 52939 ssh2
Sep  4 10:54:21 wh33tserv sshd[8068]: Failed password for invalid user ubnt from 113.161.212.60 port 50985 ssh2
Sep  4 11:33:41 wh33tserv sshd[8126]: Failed password for invalid user support from 103.207.37.234 port 65191 ssh2
Sep  4 12:03:50 wh33tserv sshd[8188]: Failed password for invalid user user from 103.207.36.249 port 61047 ssh2
Sep  4 12:07:51 wh33tserv sshd[8193]: Failed password for root from 82.85.187.101 port 55478 ssh2
Sep  4 12:07:53 wh33tserv sshd[8193]: Failed password for root from 82.85.187.101 port 55478 ssh2
Sep  4 14:03:06 wh33tserv sshd[8703]: Failed password for invalid user user from 103.207.36.249 port 62341 ssh2
Sep  4 14:11:03 wh33tserv sshd[8753]: Failed password for invalid user support from 103.207.37.234 port 51334 ssh2
Sep  4 15:04:55 wh33tserv sshd[8816]: Failed password for invalid user support from 74.208.218.245 port 51637 ssh2
Sep  4 15:04:58 wh33tserv sshd[8818]: Failed password for invalid user ubnt from 74.208.218.245 port 54401 ssh2
Sep  4 15:05:02 wh33tserv sshd[8820]: Failed password for invalid user 1234 from 74.208.218.245 port 57185 ssh2
Sep  4 15:05:04 wh33tserv sshd[8822]: Failed password for invalid user admin from 74.208.218.245 port 60085 ssh2
Sep  4 15:05:07 wh33tserv sshd[8826]: Failed password for invalid user admin from 74.208.218.245 port 62915 ssh2
Sep  4 15:05:10 wh33tserv sshd[8828]: Failed password for root from 74.208.218.245 port 49162 ssh2
Sep  4 15:05:45 wh33tserv sshd[8832]: Failed password for invalid user support from 103.207.37.234 port 61360 ssh2
Sep  4 15:48:32 wh33tserv sshd[8936]: Failed password for invalid user support from 74.208.213.154 port 51141 ssh2
Sep  4 15:48:34 wh33tserv sshd[8938]: Failed password for invalid user admin from 74.208.213.154 port 58274 ssh2
Sep  4 16:28:44 wh33tserv sshd[9000]: Failed password for invalid user support from 103.207.37.234 port 56919 ssh2
Sep  4 19:09:58 wh33tserv sshd[9317]: Failed password for invalid user support from 103.207.37.234 port 63045 ssh2
Sep  4 20:21:41 wh33tserv sshd[9433]: Failed password for invalid user user from 103.207.36.249 port 49334 ssh2
Sep  4 20:25:26 wh33tserv sshd[9438]: Failed password for root from 82.85.187.101 port 33423 ssh2
Sep  4 20:25:28 wh33tserv sshd[9438]: Failed password for root from 82.85.187.101 port 33423 ssh2
Sep  4 20:42:38 wh33tserv sshd[9606]: Failed password for invalid user support from 103.207.37.234 port 65362 ssh2
Sep  4 22:29:16 wh33tserv sshd[9956]: Failed password for invalid user support from 103.207.37.234 port 59025 ssh2
Sep  4 22:42:17 wh33tserv sshd[10006]: Failed password for invalid user user from 103.207.36.249 port 62307 ssh2
Sep  4 23:36:27 wh33tserv sshd[10072]: Failed password for invalid user admin from 185.110.132.201 port 51446 ssh2
Sep  4 23:44:10 wh33tserv sshd[10118]: Failed password for invalid user support from 185.110.132.201 port 48425 ssh2
Sep  5 01:26:46 wh33tserv sshd[10301]: Failed password for invalid user support from 103.207.37.234 port 54607 ssh2
Sep  5 03:07:19 wh33tserv sshd[10765]: Failed password for invalid user support from 103.207.37.234 port 57424 ssh2
Sep  5 04:59:35 wh33tserv sshd[10985]: Failed password for invalid user support from 103.207.37.234 port 63955 ssh2
Sep  5 05:07:30 wh33tserv sshd[10992]: Failed password for invalid user ubnt from 203.162.235.249 port 58269 ssh2
Sep  5 05:07:36 wh33tserv sshd[10994]: Failed password for invalid user admin from 203.162.235.249 port 51312 ssh2
Sep  5 05:07:44 wh33tserv sshd[10996]: Failed password for root from 203.162.235.249 port 64115 ssh2
Sep  5 05:07:51 wh33tserv sshd[10998]: Failed password for invalid user guest from 203.162.235.249 port 50153 ssh2
Sep  5 05:08:00 wh33tserv sshd[11000]: Failed password for invalid user admin from 203.162.235.249 port 52789 ssh2
Sep  5 05:08:06 wh33tserv sshd[11002]: Failed password for invalid user support from 203.162.235.249 port 53060 ssh2
Sep  5 05:08:11 wh33tserv sshd[11004]: Failed password for invalid user test from 203.162.235.249 port 53234 ssh2
Sep  5 05:08:15 wh33tserv sshd[11006]: Failed password for invalid user user from 203.162.235.249 port 53318 ssh2
Sep  5 05:38:12 wh33tserv sshd[11062]: Failed password for invalid user ubnt from 36.85.66.245 port 58783 ssh2
Sep  5 05:38:16 wh33tserv sshd[11064]: Failed password for invalid user admin from 36.85.66.245 port 60753 ssh2
Sep  5 05:38:21 wh33tserv sshd[11066]: Failed password for root from 36.85.66.245 port 63198 ssh2
Sep  5 05:38:25 wh33tserv sshd[11068]: Failed password for invalid user guest from 36.85.66.245 port 65198 ssh2
Sep  5 05:38:28 wh33tserv sshd[11070]: Failed password for invalid user admin from 36.85.66.245 port 50702 ssh2
Sep  5 05:38:33 wh33tserv sshd[11072]: Failed password for invalid user support from 36.85.66.245 port 52599 ssh2
Sep  5 05:38:37 wh33tserv sshd[11074]: Failed password for invalid user test from 36.85.66.245 port 54522 ssh2
Sep  5 05:38:40 wh33tserv sshd[11076]: Failed password for invalid user user from 36.85.66.245 port 56458 ssh2
Sep  5 05:38:46 wh33tserv sshd[11078]: Failed password for invalid user admin from 36.85.66.245 port 58213 ssh2
Sep  5 05:38:50 wh33tserv sshd[11080]: Failed password for invalid user test from 36.85.66.245 port 60477 ssh2
Sep  5 05:38:55 wh33tserv sshd[11082]: Failed password for bin from 36.85.66.245 port 62492 ssh2
Sep  5 05:39:00 wh33tserv sshd[11084]: Failed password for invalid user PlcmSpIp from 36.85.66.245 port 64771 ssh2
Sep  5 05:39:05 wh33tserv sshd[11086]: Failed password for invalid user ftpuser from 36.85.66.245 port 50594 ssh2
Sep  5 05:39:09 wh33tserv sshd[11130]: Failed password for invalid user ftp from 36.85.66.245 port 50952 ssh2
Sep  5 05:39:13 wh33tserv sshd[11132]: Failed password for invalid user sales from 36.85.66.245 port 51026 ssh2
Sep  5 05:39:18 wh33tserv sshd[11134]: Failed password for invalid user operator from 36.85.66.245 port 51085 ssh2
Sep  5 05:39:22 wh33tserv sshd[11136]: Failed password for invalid user pi from 36.85.66.245 port 51147 ssh2
Sep  5 05:39:26 wh33tserv sshd[11138]: Failed password for invalid user cop from 36.85.66.245 port 51204 ssh2
Sep  5 05:39:30 wh33tserv sshd[11140]: Failed password for uucp from 36.85.66.245 port 51250 ssh2
Sep  5 05:39:35 wh33tserv sshd[11142]: Failed password for root from 36.85.66.245 port 51294 ssh2
Sep  5 05:39:40 wh33tserv sshd[11144]: Failed password for root from 36.85.66.245 port 51338 ssh2
Sep  5 05:39:45 wh33tserv sshd[11146]: Failed password for invalid user manager from 36.85.66.245 port 51379 ssh2
Sep  5 05:39:49 wh33tserv sshd[11148]: Failed password for invalid user user from 36.85.66.245 port 51411 ssh2
Sep  5 06:11:52 wh33tserv sshd[11204]: Failed password for invalid user support from 103.207.37.234 port 58877 ssh2
Sep  5 07:30:36 wh33tserv sshd[11398]: Failed password for invalid user admin from 67.211.215.60 port 62458 ssh2
Sep  5 07:30:39 wh33tserv sshd[11400]: Failed password for invalid user ubnt from 67.211.215.60 port 62605 ssh2
Sep  5 07:30:41 wh33tserv sshd[11402]: Failed password for invalid user pi from 67.211.215.60 port 62830 ssh2
Sep  5 07:30:45 wh33tserv sshd[11404]: Failed password for invalid user admin from 67.211.215.60 port 62978 ssh2
Sep  5 07:30:49 wh33tserv sshd[11406]: Failed password for invalid user support from 67.211.215.60 port 63174 ssh2
Sep  5 07:30:52 wh33tserv sshd[11408]: Failed password for root from 67.211.215.60 port 63419 ssh2
Sep  5 07:30:54 wh33tserv sshd[11410]: Failed password for invalid user operator from 67.211.215.60 port 63628 ssh2
Sep  5 07:30:58 wh33tserv sshd[11412]: Failed password for invalid user user from 67.211.215.60 port 63797 ssh2
Sep  5 07:31:01 wh33tserv sshd[11414]: Failed password for root from 67.211.215.60 port 64006 ssh2
Sep  5 07:31:03 wh33tserv sshd[11416]: Failed password for root from 67.211.215.60 port 64184 ssh2
Sep  5 07:31:06 wh33tserv sshd[11418]: Failed password for invalid user osmc from 67.211.215.60 port 64347 ssh2
Sep  5 07:31:09 wh33tserv sshd[11420]: Failed password for sshd from 67.211.215.60 port 64503 ssh2
Sep  5 07:31:12 wh33tserv sshd[11422]: Failed password for invalid user odoo from 67.211.215.60 port 64725 ssh2
Sep  5 08:52:56 wh33tserv sshd[11596]: Failed password for invalid user ubnt from 203.162.235.249 port 54484 ssh2
Sep  5 08:53:00 wh33tserv sshd[11598]: Failed password for invalid user admin from 203.162.235.249 port 63532 ssh2
Sep  5 08:53:10 wh33tserv sshd[11600]: Failed password for root from 203.162.235.249 port 56373 ssh2
Sep  5 08:53:18 wh33tserv sshd[11602]: Failed password for invalid user guest from 203.162.235.249 port 62051 ssh2
Sep  5 08:53:24 wh33tserv sshd[11604]: Failed password for invalid user admin from 203.162.235.249 port 64630 ssh2
Sep  5 08:53:30 wh33tserv sshd[11606]: Failed password for invalid user support from 203.162.235.249 port 64773 ssh2
Sep  5 08:53:36 wh33tserv sshd[11608]: Failed password for invalid user test from 203.162.235.249 port 64919 ssh2
Sep  5 08:53:40 wh33tserv sshd[11610]: Failed password for invalid user user from 203.162.235.249 port 65016 ssh2
Sep  5 09:16:58 wh33tserv sshd[11672]: Failed password for invalid user support from 103.207.37.234 port 58357 ssh2
Sep  5 10:49:01 wh33tserv sshd[11838]: Failed password for invalid user support from 103.207.37.234 port 65064 ssh2
Sep  5 11:29:24 wh33tserv sshd[11902]: Failed password for invalid user support from 103.207.37.234 port 60297 ssh2
Sep  5 11:29:36 wh33tserv sshd[11905]: Failed password for invalid user ubnt from 203.162.235.249 port 52751 ssh2
Sep  5 11:29:40 wh33tserv sshd[11907]: Failed password for invalid user admin from 203.162.235.249 port 61930 ssh2
Sep  5 11:29:48 wh33tserv sshd[11909]: Failed password for root from 203.162.235.249 port 56921 ssh2
Sep  5 11:29:56 wh33tserv sshd[11911]: Failed password for invalid user guest from 203.162.235.249 port 55127 ssh2
Sep  5 11:30:02 wh33tserv sshd[11913]: Failed password for invalid user admin from 203.162.235.249 port 62633 ssh2
Sep  5 11:30:08 wh33tserv sshd[11915]: Failed password for invalid user support from 203.162.235.249 port 62795 ssh2
Sep  5 11:30:14 wh33tserv sshd[11917]: Failed password for invalid user test from 203.162.235.249 port 62915 ssh2
Sep  5 11:30:19 wh33tserv sshd[11919]: Failed password for invalid user user from 203.162.235.249 port 63021 ssh2
Sep  5 13:24:14 wh33tserv sshd[12138]: Failed password for invalid user admin from 91.197.232.10 port 33160 ssh2

jefro · 09-05-2016, 07:04 PM

The attacks were on your wan connection all the time. You just didn't see them.

A lot of current web pages for things to consider that may include the following.
https://www.google.com/search?q=secu...utf-8&oe=utf-8

Some people might decide to make a self signed certificate authentication. Some might whitelist an ip.

Use some very long complex passwords.

Cron some time limits for service to be on?

Be sure to have a good firewall running.

Be sure you understand minimal permission to do a task. Make a ssh account just for access with almost no permissions maybe.

Others may have some ideas on this.

Emerson · 09-05-2016, 07:54 PM

No root login, only key-based login for user.

agillator · 09-05-2016, 07:59 PM

I would (and do) get the cidr for that ip and block that cidr through your firewall (iptables on your machine if nothing else). Then periodically you can check that rule in the firewall to see how many hits you get in a day. If/when it goes away you can remove the block. If it doesn't go away, then keep it blocked. And this is in addition to all the suggestions above.

Red Squirrel · 09-05-2016, 08:57 PM

You should to use a non default port for outside facing SSH, as well as something that will protect from brute force, like fail2ban.

If you leave it that way it's a matter of when and not if someone goes in. SSH does not have any kind of built in brute force protection.

Using a non default port alone will help a lot, but that is just security through obscurity, so fail2ban is a good idea too. I have mine set for 3 tries then it bans the IP.

wh33t · 09-05-2016, 09:20 PM

Quote:

Originally Posted by Red Squirrel

You should to use a non default port for outside facing SSH, as well as something that will protect from brute force, like fail2ban.

If you leave it that way it's a matter of when and not if someone goes in. SSH does not have any kind of built in brute force protection.

Using a non default port alone will help a lot, but that is just security through obscurity, so fail2ban is a good idea too. I have mine set for 3 tries then it bans the IP.

Thank you all for the suggestions. I'm having a hard time finding any kind of SSH protection that doesn't involve ip-tables. I'm using UFW. I'll keep looking.

Red Squirrel · 09-05-2016, 10:07 PM

fail2ban does rely on iptables, but you should not have to configure it. You may need to setup a script to allow ssh by default though. If this is a remote server be careful playing with iptables as you can lock yourself out. Been there done that. Sucks. :P

IsaacKuo · 09-05-2016, 11:29 PM

I just started learning iptables last week, and it's not so bad if you stick to relatively simple stuff - like DROP everything incoming except for your custom ssh port. That's assuming ssh access is the ONLY thing you want to let in, of course.

But if you want to just use UFW, then that's fine I think. I'd just block everything except for the custom ssh port (and whatever else you want to let in), and trust in the security of key based authentication. (Put a passphrase on the key.) Unless there's another infamous Debian bug affecting your key generation, there's just no way to brute force in. So basically, the layers of security I recommend are:

1) Disable root login in ssh (helps a tiny bit, if any...at least it makes things simpler for you to maintain).

2) Only allow key based authentication (the most important aspect - it makes brute force attacks practically impossible).

3) Generate a key with passphrase (makes it so that you're still secure even someone acquires a copy of the key).

4) Use a strong passphrase (makes it harder or impossible to brute force even with the key).

5) Use custom ssh port (it mainly helps reduce how much garbage is thrown at your system).

I think that unless you're running some site which would draw specific attention from professional crackers, you have to look at security as a group effort. It's not that a cracker is going to brute force your specific system by hitting it with a zillion login attempts per second. Rather, it's going to hit a zillion different targets per second. This conveniently gets around any sort of fail2ban tactics. And when it comes to fishing for vulnerable systems, hitting a zillion different targets per second is actually more effective than hitting a single target a zillion times per second. (Hitting many targets will hit lower hanging fruit more quickly than concentrating on a single target.)

That said, why use the standard port when that's the one which is going to be hit most heavily?

agillator · 09-06-2016, 12:00 AM

Blocking a cidr (ip range) by iptables is really fairly simple. The only problem you can cause is if you block the cidr that includes YOUR ip, but then that certainly shouldn't happen, should it? However, since you are using UFW, I'll assume gufw for simplicity. It you don't have gufw, go ahead and install it. Then get the ip range of the offending ip. Open a terminal window and run whois <the offending ip>. Near the top will be the ip range and/or the cidr. You must use a cidr, so convert if necessary. Then run GUFW, click on rules, +, and advanced. In that window enter a rule name (anything you want), set insert to 1 or another position if you prefer, policy should be set to deny, direction should be in, interface is your choice, all is fine or select your input (internet facing) interface, log is your option, you can set it to log for a while to make sure it is working and then change it, protocol is best left both, If you have the cidr (123.15.156.0/24, for example) enter it in the from box. Enter 22 in the first port box if you only want that port blocked from that ip range, or leave it blank to block all traffic from those ips. Click add. in a moment it will appear in the list of rules. That should do it. You can do the same in the cli version of ufw, but gufw is usually easier for this sort of thing.

AFTER FURTHER RESEARCH - you must use the cidr, not the range of ips as I originally suggested. The above instructions have been corrected.

Sefyir · 09-06-2016, 12:20 AM

I use these iptables rules to help limit the number of attempts made. It runs on bootup.

Code:

ipt=/sbin/iptables

$ipt -N SSH
$ipt -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

$ipt -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -j SSH # Jump to SSH chain

## WEB SSH
$ipt -A SSH -m recent --set --name SSH # Set SSH recent
$ipt -A SSH -p tcp -m recent --name SSH --update --seconds 10 --hitcount 15 --rttl -j DROP # Drop if over counter
$ipt -A SSH -j ACCEPT

Basically, if you make 15 attempts (or more) within 10 a second period, drop the request. Otherwise accept.
If you don't use tools like scp (tabbing with scp for auto-complete uses a lot of requests!) you can drop this to --hitcount 2 so that every request in a 10 second period except the first is dropped.
Won't stop them but it'll minimize the number of requests

Turbocapitalist · 09-06-2016, 03:55 AM

Quote:

Originally Posted by wh33t

Also curious, if I moved to a port that is never associated with SSH, say 55555, is there a way for would-be-hackers to identify that 55555 is being listened to for SSH?

They'll find the high ports, too. I see such scans all the time. Dealing with the scans is just part of being on the net. You can block ranges with UFW (a frontend for iptables) or even rate limit the speed in which they try to connect. If you're looking at fail2ban, you can also look at sshguard. The latter has some advantages over the former and despite the name can be used for more than just SSH.

The two most important things you can do though are to disable remote root login and require keys for authentication. As far as I can tell, requiring keys also reduces the number of scans but more importantly it makes it impossible to brute force guess a way in.

Turbocapitalist · 09-06-2016, 04:04 AM

Quote:

Originally Posted by Sefyir

Basically, if you make 15 attempts (or more) within 10 a second period, drop the request. Otherwise accept.
If you don't use tools like scp (tabbing with scp for auto-complete uses a lot of requests!) you can drop this to --hitcount 2 so that every request in a 10 second period except the first is dropped.
Won't stop them but it'll minimize the number of requests

UFW will do that with the limit option. It's buried there in manual page.

Code:

sudo ufw limit ssh

With the raw iptables approach, it is possible to do it in fewer steps, if the default for the INPUT chain is to REJECT or DROP.

Code:

ip6tables -I INPUT -p TCP --dport 22 -m state --state NEW -m limit --limit 4/minute --limit-burst 5 -j ACCEPT
iptables  -I INPUT -p TCP --dport 22 -m state --state NEW -m limit --limit 4/minute --limit-burst 5 -j ACCEPT

However, what I see happen then is that the lame probes stop and the slower, distributed probes continue. There's not much that can be done about them by an end user. I suppose it would help to unplug or otherwise remove all the M$ devices from the net, thus eliminating the botnets at their source, but that's been a long fight so far.

elcore · 09-06-2016, 08:33 AM

What I did was setup cron to add a new override rule, above the existing drop rule, at specific dates and times.
Here it drops new connections by default, but accepts connections initiated by the box user if they originate from specified range.

Code:

#
iptables -A INPUT -p tcp -i eth4 -m state --state NEW -j DROP
iptables -A INPUT -p tcp -i eth4 -m state --state ESTABLISHED,RELATED -m iprange --src-range a.b.c.d-e.f.g.h -j ACCEPT
iptables -A INPUT -j DROP

But then cron on monday from 5am to 2pm (for example) restores rules from different set, allowing new connection from specified range on specified ports.

Code:

#
iptables -A INPUT -p tcp -i eth4 -m state --state NEW -m iprange --src-range a.b.c.d-e.f.g.h -m multiport --dports 222,223 -j ACCEPT
iptables -A INPUT -p tcp -i eth4 -m state --state NEW -j DROP
iptables -A INPUT -p tcp -i eth4 -m state --state ESTABLISHED,RELATED -m iprange --src-range a.b.c.d-e.f.g.h -j ACCEPT
iptables -A INPUT -j DROP

I'm using -A to add rather than inject, and src-range here should match the range of proxy from where the traffic comes from, something like 127.0.0.0-127.0.0.255
Note that the rule assumes the box is listening on eth4 tcp ports 222,223 and doesn't need any input except from specified proxy ip range.
Also note the above is written as example ipv4 input chain for securing a workstation, not a server.

Red Squirrel · 09-07-2016, 12:48 AM

Quote:

Originally Posted by Sefyir

I use these iptables rules to help limit the number of attempts made. It runs on bootup.

Code:

ipt=/sbin/iptables

$ipt -N SSH
$ipt -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

$ipt -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -j SSH # Jump to SSH chain

## WEB SSH
$ipt -A SSH -m recent --set --name SSH # Set SSH recent
$ipt -A SSH -p tcp -m recent --name SSH --update --seconds 10 --hitcount 15 --rttl -j DROP # Drop if over counter
$ipt -A SSH -j ACCEPT

Basically, if you make 15 attempts (or more) within 10 a second period, drop the request. Otherwise accept.
If you don't use tools like scp (tabbing with scp for auto-complete uses a lot of requests!) you can drop this to --hitcount 2 so that every request in a 10 second period except the first is dropped.
Won't stop them but it'll minimize the number of requests

Interesting, I've heard of this but first time I see an actual example code for it and I was never able to find one when I looked. I imagine this could be useful in general to help lower any kind of DoS based attack too, could probably have similar rules for HTTP etc too (with higher values).

sundialsvcs · 09-08-2016, 11:07 AM

Put everything behind an OpenVPN which uses digital certificates and tls-auth as I describe in my blog post: How To Build a Dwarvish Door With OpenVPN.

Not only is it impossible for the goons to enter, it is impossible for them to find(!) you.