12 Thousand invalid login attempts and counting


sol

Recommended Posts

I could really use some help deciding how to approach this problem and prevent this in the future. I've done a bunch of searching (these forums and reddit) and I'm just spinning my wheels at this point. 

 

Two days ago I upgraded to 6.4.1. During the process of this I made some other changes.

I generated an SSL cert, which seems to work fine. 
I also moved Sonarr from a plugin to a docker, which also seems to work fine. 

 

However, since upgrading, or maybe not related at all, I have somehow exposed my server to the internet resulting in the Fix Common Problems Plugin reporting that I have over 12k invalid login attempts over the past two days. (Mostly from China and Brazil.) EXAMPLES at end of post. 

 

My ISP is Google Fiber, which I love except for their terrible network box that really has nothing but port forwarding available for firewall features. 

 

I have three ports forwarded to my Unraid server for Plex, Ubooquity, and Teamspeak. The Teamspeak server uses duckdns so that my friends can get to it when my home IP rotates. 

Plex forwards connections themselves and Ubooquity is only used by me with a Ubooquity generated username and password. 

 

My public facing IP will eventually change with Google Fiber and I can force it by leaving the network box unconnected for about an hour. 

However, I would like to just have more security for my whole network in general and especially for this currently targeted unRAID box. 

 

Any immediate suggestions for my unRAID server are highly welcome. 

 

Any other suggestions regarding security with Google Fiber are also welcome, here or in private. 

 

Thanks. 

 

Feb 12 07:26:45 tmedia sshd[29184]: Disconnected from authenticating user root 61.177.172.188 port 45888 [preauth]
Feb 12 07:27:19 tmedia sshd[29270]: Failed password for root from 61.177.172.188 port 53730 ssh2
Feb 12 07:27:19 tmedia sshd[29270]: Failed password for root from 61.177.172.188 port 53730 ssh2
Feb 12 07:27:19 tmedia sshd[29270]: Failed password for root from 61.177.172.188 port 53730 ssh2
Feb 12 07:27:20 tmedia sshd[29270]: Received disconnect from 61.177.172.188 port 53730:11:  [preauth]
Feb 12 07:27:20 tmedia sshd[29270]: Disconnected from authenticating user root 61.177.172.188 port 53730 [preauth]
Feb 12 07:27:40 tmedia in.telnetd[29312]: connect from 187.10.72.47 (187.10.72.47)
Feb 12 07:27:41 tmedia login[29313]: invalid password for 'root'  on '/dev/pts/0' from '187-10-72-47.dsl.telesp.net.br'
Feb 12 07:27:45 tmedia login[29313]: invalid password for 'root'  on '/dev/pts/0' from '187-10-72-47.dsl.telesp.net.br'
Feb 12 07:27:49 tmedia login[29313]: invalid password for 'root'  on '/dev/pts/0' from '187-10-72-47.dsl.telesp.net.br'
Feb 12 07:27:53 tmedia login[29313]: invalid password for 'UNKNOWN'  on '/dev/pts/0' from '187-10-72-47.dsl.telesp.net.br'
Feb 12 07:27:53 tmedia sshd[29332]: Failed password for root from 61.177.172.188 port 53602 ssh2
Feb 12 07:27:53 tmedia sshd[29332]: Failed password for root from 61.177.172.188 port 53602 ssh2
Feb 12 07:27:54 tmedia sshd[29332]: Failed password for root from 61.177.172.188 port 53602 ssh2
Feb 12 07:27:54 tmedia sshd[29332]: Received disconnect from 61.177.172.188 port 53602:11:  [preauth]
Feb 12 07:27:54 tmedia sshd[29332]: Disconnected from authenticating user root 61.177.172.188 port 53602 [preauth]
Feb 12 07:27:56 tmedia login[29313]: invalid password for 'UNKNOWN'  on '/dev/pts/0' from '187-10-72-47.dsl.telesp.net.br'
Feb 12 07:27:56 tmedia login[29313]: REPEATED login failures on '/dev/pts/0' from '187-10-72-47.dsl.telesp.net.br'
Feb 12 07:28:00 tmedia in.telnetd[29365]: connect from 187.10.72.47 (187.10.72.47)
Feb 12 07:28:02 tmedia login[29366]: invalid password for 'root'  on '/dev/pts/0' from '187-10-72-47.dsl.telesp.net.br'
Feb 12 07:28:06 tmedia login[29366]: invalid password for 'root'  on '/dev/pts/0' from '187-10-72-47.dsl.telesp.net.br'
Feb 12 07:28:10 tmedia login[29366]: invalid password for 'root'  on '/dev/pts/0' from '187-10-72-47.dsl.telesp.net.br'
Feb 12 07:28:14 tmedia login[29366]: invalid password for 'root'  on '/dev/pts/0' from '187-10-72-47.dsl.telesp.net.br'
Feb 12 07:28:18 tmedia login[29366]: invalid password for 'UNKNOWN'  on '/dev/pts/0' from '187-10-72-47.dsl.telesp.net.br'
Feb 12 07:28:18 tmedia login[29366]: REPEATED login failures on '/dev/pts/0' from '187-10-72-47.dsl.telesp.net.br'
Feb 12 07:28:21 tmedia in.telnetd[29439]: connect from 187.10.72.47 (187.10.72.47)
Feb 12 07:28:23 tmedia login[29440]: invalid password for 'root'  on '/dev/pts/0' from '187-10-72-47.dsl.telesp.net.br'
Feb 12 07:28:27 tmedia login[29440]: invalid password for 'UNKNOWN'  on '/dev/pts/0' from '187-10-72-47.dsl.telesp.net.br'
Feb 12 07:28:30 tmedia sshd[29467]: Failed password for root from 61.177.172.188 port 31753 ssh2
Feb 12 07:28:30 tmedia sshd[29467]: Failed password for root from 61.177.172.188 port 31753 ssh2

 

