# Multiple ssh login attempts inside my system...



## ziomario (Oct 14, 2021)

Hello. Today I gave a look at the sshd logs to see if everything was ok and I found a lot of login attempts like these :


```
sshd[8427]: Failed keyboard-interactive/pam for invalid user joro from 171.245.46.121 port 44986 ssh2
sshd[8427]: Connection closed by invalid user joro 171.245.46.121 port 44986 [preauth]
sshd[8409]: Invalid user sakura from 116.110.85.5 port 41606
sshd[8409]: Postponed keyboard-interactive for invalid user sakura from 116.110.85.5 port 41606 ssh2 [preauth]
sshd[8409]: error: PAM: Authentication error for illegal user sakura from 116.110.85.5
sshd[8409]: Failed keyboard-interactive/pam for invalid user sakura from 116.110.85.5 port 41606 ssh2
sshd[8409]: Connection closed by invalid user sakura 116.110.85.5 port 41606 [preauth]
sshd[8448]: Address 116.98.168.134 maps to dynamic-ip-adsl.viettel.vn, but this does not map back to the address.
sshd[8448]: Invalid user kelly from 116.98.168.134 port 46446
```

can someone explains if it is a normal behavior ? really someone wants to login inside my system ?


----------



## covacat (Oct 14, 2021)

there are countless bots doing this
have a look at security/py-fail2ban


----------



## mer (Oct 14, 2021)

Take a look at some of the posts by Trihexagonal he's posted a really good simple pf.conf that is designed to be a firewall for a workstation.
Or add the following to your /etc/rc.conf and reboot the system:
firewall_enable="yes"
firewall_type="workstation"


----------



## ralphbsz (Oct 14, 2021)

ziomario said:


> can someone explains if it is a normal behavior ? really someone wants to login inside my system ?


Yes, completely normal. Open ports have a high rate of hack attacks. I measured it a while ago: If you have a machine with an IPv4 address and an open port 22, even if that machine is not publicly known anywhere and not associated with a particularly valuable DNS name (not a corporate machine, just a generic cloud or ISP address), you get on average a few thousand ssh login attempts per day. These are hackers looking for machines with well-known accounts or vulnerable passwords.

The same thing happens to http and https ports. Probably to many others too.

One typical indicator: If you look at the IP addresses these attacks come from, they are usually Russia, China, Vietnam, and a handful of other countries with state-sponsored hacking, non-functioning legal systems, but good internet connectivity. If your machine is in a typical first-world country, you can pretty accurately assume that all IP connections from these countries are either hack attacks, or search engines (such as Yandex and Baidu) spidering.

There are many ways of defending against this. The simplest one: If this is a single-user workstation, just turn sshd off. No more logins, no more hacking. If you don't need a web server, turn that off too. Similar for all other network-reachable services (SMTP, NFS, ...). Typically, the default firewall config for workstations accomplishes just that.

But this advice doesn't always work. Maybe your machine is a multi-user server; maybe people really need to log into it, or maybe it does need to serve useful data over the web. In that case, the next advice is: Make your machine actually secure. Ensure that all user accounts have good passwords. Disable root login over the network. Turn off http, and only leave https running. Make sure there are no CGI scripts that you don't understand. Set up .htaccess files to make sure data you want to keep private but that needs to be served by the web server is only readable by authorized parties.

Perhaps you can easily restrict these ports to internal networks? For example, at home we have a firewall router that separates the internal 192.168.0.X network from the dirty dangerous world-wide internet. Then I configure internal machines to accept ssh incoming connections only from 192.168.0.X, not from any other network.

