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.

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

Comments

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

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)

9 Answers

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.

Comments

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.

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

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.

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.

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

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.

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.

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.

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.