Edited by sol
Link to comment

I can run that from a browser on a windows machine in the same network.

 

Common Ports test gives; 
----------------------------------------------------------------------

GRC Port Authority Report created on UTC: 2018-02-12 at 17:13:43

Results from scan of ports: 0, 21-23, 25, 79, 80, 110, 113, 
                            119, 135, 139, 143, 389, 443, 445, 
                            1002, 1024-1030, 1720, 5000

    0 Ports Open
   11 Ports Closed
   15 Ports Stealth
---------------------
   26 Ports Tested

NO PORTS were found to be OPEN.

Ports found to be CLOSED were: 0, 1002, 1024, 1025, 1026, 1027, 
                               1028, 1029, 1030, 1720, 5000

Other than what is listed above, all ports are STEALTH.

TruStealth: FAILED - NOT all tested ports were STEALTH,
                   - NO unsolicited packets were received,
                   - A PING REPLY (ICMP Echo) WAS RECEIVED.

----------------------------------------------------------------------

 

All Service Ports test gives; 
----------------------------------------------------------------------

GRC Port Authority Report created on UTC: 2018-02-12 at 17:23:42

Results from scan of ports: 0-1055

    0 Ports Open
   70 Ports Closed
  986 Ports Stealth
---------------------
 1056 Ports Tested

NO PORTS were found to be OPEN.

Ports found to be CLOSED were: 0, 1, 2, 3, 4, 30, 61, 62, 91, 
                               92, 121, 122, 151, 152, 181, 
                               182, 211, 212, 241, 242, 271, 
                               272, 301, 302, 332, 333, 362, 
                               363, 392, 393, 422, 423, 452, 
                               453, 483, 484, 513, 514, 544, 
                               545, 606, 607, 636, 637, 667, 
                               668, 696, 697, 726, 727, 756, 
                               757, 787, 788, 817, 818, 847, 
                               848, 877, 878, 907, 908, 938, 
                               939, 968, 969, 998, 999, 1028, 
                               1029

Other than what is listed above, all ports are STEALTH.