A really effective (but not fully secure) way to reduce the frequency of such attacks is to disable port 22 (for ssh, similarly ports 80 and 443 for http and https), and move them to random ports. Don't pick the common values 2222 or 8888, have some more imagination. Like that your legitimate users have to work a little harder (instead of ssh user@server.example.com they have to do ssh -p 54321 user@server.example.com, or https://server.example.com:54321). But since scanning all possible ports takes about 65536 times longer, the normal hackers just don't do it. On my machine, this has reduced the frequency of random hack from thousands per day to a handful per month. This is not actually secure (it's security through obscurity), but it reduces the load to where it is tolerable.

If you are not located in the countries like Russia, China and Vietnam, another solution is to configure your upstream networking to block *ALL* IP addresses from those countries. Depending on how your networking is done, this can be trivial (some cloud providers have check boxes on their control panels for that), to very tedious (I think China uses several thousand IP blocks, and hand-copying all those into a pf.conf would take all day). Obviously, this situation doesn't work if you need connectivity to those places, in particular if you live in them.

Making computers secure is a huge field of study. The few things mentioned above are just the beginning.


----------



## ShelLuser (Oct 14, 2021)

In addition to the above I'd also strongly suggest to disable PAM authentication completely and instead switch to keybased authentication. This makes it nearly impossible for anyone to logon without the correct key.


----------



## eternal_noob (Oct 14, 2021)

ralphbsz said:


> A really effective (but not fully secure) way to reduce the frequency of such attacks is to disable port 22 (for ssh, similarly ports 80 and 443 for http and https), and move them to random ports.


Does that really work? I always thought this was security by obscurity (which doesn't work)...


----------



## ziomario (Oct 14, 2021)

ShelLuser said:


> In addition to the above I'd also strongly suggest to disable PAM authentication completely and instead switch to keybased authentication. This makes it nearly impossible for anyone to logon without the correct key.



how can I disable PAM ?


----------



## eternal_noob (Oct 14, 2021)

ziomario said:


> how can I disable PAM ?











						stop sshd from asking for password
					

I am trying to disallow password login to my ssh server, but can't. I have set: PasswordAuthentication no in /etc/ssh/sshd_config and have reset the deamon with: service sshd restart and killall -HUP sshd neither of these work, when logging it still asks me for my password, when asked for the...




					forums.freebsd.org


----------



## ralphbsz (Oct 14, 2021)

eternal_noob said:


> Does that really work? I always thought this was security by obscurity (which doesn't work)...


As I said above: No, it doesn't actually make your system secure. An intelligent attacker who is specifically targeting your system and has much time to waste will get through this easily. All they have to do is try all ~two dozen common prototols on all 65535 ports.

But it greatly reduces the number of attacks from mostly clueless script-kiddies. So after you have made your system secure (good passwords, use keys only, disable remote login for all or a few critical accounts, ...), this will reduce the number of entries in /var/log/auth.log so a human can look at it without complex tools and verify that no real attacks have happened. So this is a good technique to make life easier.

The same is true with my suggested remedy of blocking all traffic from Russia, China, Vietnam, ...: No, it does not make your system actually secure. It just reduces the number of attacks by several orders of magnitude, meaning you can spend more time making the system secure against what you consider real threats.


----------



## gpw928 (Oct 14, 2021)

eternal_noob said:


> Does that really work? I always thought this was security by obscurity (which doesn't work)...


Security by obscurity works very well -- until it fails.  Just ask the CIA.

I used to forward port 22 from my firewall to inside the network (login by ssh key only).

I was getting ready to configure port knocking, but never needed to do that.

When I reconfigured sshd to listen on a high (unpredictable) port number, the numerous attacks stopped completely.

I concluded that the attacks are mostly run by script kiddies who are just relying on the default configuration of the tools they use, and with port 22 closed, they just gave up.

Stopping the attacks really mattered to me, as my Internet connection is cellular mobile, and I pay for both the inbound and outbound traffic.


----------



## gpw928 (Oct 14, 2021)

ziomario said:


> how can I disable PAM ?


As others have indicated, exposing your system to the Internet without a basic firewall running is extremely dangerous.

How do you connect to the Internet?  Is there some sort of appliance between your FreeBSD system and a service provider's plug in the wall?

Such appliances will usually have a firewall in default configuration to prevent entry into your "internal network" from external sources.

If you have such an appliance, you need to attend to its configuration.

If your FreeBSD system is connected directly to the Internet, then you need to enable your host-based firewall, as suggested by mer above.

Configuring sshd depends on the answers to the questions above.  If you disable PAM, you may shoot yourself in the foot (depending on your situation).

If you tell us exactly how you connect to the Internet, the advice will improve.


----------



## D-FENS (Oct 14, 2021)

Indeed, best security is: real security + obscurity. Can't hurt to make them look for the honey, right?
And a couple of tricks:

use a large port number, this way you'll make them sweat before they scan and find it. Never use standard port numbers like 22.
configure port-knocking if you have the nerve for it.
disable password authentication, login via key only. Use "PermitRootLogon prohibit-password", or simply "no" and sudo after login.
if you have a fixed set of IP addresses (or network IP-ranges) from which you login, you can configure your firewall to allow only those source IPs and nothing else, so the botnets will get the short end of it.
create honey-pots - open a multiple SSH ports - most of which lead to a jailed honeypot that gets rolled-back via ZFS every minute. Only one SSH port should lead to your real server.
 That'll show 'em!


----------



## richardtoohey2 (Oct 14, 2021)

gpw928 said:


> When I reconfigured sshd to listen on a high (unpredictable) port number, the numerous attacks stopped completely.


Worked for me for a number of years, but not so effective any more.  Definitely reduces the noise, but not completely.

Dedicated firewall plus firewall on server, move ports, logging, monitoring, patching, patching, patching, reading, locking down, geo-blocking, turning off any unneeded services, and still a huge sprinkle of luck.

Swiss cheese model: https://en.wikipedia.org/wiki/Swiss_cheese_model

When I was reading the "breaking" news about the Apache 0-day the other day - my server logs already loaded with attacks - prevented by the Apache default deny.

As soon as it's on the internet, the scripts will find it.


----------



## dd_ff_bb (Oct 15, 2021)

I have simple setup but i guess it works for ssh logins:

All servers i'm managing only accept ssh from single ip with key authentication.

This machine/ip is $5 vps.

I use this vps as jump host (ssh -J) from my workstation so it doesn't have my private key which servers require for authentication and its knownhosts file is empty.

(it only has pub key of my workstation) (i also have another jump host from another provider in different region for backup)

I took snapshot of this vps when i first set it up and randomly roll it back from that snapshot.

(if i have to update this host first i roll it back, update and take new snapshot)

Nothing runs on this vps and all ports blocked.

Vps only accepts ssh from my workstation ip (its dynamic ip) whenever my ip changes i login to vps via console and update it
(my ip only changes 2-3 times through the year)

Also this is the only vps under this specific account in case console access blows.


----------



## Tieks (Oct 15, 2021)

ziomario said:


> really someone wants to login inside my system ?


They must be mistaken, Zio. I for sure wouldn't even dare to. 

Another way to secure sshd: I have an AVM Fritzbox router that does both internet and phone. These things allow you to open a port to the internal network to read data on phone calls. So I wrote a daemon script that not just logs phone calls, but will also `service sshd onestart` on an incoming call from my smartphone number to my home number. Added a high port and key authentication. I haven't seen such a login attempt in many years.


----------



## D-FENS (Oct 15, 2021)

dd_ff_bb said:


> I have simple setup but i guess it works for ssh logins:
> 
> All servers i'm managing only accept ssh from single ip with key authentication.
> 
> ...


That's a great solution, simply genius!


----------



## mrbeastie0x19 (Oct 15, 2021)

Some of these attacks are actually used to exploit vulnerable IOT devices with default user and password settings... Smart right. They are then sometimes used in clusters to deny service. Unless it is a targeted attack you can bet most of these are just script-kiddies running common off the shelf tools they found on the Internet.


----------



## ziomario (Oct 16, 2021)

dd_ff_bb said:


> I have simple setup but i guess it works for ssh logins:
> 
> All servers i'm managing only accept ssh from single ip with key authentication.
> 
> ...



what about to create one ssh tunnel with tor or with a vpn ?


----------



## D-FENS (Oct 16, 2021)

ziomario said:


> what about to create one ssh tunnel with tor or with a vpn ?


As far as I know the opposite is more secure: Create an SSH tunnel and then login via a VPN. That's what I do for a really secure setup.
I have heard that SSH is more secure than SSL to date, provided you use good encryption and disable password login.


----------



## ziomario (Oct 21, 2021)

this can be the tutorial that can allows me to do what you have suggested ? ---> https://www.getfilecloud.com/blog/create-your-own-virtual-private-network-for-ssh-with-putty/


----------



## Deleted member 30996 (Oct 21, 2021)

ralphbsz said:


> If you are not located in the countries like Russia, China and Vietnam, another solution is to configure your upstream networking to block *ALL* IP addresses from those countries. Depending on how your networking is done, this can be trivial (some cloud providers have check boxes on their control panels for that), to very tedious (I think China uses several thousand IP blocks, and hand-copying all those into a pf.conf would take all day). Obviously, this situation doesn't work if you need connectivity to those places, in particular if you live in them.


When I used pfSense we utilized countryblocks.net to block access from countries or whole continents with lists they provide that you can generate to suit your needs in several different formats. Apache, ip tables, IP ranges, etc.

You can choose to block Asia and it will automatically select all countries to generate a list from.

Don't forget the Democratic People's Republic of Korea:

```
57.73.224.0/19
77.94.35.0/24
175.45.176.0/22
```

I don't allow myself remote access and block remote access to ports for the services I do have running.


----------



## decuser (Oct 23, 2021)

eternal_noob said:


> ziomario said:
> 
> 
> > how can I disable PAM ?



Disabling PAM is a bit involved and unnecessary. Just disable PAM authentication in sshd.conf and restart the daemon.


----------



## KenGordon (Oct 24, 2021)

I have been reading Michael Lucas' book "Absolute FreeBSD", and not only find it extremely educational, but also very entertaining.  So far, I have found 3 typos. (Heh, heh ) 
I am in the Chapters devoted to security, and after reading those I am almost afraid to continue with my project of building a desktop for my family to enable them to get off Billy's crap.

I'm not really interested in building a server. I did that for long enough at the University of Idaho for some 30 years, and don't care to do it again. But I DO want to build secure desktop computers for my family and myself.

Trihex's tutorial on PF will be one thing I will most certainly install, but from Lucas' book, there are still innumerable holes in any system that some jackass could exploit.

Our router does have a built-in firewall, but from what has been discussed here, I am going to have to really dig into my system to get it secure. What a PITA. I really miss the days before the internet (Bitnet?), which was also before there were any hackers. Damn them all.

Gee.... :-(

Ken Gordon


----------



## KenGordon (Oct 24, 2021)

I suppose that this might be a good place to clarify this: for a simple desktop (yeah, "simple", sure...), I would think that there are no, or very, very few, "services" such a machine should be set up to provide....like none? I am thinking of print services, primarily, but our printers are all networked, so why would I need that one?

Now, I DO need to be able to work with other computers in our network, since all have files on them that we need to pass back and forth. So, I guess I am going to have to do a lot more studying on this matter. 

However, I would gladly accept any words of wisdom from you more-experienced folks here.

Ken Gordon


----------



## KenGordon (Oct 24, 2021)

Also, of course, I am going to have to be able to interface with some WinDOZE boxes here....at least for a while.

Ken Gordon


----------



## Sevendogsbsd (Oct 25, 2021)

eternal_noob said:


> Does that really work? I always thought this was security by obscurity (which doesn't work)...


It is but it may cut down on the number of scans. Most of the scans are automated and are looking for well known ports. A determined attacker (human) is going to run a full port scan to determine what is open and target that.


----------



## ziomario (Oct 25, 2021)

Sevendogsbsd said:


> It is but it may cut down on the number of scans. Most of the scans are automated and are looking for well known ports. A determined attacker (human) is going to run a full port scan to determine what is open and target that.



I'm not so sure. A human can't make a lot of full port scans since he wouldn't have the time. Even because hackers know that a good sys administrator does not want to use common ports.


----------



## Sevendogsbsd (Oct 25, 2021)

Cyber criminals have nothing but time. The port is irrelevant; if I find an open port, I will attack it. Doesn’t matter if you  run on a non standard port, people can still find it. My comment was running on a non standard port can reduce the number of automated (bot) scans because those are trying well known ports.


----------



## richardtoohey2 (Oct 26, 2021)

Sevendogsbsd said:


> My comment was running on a non standard port can reduce the number of automated (bot) scans because those are trying well known ports.


It definitely makes a difference, so it's worth doing if you can.  But it's not a top-level defence, just something to cut down the (logging) noise and the script-kiddies a bit.

A few years ago moving the ssh port meant a quiet life, nowadays it's not so useful.  But YMMV!


----------

