sol

12 Thousand invalid login attempts and counting

19 posts in this topic Last Reply

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

Share this post


Link to post

I would go to this link and let it scan your firewall to see what ports you have exposed, you can do common ports or all ports which will take longer. It's harmless but very informative as it will tell you what you have open.

 

https://www.grc.com/x/ne.dll?bh0bkyd2

 

Share this post


Link to post

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)

Share this post


Link to post

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.

Share this post


Link to post

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

Share this post


Link to post

If you unplugged it for 15 min or half an hour I bet it would change the IP, but that depends on their TTL settings, it might be longer and so might not work.

 

You should enquire as to weather they can configure it as a passthrough device so you could put an appliance downstream. Is the service DSL or Cable?

Share this post


Link to post

why not just use the ubiquiti as your firewall instead of trying to replace the google fiber box? It's fully featured and can do everything else. I have google domains doing dns for me, but pretty sure you could use duckdns as well.

Share this post


Link to post

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. 

 

Share this post


Link to post

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.

Share this post


Link to post

Disable your port forwarding one-by-one to see if anything changes. 

Share this post


Link to post

Follow up!

 

I had to leave the network box (router) offline for over 30 minutes, but once I got a new ip all the attacks stopped. 

 

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

Share this post


Link to post
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.)  

Share this post


Link to post

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.

 

Share this post


Link to post
1 hour ago, Encino Stan said:

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

 

 

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

Share this post


Link to post
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? 

Share this post


Link to post

Absolutely, you want to wait until you have perhaps fifty to one-hundred attempts in the log file before you get  the diagnostics.  Then you should probably follow your instincts  and shut it down.

Share this post


Link to post

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

Share this post


Link to post
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?

Share this post


Link to post
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.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


Copyright © 2005-2018 Lime Technology, Inc.
unRAID® is a registered trademark of Lime Technology, Inc.