TruStealth: FAILED - NOT all tested ports were STEALTH,
                   - NO unsolicited packets were received,
                   - A PING REPLY (ICMP Echo) WAS RECEIVED.

----------------------------------------------------------------------

 

 

I don't run a browser inside unRAID.  

 

However I can run lsof -Pni | grep LISTEN to show all ports being used. Doesn't assess their vulnerability of course. 

 

rpcbind    1467    rpc    8u  IPv4    1727      0t0  TCP *:111 (LISTEN)
rpcbind    1467    rpc   11u  IPv6    1730      0t0  TCP *:111 (LISTEN)
rpc.statd  1471    rpc    9u  IPv4    9886      0t0  TCP *:44971 (LISTEN)
rpc.statd  1471    rpc   11u  IPv6    9890      0t0  TCP *:35775 (LISTEN)
inetd      1481   root    4u  IPv4    3480      0t0  TCP *:37 (LISTEN)
inetd      1481   root    6u  IPv4    3482      0t0  TCP *:21 (LISTEN)
inetd      1481   root    7u  IPv4    3483      0t0  TCP *:23 (LISTEN)
sshd       1489   root    3u  IPv4    2787      0t0  TCP *:22 (LISTEN)
sshd       1489   root    4u  IPv6    2789      0t0  TCP *:22 (LISTEN)
smbd       1526   root   29u  IPv6    1830      0t0  TCP *:445 (LISTEN)
smbd       1526   root   30u  IPv6    1831      0t0  TCP *:139 (LISTEN)
smbd       1526   root   31u  IPv4    1832      0t0  TCP *:445 (LISTEN)
smbd       1526   root   32u  IPv4    1833      0t0  TCP *:139 (LISTEN)
apcupsd    2628   root    4u  IPv4   11472      0t0  TCP *:3551 (LISTEN)
docker-pr  2647   root    4u  IPv6  340250      0t0  TCP *:8989 (LISTEN)
nginx      2712   root    7u  IPv4   10563      0t0  TCP *:80 (LISTEN)
nginx      2712   root    8u  IPv6   10564      0t0  TCP *:80 (LISTEN)
nginx      2712   root   15u  IPv4  210329      0t0  TCP *:443 (LISTEN)
nginx      2712   root   16u  IPv6  210330      0t0  TCP *:443 (LISTEN)
docker-pr  4970   root    4u  IPv6   18265      0t0  TCP *:9117 (LISTEN)
docker-pr  5311   root    4u  IPv6   19090      0t0  TCP *:8181 (LISTEN)
docker-pr  5508   root    4u  IPv6   22671      0t0  TCP *:2203 (LISTEN)
docker-pr  5525   root    4u  IPv6   21770      0t0  TCP *:2202 (LISTEN)
docker-pr  5802   root    4u  IPv6   21907      0t0  TCP *:5050 (LISTEN)
ts3server  6569 nobody   32u  IPv4   22270      0t0  TCP *:30033 (LISTEN)
ts3server  6569 nobody   33u  IPv6   22271      0t0  TCP *:30033 (LISTEN)
ts3server  6569 nobody   45u  IPv4   22282      0t0  TCP *:10011 (LISTEN)
ts3server  6569 nobody   46u  IPv6   22283      0t0  TCP *:10011 (LISTEN)
Plex\x20M  6731 nobody   59u  IPv4   25603      0t0  TCP *:32400 (LISTEN)
Plex\x20M  6731 nobody   61u  IPv4   25607      0t0  TCP 127.0.0.1:32401 (LISTEN)
Plex\x20S  7104 nobody    8u  IPv4   25950      0t0  TCP 127.0.0.1:33189 (LISTEN)
Plex\x20T  7573 nobody   14u  IPv4   25127      0t0  TCP 127.0.0.1:32600 (LISTEN)
Plex\x20D  7574 nobody   15u  IPv4   26709      0t0  TCP *:1894 (LISTEN)
Plex\x20D  7574 nobody   24u  IPv4   26722      0t0  TCP *:32469 (LISTEN)
Plex\x20S  7610 nobody    4u  IPv4   27781      0t0  TCP 127.0.0.1:42725 (LISTEN)
docker-pr 17802   root    4u  IPv6  883902      0t0  TCP *:58946 (LISTEN)
docker-pr 17814   root    4u  IPv6  883917      0t0  TCP *:58846 (LISTEN)
docker-pr 17825   root    4u  IPv6  883930      0t0  TCP *:8118 (LISTEN)
docker-pr 17837   root    4u  IPv6  882835      0t0  TCP *:8112 (LISTEN)
nginx     27811 nobody    7u  IPv4   10563      0t0  TCP *:80 (LISTEN)
nginx     27811 nobody    8u  IPv6   10564      0t0  TCP *:80 (LISTEN)
nginx     27811 nobody   15u  IPv4  210329      0t0  TCP *:443 (LISTEN)
nginx     27811 nobody   16u  IPv6  210330      0t0  TCP *:443 (LISTEN)
Plex\x20S 30083 nobody    4u  IPv4 2820813      0t0  TCP 127.0.0.1:44253 (LISTEN)
Plex\x20S 30124 nobody    4u  IPv4 2821797      0t0  TCP 127.0.0.1:43857 (LISTEN)
docker-pr 30144   root    4u  IPv6  292394      0t0  TCP *:51413 (LISTEN)
docker-pr 30156   root    4u  IPv6  289660      0t0  TCP *:9091 (LISTEN)
Plex\x20S 30193 nobody    4u  IPv4 2820904      0t0  TCP 127.0.0.1:38447 (LISTEN)
Plex\x20S 30231 nobody    4u  IPv4 2823356      0t0  TCP 127.0.0.1:39423 (LISTEN)
Plex\x20S 30256 nobody    4u  IPv4 2822469      0t0  TCP 127.0.0.1:39925 (LISTEN)

