sol Posted February 12, 2018 Posted February 12, 2018 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
ashman70 Posted February 12, 2018 Posted February 12, 2018 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
sol Posted February 12, 2018 Author Posted February 12, 2018 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)
ashman70 Posted February 12, 2018 Posted February 12, 2018 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.
sol Posted February 12, 2018 Author Posted February 12, 2018 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.
ashman70 Posted February 12, 2018 Posted February 12, 2018 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?
ppunraid Posted February 12, 2018 Posted February 12, 2018 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.
sol Posted February 12, 2018 Author Posted February 12, 2018 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.
statecowboy Posted February 12, 2018 Posted February 12, 2018 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.
spencers Posted February 20, 2018 Posted February 20, 2018 Disable your port forwarding one-by-one to see if anything changes.
sol Posted March 2, 2018 Author Posted March 2, 2018 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.
Frank1940 Posted March 2, 2018 Posted March 2, 2018 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.)
Encino Stan Posted March 17, 2018 Posted March 17, 2018 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.
Frank1940 Posted March 17, 2018 Posted March 17, 2018 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.
Encino Stan Posted March 17, 2018 Posted March 17, 2018 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?
Frank1940 Posted March 17, 2018 Posted March 17, 2018 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.
rott Posted March 20, 2018 Posted March 20, 2018 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
JonathanM Posted March 20, 2018 Posted March 20, 2018 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?
Encino Stan Posted April 9, 2018 Posted April 9, 2018 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.
Ricco Posted May 1, 2018 Posted May 1, 2018 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
itimpi Posted May 1, 2018 Posted May 1, 2018 It is normally recommended that you do not expose unRAID directly to the internet, but instead set up a VPN server either on your unRAID machine or (if it supports it) on your router. That provides a much safer way of accessing unRAID remotely.
Stan464 Posted July 24, 2018 Posted July 24, 2018 Grab a Custom Made or PFSense Made Router/Firewall and have the Traffic float through that, Install the likes of Suricata & Snort & Fail2Ban, Sorted!
Recommended Posts
Archived
This topic is now archived and is closed to further replies.