add fail2ban to prevent ssh bruteforcing

Question

49

add fail2ban to prevent ssh bruteforcing

asked 2014-02-05 14:45:56 +0300

slaveriq
6028 ●33 ●43 ●39

updated 2015-07-13 18:49:21 +0300

Since a phone in developer mode is listening on port 22 for ssh on all interfaces (yes also on the 3g/LTE interface), bots are trying to bruteforce the login. At the moment it seems to only hit the root user and yes that is pretty futile, but we have seen bigger attacks where other user names where used earlier, so it's just a question of time before they will bruteforce the login for the nemo user as well.

Feb 05 13:22:47 awesomephone sshd[8341]: Failed password for root from 61.147.107.83 port 4565 ssh2
Feb 05 13:22:49 awesomephone sshd[8338]: Failed password for root from 61.147.107.83 port 3937 ssh2
Feb 05 13:22:52 awesomephone sshd[8338]: Failed password for root from 61.147.107.83 port 3937 ssh2
Feb 05 13:22:52 awesomephone sshd[8341]: Failed password for root from 61.147.107.83 port 4565 ssh2

I would therefor suggest having fail2ban or something similar, that would block ip's with more than X amount of failed logins.

edit: As proposed in the comments. An solution could also be to have sshd only listen on the wlan/usb device and not the wwan device. Even better would be if one could limit it to a specific wireless network. But i guess that could be error prone and one would not be able to use SSH to safe ones butt when the UI is unresponve(/broken by patches).

edit retag flag offensive close delete

Comments

1

where is this log?

lukedirtwalker ( 2014-02-05 19:05:58 +0300 )edit

(yes also on the 3g/LTE interface): According to my understanding, most mobile providers allocate IP numbers from private address ranges to their customers and do not allow direct inter-user-communication. Therefore for most users the threat is only of theoretical nature at the moment regarding the 2G/3G/4G interface.

Nonetheless: Brute force attacks should be stopped by the operating system.

jgr ( 2014-02-05 19:40:47 +0300 )edit

4

With the upcoming IPv6 Implementation, more devices may end up with a direct connection to the Internet. Of course, this also leads to new attack vectors (like changing your IPv6-Address after every login attempt)

Cmdr_Zod ( 2014-02-05 21:40:34 +0300 )edit

2

i agree with ipv6 this will be an issue for more ppl. my isp gives me a public routable ip so i have this problem today.

you can find rhe log by writing journalctl

slaveriq ( 2014-02-05 23:50:47 +0300 )edit

2

Would it be possible to activate the ssh deamon only for usb connections for example? or does the deamon automatically listen to any connection type?

shfit ( 2014-03-09 20:02:38 +0300 )edit

where is this log?
lukedirtwalker ( 2014-02-05 19:05:58 +0300 )edit
(yes also on the 3g/LTE interface): According to my understanding, most mobile providers allocate IP numbers from private address ranges to their customers and do not allow direct inter-user-communication. Therefore for most users the threat is only of theoretical nature at the moment regarding the 2G/3G/4G interface.
Nonetheless: Brute force attacks should be stopped by the operating system.
jgr ( 2014-02-05 19:40:47 +0300 )edit
With the upcoming IPv6 Implementation, more devices may end up with a direct connection to the Internet. Of course, this also leads to new attack vectors (like changing your IPv6-Address after every login attempt)
Cmdr_Zod ( 2014-02-05 21:40:34 +0300 )edit
i agree with ipv6 this will be an issue for more ppl. my isp gives me a public routable ip so i have this problem today.
you can find rhe log by writing journalctl
slaveriq ( 2014-02-05 23:50:47 +0300 )edit
Would it be possible to activate the ssh deamon only for usb connections for example? or does the deamon automatically listen to any connection type?
shfit ( 2014-03-09 20:02:38 +0300 )edit

Answer 1

6

answered 2014-03-09 13:22:46 +0300

Manatus
5188 ●58 ●79 ●74

updated 2014-03-09 13:32:31 +0300

This is really not an answer but it didn't fit in comments.