Link to comment

What kind of firewall/router are you using? Depending on the model and type of your firewall the results will vary. I use a business class firewall/appliance and if I run the test all ports come back stealth because my firewall detects the port scan and blocks it immediately. Consumer level/home routers and firewalls may not have this level of intelligence and so you will get some ports report as close rather then stealth. It seems likely however that port scans have been run against your firewall resulting in these connection attempts. First thing I would do it change your firewall so it doesn't respond to pings from the internet, that is the first thing hackers do, if they get a reply they know it's online and then they will run a port scan, turning this off doesn't mean you won't get scanned, it just reduces the likelihood.

Link to comment

As mentioned in my first post;

 

My ISP is Google Fiber, which I love except for their terrible network box that really has nothing but port forwarding available for firewall features. It has extremely limited firewall settings. Other settings include, setting static IPs for devices, setting DNS servers, setting DHCP (basic like address range), and setting an endpoint as a DMZ.  

 

One thing I could do is put some kind of appliance between the network box (router) and my endpoints, but I don't have an idea for that yet and it would need to be able to handle the 1gig up and down. 

 

Using a third party router on their system is possible but difficult. For example; 

https://www.stevejenkins.com/blog/2015/11/replace-your-google-fiber-network-box-with-a-ubiquiti-edgerouter-lite/

 

Putting something like fail2ban directly on unRAID would be a nice way to frustrate these attempts, but I haven't found a way to do that. 

 

Still looking for any ideas. 

 

I did contact Google Fiber and they can't do anything to my network box to mitigate the attacks. They can't even force it to change it's IP. 

Edited by sol
Link to comment

Yes, I do think the edgerouter lite as just a firewall may be a good option for my wired devices. Wireless would still be controlled by the Google fiber network box though. 

 

Replacing the network box (maybe more complicated than I can handle) and adding a wifi router would solve pretty much everything. 

 

I was hoping for a more simple solution, using unRAID and or docker, that could mitigate some of the possibility of attacks like this. 

 

