luowilliam Posted November 2, 2018 Share Posted November 2, 2018 My ISP called/emailed me and said my IP is used for sending out tons of spams. I scanned all my computers except for the unraid box. ISP still reporting spams. Last night, I shut down my unraid box and today ISP said they haven't seen any spam since. What can I do at this point to pin point what happened on the unraid box? Any help is welcome. Thanks in advance. William 1 Quote Link to comment
JonathanM Posted November 2, 2018 Share Posted November 2, 2018 Are there any rules in your router referencing your unraid box? Attach the diagnostics zip file here and someone will have a look. Quote Link to comment
luowilliam Posted November 2, 2018 Author Share Posted November 2, 2018 Sorry what do you mean by rules? Other then forwarding ports for torrents in Transmission there's nothing particular I put in. I will upload the diagnostic zip tonight. Thanks. Quote Link to comment
Jcloud Posted November 2, 2018 Share Posted November 2, 2018 17 minutes ago, luowilliam said: Sorry what do you mean by rules? Other then forwarding ports for torrents in Transmission there's nothing particular I put in. That's what Jonathanm was referring to, what ports on the router-firewall have been opened up and forwarded to your Unraid machine and it's hosted services (such Docker containers, virtual machines, and anything else). As an example, you mentioned your Transmission service. Quote Link to comment
luowilliam Posted November 2, 2018 Author Share Posted November 2, 2018 I will have to look at the machine for detail. What I remember now is the Transmission and Plex media server. Quote Link to comment
luowilliam Posted November 3, 2018 Author Share Posted November 3, 2018 Attached is my diagnostics. I used netstat to look at all the established connection can't see anything weird. Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:1967 0.0.0.0:* LISTEN 8608/Plex DLNA Serv tcp 0 0 0.0.0.0:sunrpc 0.0.0.0:* LISTEN 1562/rpcbind tcp 0 0 0.0.0.0:32400 0.0.0.0:* LISTEN 8503/./Plex Media S tcp 0 0 0.0.0.0:http 0.0.0.0:* LISTEN 4822/nginx: master tcp 0 0 NAS1:32401 0.0.0.0:* LISTEN 8503/./Plex Media S tcp 0 0 0.0.0.0:41361 0.0.0.0:* LISTEN 1567/rpc.statd tcp 0 0 0.0.0.0:32469 0.0.0.0:* LISTEN 8608/Plex DLNA Serv tcp 0 0 192.168.122.1:domain 0.0.0.0:* LISTEN 7000/dnsmasq tcp 0 0 0.0.0.0:ftp 0.0.0.0:* LISTEN 4726/inetd tcp 0 0 0.0.0.0:ssh 0.0.0.0:* LISTEN 4688/sshd tcp 0 0 0.0.0.0:telnet 0.0.0.0:* LISTEN 4726/inetd tcp 0 0 NAS1:32600 0.0.0.0:* LISTEN 8610/Plex Tuner Ser tcp 0 0 NAS1:34009 0.0.0.0:* LISTEN 8543/Plex Plug-in [ tcp 0 0 NAS1:41339 0.0.0.0:* LISTEN 8669/Plex Plug-in [ tcp 0 0 NAS1:16509 0.0.0.0:* LISTEN 6533/libvirtd tcp 0 0 0.0.0.0:microsoft-ds 0.0.0.0:* LISTEN 1632/smbd tcp 0 0 0.0.0.0:6789 0.0.0.0:* LISTEN 7309/nzbget tcp 0 0 0.0.0.0:netbios-ssn 0.0.0.0:* LISTEN 1632/smbd tcp 0 101 192.168.1.100:34378 news.iad.usenetser:8080 ESTABLISHED 7309/nzbget tcp 0 0 192.168.1.100:42758 news.iad.usenetser:8080 ESTABLISHED 7309/nzbget tcp 0 101 192.168.1.100:42778 news.iad.usenetser:8080 ESTABLISHED 7309/nzbget tcp 0 85 192.168.1.100:34342 news.iad.usenetser:8080 ESTABLISHED 7309/nzbget tcp 0 0 192.168.1.100:42802 news.iad.usenetser:8080 ESTABLISHED 7309/nzbget tcp 0 0 192.168.1.100:42798 news.iad.usenetser:8080 ESTABLISHED 7309/nzbget tcp 0 0 192.168.1.100:6789 172.17.0.3:42748 TIME_WAIT - tcp 0 0 192.168.1.100:34334 news.iad.usenetser:8080 ESTABLISHED 7309/nzbget tcp 1 0 192.168.1.100:56608 ec2-52-208-155-135:http CLOSE_WAIT 8608/Plex DLNA Serv tcp 0 0 192.168.1.100:42770 news.iad.usenetser:8080 ESTABLISHED 7309/nzbget tcp 0 0 192.168.1.100:42774 news.iad.usenetser:8080 ESTABLISHED 7309/nzbget tcp 0 0 192.168.1.100:6789 172.17.0.3:42756 TIME_WAIT - tcp 0 0 192.168.1.100:34322 news.iad.usenetser:8080 ESTABLISHED 7309/nzbget tcp 0 0 192.168.1.100:http 192.168.1.76:59168 ESTABLISHED 4823/nginx: worker tcp 0 0 192.168.1.100:ssh customer.worldstre:2494 ESTABLISHED 4871/sshd: adm [pri tcp 0 0 192.168.1.100:6789 172.17.0.4:33332 TIME_WAIT - tcp 0 0 192.168.1.100:6789 172.17.0.3:42760 TIME_WAIT - tcp 0 320 192.168.1.100:ssh 192.168.1.90:64131 ESTABLISHED 23142/sshd: root@pt tcp 0 0 192.168.1.100:34346 news.iad.usenetser:8080 ESTABLISHED 7309/nzbget tcp 0 0 192.168.1.100:6789 172.17.0.3:42750 TIME_WAIT - tcp 0 0 192.168.1.100:34360 news.iad.usenetser:8080 ESTABLISHED 7309/nzbget tcp 0 101 192.168.1.100:42754 news.iad.usenetser:8080 ESTABLISHED 7309/nzbget tcp 0 0 192.168.1.100:6789 192.168.1.76:59421 ESTABLISHED 7309/nzbget tcp 1 0 NAS1:57568 NAS1:34009 CLOSE_WAIT 8608/Plex DLNA Serv tcp 0 0 192.168.1.100:6789 172.17.0.3:42746 TIME_WAIT - tcp 0 0 192.168.1.100:34318 news.iad.usenetser:8080 ESTABLISHED 7309/nzbget tcp 0 0 192.168.1.100:6789 192.168.1.76:59420 ESTABLISHED 7309/nzbget tcp 0 0 192.168.1.100:6789 172.17.0.4:33330 TIME_WAIT - tcp 0 0 192.168.1.100:http 192.168.1.76:59606 ESTABLISHED 4823/nginx: worker tcp 0 0 192.168.1.100:6789 192.168.1.76:59396 TIME_WAIT - tcp 0 0 192.168.1.100:6789 192.168.1.76:59423 ESTABLISHED 7309/nzbget tcp 64 0 192.168.1.100:42750 news.iad.usenetser:8080 ESTABLISHED 7309/nzbget tcp 0 0 192.168.1.100:44246 184.105.148.98:https ESTABLISHED 8503/./Plex Media S tcp 0 0 192.168.1.100:42782 news.iad.usenetser:8080 ESTABLISHED 7309/nzbget tcp 0 0 192.168.1.100:6789 192.168.1.76:59397 TIME_WAIT - tcp 0 101 192.168.1.100:34362 news.iad.usenetser:8080 ESTABLISHED 7309/nzbget tcp 0 0 192.168.1.100:6789 192.168.1.76:59422 ESTABLISHED 7309/nzbget tcp 0 0 192.168.1.100:6789 172.17.0.4:33328 TIME_WAIT - tcp 0 0 192.168.1.100:34370 news.iad.usenetser:8080 ESTABLISHED 7309/nzbget tcp 0 0 192.168.1.100:34366 news.iad.usenetser:8080 ESTABLISHED 7309/nzbget tcp 0 0 192.168.1.100:34338 news.iad.usenetser:8080 ESTABLISHED 7309/nzbget tcp 0 0 192.168.1.100:6789 172.17.0.3:42758 TIME_WAIT - tcp 0 0 192.168.1.100:http 192.168.1.76:58751 ESTABLISHED 4823/nginx: worker tcp6 0 0 [::]:sunrpc [::]:* LISTEN 1562/rpcbind tcp6 0 0 [::]:http [::]:* LISTEN 4822/nginx: master tcp6 0 0 [::]:51413 [::]:* LISTEN 8156/docker-proxy tcp6 0 0 [::]:ssh [::]:* LISTEN 4688/sshd tcp6 0 0 [::]:60599 [::]:* LISTEN 1567/rpc.statd tcp6 0 0 [::]:8989 [::]:* LISTEN 7817/docker-proxy tcp6 0 0 [::]:9117 [::]:* LISTEN 6561/docker-proxy tcp6 0 0 [::]:microsoft-ds [::]:* LISTEN 1632/smbd tcp6 0 0 [::]:9091 [::]:* LISTEN 8169/docker-proxy tcp6 0 0 [::]:7878 [::]:* LISTEN 7459/docker-proxy tcp6 0 0 [::]:netbios-ssn [::]:* LISTEN 1632/smbd tcp6 0 0 192.168.1.100:9091 172.17.0.4:55036 TIME_WAIT - nas1-diagnostics-20181102-2314.zip Quote Link to comment
Squid Posted November 3, 2018 Share Posted November 3, 2018 Not the real expert here, but it appears that your server is facing the internet, as you have a ton of connections from 194.88.107.164 (Netherlands) Is this your IP address? Have you forwarded SSH ports, or popped the server into a DMZ? 1 Quote Link to comment
luowilliam Posted November 3, 2018 Author Share Posted November 3, 2018 Interesting, how did you see those connections? I guess it is kinda facing the internet because of the forwarded port for transmission and plex and SSH. How would I find out where the spam bot is and get rid of it? Quote Link to comment
BRiT Posted November 3, 2018 Share Posted November 3, 2018 Your box is likely compromised from your SSH server. Here are all the FAILED attempts from your server to port 25, which is SMTP (email) servers from your SSH daemon. This does not include successful connections to SMTP. As SQUID pointed out, you have SSH user 'adm' connecting from 194.88.107.164 . This is logged in your syslog file. STEP 1, remove your server from the internet. Nov 2 23:06:29 NAS1 sshd[16314]: error: connect_to 67.195.228.141 port 25: failed. Nov 2 23:07:00 NAS1 sshd[16656]: error: connect_to 104.47.124.33 port 25: failed. Nov 2 23:07:11 NAS1 sshd[17634]: error: connect_to 64.233.167.26 port 25: failed. Nov 2 23:07:22 NAS1 sshd[17977]: error: connect_to 104.47.126.33 port 25: failed. Nov 2 23:07:36 NAS1 sshd[18363]: error: connect_to 104.47.126.33 port 25: failed. Nov 2 23:07:50 NAS1 sshd[18761]: error: connect_to 104.47.126.33 port 25: failed. Nov 2 23:08:03 NAS1 sshd[19127]: error: connect_to 104.47.126.33 port 25: failed. Nov 2 23:08:16 NAS1 sshd[19562]: error: connect_to 104.47.48.33 port 25: failed. Nov 2 23:08:30 NAS1 sshd[19931]: error: connect_to 104.47.48.33 port 25: failed. Nov 2 22:56:44 NAS1 sshd[4871]: SSH: Server;Ltype: Version;Remote: 89.38.96.13-2494;Protocol: 2.0;Client: WinSCP_release_5.1.3 Nov 2 22:56:44 NAS1 sshd[4871]: SSH: Server;Ltype: Kex;Remote: 89.38.96.13-2494;Enc: aes128-ctr;MAC: hmac-sha2-256;Comp: none [preauth] Nov 2 22:56:45 NAS1 sshd[4871]: SSH: Server;Ltype: Authname;Remote: 89.38.96.13-2494;Name: adm [preauth] Nov 2 22:56:45 NAS1 sshd[4871]: Accepted none for adm from 89.38.96.13 port 2494 ssh2 Nov 2 22:56:45 NAS1 sshd[4871]: SSH: Server;Ltype: Authname;Remote: 89.38.96.13-2494;Name: adm [preauth] Nov 2 22:56:45 NAS1 sshd[4871]: Accepted none for adm from 89.38.96.13 port 2494 ssh2 Nov 2 23:03:38 NAS1 sshd[11159]: SSH: Server;Ltype: Authname;Remote: 194.88.107.164-64656;Name: adm [preauth] Nov 2 23:03:38 NAS1 sshd[11159]: Accepted none for adm from 194.88.107.164 port 64656 ssh2 Nov 2 23:06:20 NAS1 sshd[16300]: SSH: Server;Ltype: Authname;Remote: 194.88.107.164-59160;Name: adm [preauth] Nov 2 23:06:20 NAS1 sshd[16300]: Accepted none for adm from 194.88.107.164 port 59160 ssh2 Nov 2 23:06:30 NAS1 sshd[16314]: Disconnecting user adm 194.88.107.164 port 59160: oclose packet referred to nonexistent channel 0 Nov 2 23:06:31 NAS1 sshd[16619]: SSH: Server;Ltype: Authname;Remote: 194.88.107.164-63134;Name: adm [preauth] Nov 2 23:06:31 NAS1 sshd[16619]: Accepted none for adm from 194.88.107.164 port 63134 ssh2 Nov 2 23:07:00 NAS1 sshd[16656]: Disconnecting user adm 194.88.107.164 port 63134: oclose packet referred to nonexistent channel 0 Nov 2 23:07:01 NAS1 sshd[17597]: SSH: Server;Ltype: Authname;Remote: 194.88.107.164-57867;Name: adm [preauth] Nov 2 23:07:01 NAS1 sshd[17597]: Accepted none for adm from 194.88.107.164 port 57867 ssh2 Nov 2 23:07:11 NAS1 sshd[17634]: Disconnecting user adm 194.88.107.164 port 57867: oclose packet referred to nonexistent channel 0 Nov 2 23:07:12 NAS1 sshd[17948]: SSH: Server;Ltype: Authname;Remote: 194.88.107.164-61714;Name: adm [preauth] Nov 2 23:07:12 NAS1 sshd[17948]: Accepted none for adm from 194.88.107.164 port 61714 ssh2 Nov 2 23:07:22 NAS1 sshd[17977]: Disconnecting user adm 194.88.107.164 port 61714: oclose packet referred to nonexistent channel 0 Nov 2 23:07:23 NAS1 sshd[18334]: SSH: Server;Ltype: Authname;Remote: 194.88.107.164-49173;Name: adm [preauth] Nov 2 23:07:23 NAS1 sshd[18334]: Accepted none for adm from 194.88.107.164 port 49173 ssh2 Nov 2 23:07:36 NAS1 sshd[18363]: Disconnecting user adm 194.88.107.164 port 49173: oclose packet referred to nonexistent channel 0 Nov 2 23:07:37 NAS1 sshd[18734]: SSH: Server;Ltype: Authname;Remote: 194.88.107.164-54070;Name: adm [preauth] Nov 2 23:07:37 NAS1 sshd[18734]: Accepted none for adm from 194.88.107.164 port 54070 ssh2 Nov 2 23:07:50 NAS1 sshd[18761]: Disconnecting user adm 194.88.107.164 port 54070: oclose packet referred to nonexistent channel 0 Nov 2 23:07:51 NAS1 sshd[19120]: SSH: Server;Ltype: Authname;Remote: 194.88.107.164-58885;Name: adm [preauth] Nov 2 23:07:51 NAS1 sshd[19120]: Accepted none for adm from 194.88.107.164 port 58885 ssh2 Nov 2 23:08:03 NAS1 sshd[19127]: Disconnecting user adm 194.88.107.164 port 58885: oclose packet referred to nonexistent channel 0 Nov 2 23:08:04 NAS1 sshd[19531]: SSH: Server;Ltype: Authname;Remote: 194.88.107.164-63248;Name: adm [preauth] Nov 2 23:08:04 NAS1 sshd[19531]: Accepted none for adm from 194.88.107.164 port 63248 ssh2 Nov 2 23:08:16 NAS1 sshd[19562]: Disconnecting user adm 194.88.107.164 port 63248: oclose packet referred to nonexistent channel 0 Nov 2 23:08:17 NAS1 sshd[19908]: SSH: Server;Ltype: Authname;Remote: 194.88.107.164-51137;Name: adm [preauth] Nov 2 23:08:17 NAS1 sshd[19908]: Accepted none for adm from 194.88.107.164 port 51137 ssh2 Nov 2 23:08:30 NAS1 sshd[19931]: Disconnecting user adm 194.88.107.164 port 51137: oclose packet referred to nonexistent channel 0 Quote Link to comment
luowilliam Posted November 3, 2018 Author Share Posted November 3, 2018 So I have closed SSH port 22 on my router. Seems like the spamming stopped but do I need to worry about the box been compromised any other way? Also, If I would like to get Plex working over internet. What's the proper and secure way of doing that? Thanks for all the help. Quote Link to comment
BRiT Posted November 3, 2018 Share Posted November 3, 2018 I don't know how anyone was able to login as 'adm' as under standard unraid configuration that user has no password and can not login. Double check your password and shadow files on your USB drive [/boot/config/] and on the running system [/etc/]. The 'x' in passwd indicates the real data is in the shadow file. The '*' in the shadow file indicates no acceptable password. # grep adm /boot/config/passwd /etc/passwd /boot/config/passwd:adm:x:3:4:adm:/var/log:/bin/false /etc/passwd:adm:x:3:4:adm:/var/log:/bin/false # grep adm /boot/config/shadow /etc/shadow /boot/config/shadow:adm:*:14824:0:99999:7::: /etc/shadow:adm:*:14824:0:99999:7::: Quote Link to comment
luowilliam Posted November 3, 2018 Author Share Posted November 3, 2018 58 minutes ago, BRiT said: I don't know how anyone was able to login as 'adm' as under standard unraid configuration that user has no password and can not login. Double check your password and shadow files on your USB drive [/boot/config/] and on the running system [/etc/]. The 'x' in passwd indicates the real data is in the shadow file. The '*' in the shadow file indicates no acceptable password. # grep adm /boot/config/passwd /etc/passwd /boot/config/passwd:adm:x:3:4:adm:/var/log:/bin/false /etc/passwd:adm:x:3:4:adm:/var/log:/bin/false # grep adm /boot/config/shadow /etc/shadow /boot/config/shadow:adm:*:14824:0:99999:7::: /etc/shadow:adm:*:14824:0:99999:7::: Sorry, can you provide a little more explanation for this? Like how is it there's an adm account left there for default and the commands you provided. When I typed those in it says there is no such file or direcotry. Quote Link to comment
BRiT Posted November 4, 2018 Share Posted November 4, 2018 (edited) The grep command searches for strings inside of files. In this situation since your syslog shows multiple logins for user adm for ssh, so you should make sure the user is prevented from logging in. We can do that using the 2 grep commands I provided. The location /etc/ contains criticial configuration files for the running system in RAM. These files do NOT survive reboots and are replaced when the server reboots. The location /boot/config/ contains SAVED ciritical configurations files that are copied into /etc/ when unraid first boots up. These files survive reboots. The first grep command searches for all occurrences of adm in the file /boot/config/passwd and the file /etc/passwd. The second grep command searches for all occurrences of adm in the file /boot/config/shadow and the file /etc/shadow. Try the following 2 commands at the unraid command prompt / terminal prompt. grep adm /boot/config/passwd /etc/passwd grep adm /boot/config/shadow /etc/shadow They should produce output similar to what I posted above and will post below again. It the numbers may be different, but the PASSWD files should contain an 'x' after the username and the SHADOW files should contain an '*' after the username. If the two command do not produce files, then your system is likely majorly compromised and it would be wise reboot the system at least once and then try them again. If it still doesn't produce results then you should unplug it from the network until you start over from scratch with an entirely brand new USB drive from scratch so you can be certain no compromised configurations or scripts are reinstalling at reboot. Output results from the 2 commands: /boot/config/passwd:adm:x:3:4:adm:/var/log:/bin/false /etc/passwd:adm:x:3:4:adm:/var/log:/bin/false /boot/config/shadow:adm:*:14824:0:99999:7::: /etc/shadow:adm:*:14824:0:99999:7::: Edited November 4, 2018 by BRiT Quote Link to comment
luowilliam Posted November 5, 2018 Author Share Posted November 5, 2018 On 11/3/2018 at 6:55 PM, BRiT said: The grep command searches for strings inside of files. In this situation since your syslog shows multiple logins for user adm for ssh, so you should make sure the user is prevented from logging in. We can do that using the 2 grep commands I provided. The location /etc/ contains criticial configuration files for the running system in RAM. These files do NOT survive reboots and are replaced when the server reboots. The location /boot/config/ contains SAVED ciritical configurations files that are copied into /etc/ when unraid first boots up. These files survive reboots. The first grep command searches for all occurrences of adm in the file /boot/config/passwd and the file /etc/passwd. The second grep command searches for all occurrences of adm in the file /boot/config/shadow and the file /etc/shadow. Try the following 2 commands at the unraid command prompt / terminal prompt. grep adm /boot/config/passwd /etc/passwd grep adm /boot/config/shadow /etc/shadow They should produce output similar to what I posted above and will post below again. It the numbers may be different, but the PASSWD files should contain an 'x' after the username and the SHADOW files should contain an '*' after the username. If the two command do not produce files, then your system is likely majorly compromised and it would be wise reboot the system at least once and then try them again. If it still doesn't produce results then you should unplug it from the network until you start over from scratch with an entirely brand new USB drive from scratch so you can be certain no compromised configurations or scripts are reinstalling at reboot. Output results from the 2 commands: /boot/config/passwd:adm:x:3:4:adm:/var/log:/bin/false /etc/passwd:adm:x:3:4:adm:/var/log:/bin/false /boot/config/shadow:adm:*:14824:0:99999:7::: /etc/shadow:adm:*:14824:0:99999:7::: Thank you for the explanation. Here's what I got from the grep command: grep: /boot/config/passwd: No such file or directory /etc/passwd:_kadmin_admin:*:218:-2:Kerberos Admin Service:/var/empty:/usr/bin/false /etc/passwd:_kadmin_changepw:*:219:-2:Kerberos Change Password Service:/var/empty:/usr/bin/false /etc/passwd:_krb_kadmin:*:231:-2:Open Directory Kerberos Admin Service:/var/empty:/usr/bin/false grep: /boot/config/shadow: No such file or directory grep: /etc/shadow: No such file or directory Doesn't look good I guess right? So the next question is how would I restart from scratch and minimize the amount of work I have to do in the configuration? Thanks. Quote Link to comment
NewDisplayName Posted November 10, 2018 Share Posted November 10, 2018 (edited) You shoulnt face unraid to the internet. Its not build (hardended) for that. If i were u, i would setup unraid from scratch bc its very hard to say what they exactly altered or if there are any other backdoors. Why u had ssh open to internet? (thats like the worst idea) If u want to open any other service like plex, i would change the standard port for that app, maybe something high like 61355. If there is a security hole in that app, they could still take over server, but its unlikly to happen. And just redirect that port to plex (unraid). But ssh gets scanned like 12098392183 mrd times a second Edited November 10, 2018 by nuhll Quote Link to comment
Abnorm Posted November 23, 2018 Share Posted November 23, 2018 If you need access to stuff on your unraid from the interwebs, base this around VPN. Assume services are in themselves unsecure (for example ssh). At least for ssh (and other common services, like Plex, FTP etc) never forward and use default ports as these will mitigate 99% of all automated scans from bots, but you should never access your server this way. Using default ports is a bad practice and gives hackers a good idea of what you're hosting on your box and could utilize new vulnerabilities as they're exposed. Hackers mostly does not like manual labor but if you've caught their interest they'll give it a more direct effort. Quote Link to comment
ryoko227 Posted November 26, 2018 Share Posted November 26, 2018 This is all really good info! Sorry the OP got hacked, but it's helpful to see a "what not to do" case. I tried something similar once on a test rig, dropping the unRAID IP into the DMZ.... OMG! The literal NON-STOP SSH login attempts were insane. Needless to say, that test rig got a complete wipe after that experience. Back on point though, @Abnorm I just wanted to bounce this off you since it seems related to what the OP is trying to fix and also to make sure that I'm doing this correct. I have a OpenVPN docker, with the default port forwarding setup on the router, and named via duckdns. Is it relatively safe to assume, that unless someone finds a vulnerability in OpenVPN itself, that this rather standard method should be predominantly secure? Quote Link to comment
Abnorm Posted November 29, 2018 Share Posted November 29, 2018 On 11/26/2018 at 6:51 AM, ryoko227 said: This is all really good info! Sorry the OP got hacked, but it's helpful to see a "what not to do" case. I tried something similar once on a test rig, dropping the unRAID IP into the DMZ.... OMG! The literal NON-STOP SSH login attempts were insane. Needless to say, that test rig got a complete wipe after that experience. Back on point though, @Abnorm I just wanted to bounce this off you since it seems related to what the OP is trying to fix and also to make sure that I'm doing this correct. I have a OpenVPN docker, with the default port forwarding setup on the router, and named via duckdns. Is it relatively safe to assume, that unless someone finds a vulnerability in OpenVPN itself, that this rather standard method should be predominantly secure? Hey, a bit late to the party, sorry. Yeah I had the same experience once, so i read up on it and asked some security dudes at work, they gave me a crash course. A good mindset (for interwebs stuff specifically:)) is to always assume a vulnerability exists, you are never safe, regardless of what you do. 🐱👤 In my mind i would say you're in a good spot (or as a good spot you can get) regarding how you've setup your system for remote access. I would do the same, I'm just going to use a reverse dns as well, just think the available duckdns domains are boring . But this will not increase security by any measure. Its just an A-record for my own domain that points to the registered duckdns-domain, as IPs are not likely to change much when i get my fibre at the end of the year. 1 Quote Link to comment
NewDisplayName Posted November 29, 2018 Share Posted November 29, 2018 (edited) For my part, i think vpn is more insecure way to access something in your network. I think its more likly that someone hacks VPN then e.g. a plex account, also when they are successfull on vpn, they have your whole network. But most ppl have a different opionion on that. I only have plex and ts3 (if i need it and start it) and RDP reachable from outside. All on non standard ports. Edited November 29, 2018 by nuhll Quote Link to comment
luowilliam Posted November 29, 2018 Author Share Posted November 29, 2018 To start a unraid from scratch, is there a way to do so without affecting the data on my disks? I have no idea how to approach this. Thanks. Quote Link to comment
JorgeB Posted November 30, 2018 Share Posted November 30, 2018 Backup flash drive, format flash drive and set it up like a new install, from the backup only restore the key file and super.dat, both on the config folder, this will only keep the disks assignments, everything else will need to be reconfigured, name, lan settings, etc. Quote Link to comment
scouserontour Posted December 5, 2018 Share Posted December 5, 2018 Hi, this is all very interesting and made me look at my system. Here is the output I get: grep adm /boot/config/passwd /etc/passwd /boot/config/passwd:adm:x:3:4:adm:/var/log:/bin/false /etc/passwd:adm:x:3:4:adm:/var/log:/bin/false grep adm /boot/config/shadow /etc/shadow /boot/config/shadow:adm::14824:0:99999:7::: /etc/shadow:adm::14824:0:99999:7::: So if I understand correct, adm doesn't require a password. Any ideas as to why that would be the case, if the default is :*:? I have setup my router to DNAT to Plex on 32400 and linuxserver/letsencrypt on 80 and 443. I am running Unraid 6.6.6. Thanks Quote Link to comment
NewDisplayName Posted December 6, 2018 Share Posted December 6, 2018 (edited) 3 hours ago, scouserontour said: Hi, this is all very interesting and made me look at my system. Here is the output I get: grep adm /boot/config/passwd /etc/passwd /boot/config/passwd:adm:x:3:4:adm:/var/log:/bin/false /etc/passwd:adm:x:3:4:adm:/var/log:/bin/false grep adm /boot/config/shadow /etc/shadow /boot/config/shadow:adm::14824:0:99999:7::: /etc/shadow:adm::14824:0:99999:7::: So if I understand correct, adm doesn't require a password. Any ideas as to why that would be the case, if the default is :*:? I have setup my router to DNAT to Plex on 32400 and linuxserver/letsencrypt on 80 and 443. I am running Unraid 6.6.6. Thanks If i understand your question correct. youre asking why adm has no password? It doesnt need a password, because its not allowed to login, thats why its shell is "/bin/false". "An emergent use of /bin/false, as you identified, is as a null shell for users not allowed to log in. The system in this case will behave exactly as though the shell failed to run." https://serverfault.com/questions/519215/what-is-the-difference-between-sbin-nologin-and-bin-false Edited December 6, 2018 by nuhll Quote Link to comment
BRiT Posted December 6, 2018 Share Posted December 6, 2018 But could it still issue remote shell commands without logging in? Quote Link to comment
NewDisplayName Posted December 6, 2018 Share Posted December 6, 2018 (edited) 10 minutes ago, BRiT said: But could it still issue remote shell commands without logging in? as far as i know: no. If so, all unraid machines on this planet would be hacked Without login, no commands. Edited December 6, 2018 by nuhll Quote Link to comment
Recommended Posts
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.