Fail2ban is not completely useless even on the era of IPv6. Development versions have an option for blocking different levels of IPv6 networks. Thinking behind this is that IPv6 addresses are distributed in networks, compared to single IP per single person with IPv4. If you block the network on the level it is commonly distributed (can't recall the mask now), it is effectively the same thing as banning a single IPv4 address today.

This will work for a while (year or three) but... Currently fail2ban reads the sshd log entries and bans the originating address when there are too many failures.

In the future hammering will get in to such levels that logging those attempts, and parsing the log, will get too heavy for phone devices. First the bottleneck would be sdcard. So the next step would be putting ssh-logs on tmpfs in memory. This would fail too, eventually, as parsing the logs would get so heavy on CPU.

So, in the future the only way I can think of, is shutting down the ssh daemon on your device, or limiting the access in iptables to a small range of networks.

Edit: One easy answer of course would be limiting ssh accessible from wlan interface network only. That effectively cuts out the background noise of the internet.

edit flag offensive delete publish link

Comments

Agree. I already added request for this in December:

https://together.jolla.com/question/2650/disable-ssh-daemon-when-remote-connections-are-disabled/

Plnt ( 2014-03-18 15:24:27 +0300 )edit

It seems to me like you are saying that battery-powered devices will not be able to have a login-server in the future at all. I doubt that will happen. A filter could be placed reading on port 22 and passing on to sshd, or even adding filtering capability directly to sshd.

00prometheus ( 2014-04-12 04:27:37 +0300 )edit

I know logging method can be bypassed by simply coding past it but that would not be fail2ban type of solution (logs) anymore, nor it would be the ethos of unix to add such features to sshd. How I see it, iptables should get better options for sorting out the noise or play along with intrusion detection system that would be small enough to fit in the memory. It needs to be something dynamic. Or sdcards should get a lot faster, of course. :)

Manatus ( 2014-04-12 20:47:42 +0300 )edit

Emacs... Point taken. ;)

Manatus ( 2014-04-23 09:22:59 +0300 )edit

I think fail2ban is completely rubbish. Tinkering with log files is error-prone and simply the wrong place for a security feature. If you want to limit login access use PAM tally to do it right.

inta ( 2015-07-13 18:15:57 +0300 )edit

Answer 2

2

answered 2014-03-18 15:03:33 +0300

icebox
820 ●12 ●21 ●26

There are several better avenues than parsing logs on a limited device:

Edit /etc/ssh/sshd_config and switch the port number to something random (not 2200, everybody uses that)
You can also set the ListenAddress thus limiting ssh to some networks but it doesn't accept interfaces and so it's useless if you roam to different networks (say home, work, etc.)
Use iptables to block the ssh port on the mobile WAN - seem the best option in my opinion

But I agree with the original poster, since this is a personal service mainly used for debugging I think it should listen by default only on the wireless lan/usb lan and/or be blocked by default on the mobile interface

edit flag offensive delete publish link

Comments

changing the default port is not a good option. Now a days you can scan the entire internet in a matter of minutes. Scanning a single ip for all ports is no work at all.

maybe a whitelist of ip's that is allowed to connect to sshd would be better.

slaveriq ( 2014-03-18 15:58:23 +0300 )edit

and yet on servers where ssh has been moved to a nonstandard port I don't see any attempts for months while on servers where ssh is running on port 22 I see lots of attempts minutes after I've deployed them.

I'm really curious how one scans all 65000 ports on all the internet hosts and identifies the one that's ssh and not something else in a matter of minutes.

But like I said a firewall seems in my opinion too the best idea.

icebox ( 2014-03-18 16:01:43 +0300 )edit

http://media.ccc.de/browse/congress/2013/30C3_-_5533_-_en_-_saal_2_-_201312281245_-_fast_internet-wide_scanning_and_its_security_applications_-_j_alex_halderman.html

honestly I have seen lots of login tries on none standard ports. Yes it is a lot less but it's not a protection.

slaveriq ( 2014-03-18 22:45:17 +0300 )edit

Answer 3

1

answered 2014-04-23 01:35:22 +0300

00prometheus
13308 ●135 ●174 ●152

What Unix-code ethos? Have you ever done "ls --help"? Or tried running emacs? ;-)

Seriously, I think the world would gain much from sshd having that functionality built in and easily accessible, though I suppose a filter-daemon sitting on port 22 and in turn passing on data to sshd might be a more modular way to go.

edit flag offensive delete publish link

Answer 4

6

answered 2015-07-13 15:17:12 +0300

Mikaela

1545 ●34 ●48 ●51

https://mikaela.info/

I don't think adding fail2ban would fix anything and would prefer firewall with limiting capabilities.

To this issue I also believe the correct solution is editing /etc/ssh/sshd_config and setting PasswordAuthentication no so SSH key is required for logging in.

edit flag offensive delete publish link

Comments

That would fix them guessing your password, but still leaves the phone spending way to much cpu time on garbage requests.

slaveriq ( 2015-07-13 18:39:11 +0300 )edit

2

There is small overlap with this question and https://together.jolla.com/question/3564/firewalling-the-jolla/ and there also seems to be https://together.jolla.com/question/69043/request-user-friendly-firewall-specifically-uwf-uncomplicated-firewall/ .

