ISP says my IP is sending out spam


luowilliam

Recommended Posts

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

  • Upvote 1
Link to comment
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.

Link to comment

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

Link to comment

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

 

Link to comment

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:::

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

Link to comment

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 by BRiT
Link to comment
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.

Link to comment

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 by nuhll
Link to comment
  • 2 weeks later...

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. 

 

Link to comment

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?

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

  • Like 1
Link to comment

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 by nuhll
Link to comment

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

 

Link to comment
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 by nuhll
Link to comment

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.