systemd (and sd-pam) in userspace

etienne_marais

etienne_marais

Honorary Master
Joined
Mar 16, 2008
Messages
16,250
Reaction score
19,740
Location
Centurion
Being in the habit of not closing ssh connections before disconnecting from the network at work and packing up and having no stale processes running by the time I get home and reconnecting, I was surprised to see 3 instances of my username when running "who".

When I did ps -alu <username> I saw 3 sshd connections and killed 2 with the oldest pid's (before realizing that there may be more to it). Apart from that there was also a systemd process running under this non-administrative/non-root user as well as a process "(sd-pam)", both of which I killed.

Furthermore df reported 0% diskspace left on some system critical mounts:

udev 412872 0 412872 0% /dev
tmpfs 87360 10772 76588 13% /run
/dev/mapper/ubuntu--vg-root 8662024 8334088 0 100% /
tmpfs 436796 0 436796 0% /dev/shm
tmpfs 5120 0 5120 0% /run/lock
tmpfs 436796 0 436796 0% /sys/fs/cgroup
/dev/sdb1 51474044 28767828 20068444 59% /datadir
/dev/sda2 483946 329421 129540 72% /boot
/dev/sda1 523248 7004 516244 2% /boot/efi
tmpfs 87360 0 87360 0% /run/user/1000

All my disk intensive stuff goes into /datadir but it has been a while since I checked free space on mounts.

/run/user/1000 contains a folder systemd with subfolders 'notify' and 'private', both with suid flags, but both user and group are the <username> and not root. The 'file' command reports that both are sockets.

I have not spawned any long running daemons or process using <user>, only with root after doing su from <username>

What is the probability of this being related to a hacking attempt vs. something to do with system going weird due to running out of space on the above mentioned mounts ?
 
It seems likely to be a hacking attempt.

tail -f /var/log/auth.log shows repeated attempts of root ssh connections from an ip in China. Unless that is simply how it goes for all servers.
 
Last edited:
etienne_marais said:
It seems likely to be a hacking attempt.

tail -f /var/log/auth.log shows repeated attempts of root ssh connections from an ip in China. Unless that is simply how it goes for all servers.
Click to expand...

If SSH is open to public you will see loads of them all the time.

Can usually set sshd to drop the connection after too many attempts. Also consider changing the default port and revoking root SSH access if you have run it open to public
 
bin3 said:
If SSH is open to public you will see loads of them all the time.

Can usually set sshd to drop the connection after too many attempts. Also consider changing the default port and revoking root SSH access if you have run it open to public
Click to expand...

Thanks bin3.

In the meantime I noticed that on a different server systemd and "(sd-pam)" was also running in userspace (i.e. not as root). So either this is simply a normal spawned process or both servers are being targeted, same goes for the 0% free mounts which then probably equates to always 100% used mounts (i.e. the mount disksize grows as needed, alway being filled 100%). If all is indeed in order then I'm relieved, never paid much attention to these things...
 
bin3 said:
If SSH is open to public you will see loads of them all the time.

Can usually set sshd to drop the connection after too many attempts. Also consider changing the default port and revoking root SSH access if you have run it open to public
Click to expand...

SSH on a non standard port is useless. Not hard to do a portscan.

Obfuscation is NOT security.

I'd recommend that OP looks at fail2ban / not allowing root over ssh (as you've mentioned) / keys if not in place (and removing password auth) / and possibly port knocking (i really like the idea) so SSH is only exposed when absolutely necessary. I'd also consider locking SSH to connections from a set IP / IP range (if possible).
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X