I would like ufw as it has ufw limit <port|service> which (from ufw manpage):

ufw  supports  connection rate limiting, which is useful for protecting
against brute-force login attacks. When a limit rule is used, ufw  will
normally  allow  the  connection  but  will  deny  connections if an IP
address attempts to initiate 6 or more connections within  30  seconds.
See http://www.debian-administration.org/articles/187 for details. Typ‐
ical usage is:

         ufw limit ssh/tcp

And why I would like ufw is that it would help with bruteforcing and also be otherwise more helpful than fail2ban by allowing blocking ports that nothing should be listening on and also preventing outgoing connections if ever needed.

Mikaela ( 2015-07-13 19:34:43 +0300 )edit

will deny connections if an IP address attempts to initiate 6 or more connections within 30 seconds.

This will deny connections from my PC after I used my sftp client to move a lot of data. The reason for this is that the sftp client is configured to use up to 10 simultaneous connections and sftp basically is file transfer via ssh. In my opinion SSH should do that directly, simply cause it's the only one who knows if a login attempt was successful or not.

V10lator ( 2015-07-14 13:58:18 +0300 )edit

Answer 5

0

answered 2015-07-13 16:02:32 +0300

Feathers_McGraw

260 ●8 ●12 ●18

https://samhobbs.co.uk/

Just throwing another option out there...

You can avoid having SSH up and running at all by installing sudo and adding nemo to sudoers (I also chose to set a pw, but that's up to you). Then disable developer mode, and you can still perform root actions using sudo.

I got sudo from NeilDK's openrepos repository.

Of course, this is only a solution if you only had SSH enabled because of developer mode, not so much if you actually wanted to SSH from a different computer. If that's the case I would require publickey authentication, like Mikaela suggested.

edit flag offensive delete publish link

Comments

But then how do you scp files?

slaveriq ( 2015-07-13 17:33:00 +0300 )edit

I guess I would temporarily enable developer mode to do that. My point was mainly that you don't have to enable SSH all the time to have root (IMO these should be quite separate in settings).

Feathers_McGraw ( 2015-07-13 18:06:44 +0300 )edit

Answer 6

1

answered 2015-07-13 17:20:48 +0300

Nieldk

4562 ●40 ●70 ●76

I use dual factor authentication GAuth/password

http://talk.maemo.org/showthread.php?p=1468543

edit flag offensive delete publish link

Comments

Multifactor is neat but it add's an other dependency (as in i would need a specific device to generate the TOTP token).

slaveriq ( 2015-07-13 17:37:00 +0300 )edit

2

Isnt security a bitch :)

Nieldk ( 2015-07-13 17:41:57 +0300 )edit

1

TBH it does not add much more security over SSH keys. But ofc TOTP would be easier to to setup in a GUI than typing in your public key.

And both solutions only protect you from someone guessing your password. Your phone would still spend way to much cpu time on something netfilter could sort out in no time for you ;)

slaveriq ( 2015-07-13 18:36:32 +0300 )edit

Answer 7

0

answered 2015-07-13 20:12:25 +0300

inte
3842 ●52 ●87 ●83

I'm using SSH access control from openrepos with serves fine for this purpose: https://openrepos.net/content/coderus/ssh-access-confirmation

edit flag offensive delete publish link

Answer 8

0

answered 2015-07-14 10:02:50 +0300

Nieldk

4562 ●40 ●70 ●76

If what you want is DOS related, then disable SSH is the best solution, if you need SSH and cant disable it, then iptables firewall is second choise.
If you want to further protect the login, Gauth works good and provides a good measure against brute-force attacks. And no, it doesnt prevent from trying. DOS, unlikely to happen, DDoS yes, could happen
Another mean is coderus ssh-access-confirmation. I would say same level of access protection as Gauth, but, it requires you to have your device near you to confirm access.
Simply use a strong password, that is difficult to guess ;)

edit flag offensive delete publish link

Answer 9

0

answered 2015-07-14 15:11:33 +0300

filipb92
490 ●7 ●12 ●20

You could install ssh access confirmation from https://openrepos.net/content/coderus/ssh-access-confirmation, you then have to approve each ssh connection on the device. Works like a charm.

edit flag offensive delete publish link

add fail2ban to prevent ssh bruteforcing

Comments

9 Answers

Comments

Comments

Comments

Comments

Comments

Question tools

Stats

Related questions

add fail2ban to prevent ssh bruteforcing

Comments

9 Answers

Comments

Comments

Comments

Comments

Comments

Question tools

Public thread

Stats

Related questions