I did find some information about using keys instead of a password for SSH, but most of the threads appear to be pretty old and not at all detailed for someone, like myself, who would need more specific instructions. This would make brute forcing SSH, like what is happening to me now, pretty much impossible. 

 

Link to comment

I've got basically the same setup as you (and google fiber).  I find that when I've opened port 22 to ssh into my machine those bots start trying to get in.  The solution for me was to change which port SSH operates on and only open it when needed.  I run lets encrypt and open vpn on my unraid machine so have those ports opened only.  In the end, from what i understand these attack attempts are expected when you open a port like 22 or a more common port.  I get the same results as you, but nobody is getting anywhere.

 

I guess what I'm getting at is the GF network box seems to be doing its job, only allowing in traffic in ports you've specified, and only with good auth.

 

For what it's worth I also have a unifi AP and have no ports forwarded for the controller and can still access the controller over the cloud.

Link to comment
  • 2 weeks later...
2 hours ago, sol said:

Still interested in getting a firewall I can actually control though. 

 

You might want to look at the Ubiquiti routers.  There is a lot of discussion on them in this thread:

 

      https://lime-technology.com/forums/topic/61265-what-router-are-you-running/

 

 

I choose this router when I was looking foe one with WI since I wanted to use a separate access point for WiFi and it was the only one that I could find at the time that didn't have a built-in WiFi.  I haven't been sorry.  There is a bit of a learning curve.  (Quick tip, When you first fire it up, look at the Setup Guide and as soon as you gain access to the GUI, go to the Wizards and pick one and the basic router functions will be up and running.)  

Link to comment
  • 2 weeks later...

Last month (Feb) I upgraded to 6.4.1. During the process of this I made some other changes, and generated an SSL cert, which seems to work fine. 

Haven't logged onto my system since, yesterday logged on and Fix Common Problems warned me of many logon attempts.

 

GRC Shields Up shows that all ports are stealth. I don't have any ports forwarded in my router.

 

Link to comment
18 minutes ago, Frank1940 said:

 

You need to post up your diagnostics file (   Tools   >>>   Diagnostics   )  with some of these login attempts in it.

I will next time I see them. Panicked yesterday and shut tower off. Turned back on today, and only see logs for today. I guess system gets reset on boot? 

Link to comment
13 hours ago, rott said:

if you have any old computer around you could load pfsense on it that is a great firewall with many options and it is totally free

Any old fairly recent computer. The newest versions of pfsense require some CPU features that aren't all that old.

 

Can you tell I'm a little miffed over not getting the latest security updates for a pfsense box that otherwise has plenty of performance but isn't new enough?

Link to comment
  • 3 weeks later...
On 2/12/2018 at 10:18 AM, sol said:

Two days ago I upgraded to 6.4.1. During the process of this I made some other changes.

I generated an SSL cert, which seems to work fine. 
I also moved Sonarr from a plugin to a docker, which also seems to work fine. 

 

However, since upgrading, or maybe not related at all, I have somehow exposed my server to the internet resulting in the Fix Common Problems Plugin reporting that I have over 12k invalid login attempts over the past two days.

 

 

I wonder if there was something unique about 6.4.1. All my login attempts started within a couple of days after upgrading to 6.4.1 and the log showed they attacked every few days until I upgraded to 6.5.0. There have been no log entries of attempted login since upgrading to 6.5.  Either a coincidence or there was some vulnerability in 6.4.1.

Link to comment
  • 3 weeks later...

Heya

 

I have the same issue and I think most people do when opening port 22 or similar:

 

Possible Hack Attempt on Apr 30 On Apr 30 there were 3231 invalid login attempts.
Apr 30 18:19:23 Fractal sshd[2723]: Failed password for root from 222.186.43.6 port 25836 ssh2

All mine are from the same IP. Is there a way to block attacker IP's?

Or all from a known list, like theses - https://report.cs.rutgers.edu/DROP/attackers

 

Making sure I have a strong password and changing it now and then is a good policy of course.

 

Thanks

Link to comment
  • 2 months later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.