I’m looking at my server logs like a good system administrator, and the logins that correspond to my virual domains have lots and lots of su’s going against them. Here is an example:
Aug 8 03:09:05 146 su(pam_unix): session opened for user rock by (uid=0)
Aug 8 03:09:06 146 su(pam_unix): session closed for user rock
Aug 8 03:11:02 146 su(pam_unix): session opened for user travel by (uid=0)
Aug 8 03:11:03 146 su(pam_unix): session closed for user travel
I’m worried that I started working on security too late and there is already someone inside (or a program) trying to break into the other logins.
I recently turned on the firewall. Don’t know if that’s relevant, but thought I’d mention it.
I’m wondering if since these are the logins for my virtualmin domains, if maybe my new firewall rules are stopping Virtualmin from doing something. Maybe it’s Virtualmin trying to do the logins?
Nothing to be concerned about. It’s probably Dovecot’s POP daemon.
Note that these are root (uid=0) becoming a non-root user. No cracker would want to go that direction!
Hey, so I’m being hacked by a bunch of retards who are already root and don’t know it.
You understood it was root opening accounts because of (uid=0) in the log.
I don’t think it is dovecot pop because I don’t use email on that server and I have Dovecot turned off. I guess its not a big issue.
I also have hundreds of
Aug 9 10:30:11 146 named: lame server resolving ‘Ymir.Claremont.edu’ (in ‘CLAREMONT.edu’?): 18.104.22.168#53
but I guess that’s because so many people on the internet have forgotten how to set up their domains properly.
Thanks for the elucidation Joe! If it wasn’t for you, I’d be breaking my server in all sorts of ways attempting to fix stuff that was not broken. It is kind of like the deaf person who after she regains her hearing dials 911 when the refrigerator turns on.
Hey, so I'm being hacked by a bunch of retards who are already root and don't know it. ;-)
It could happen. I’ve seen some strikingly stupid script kiddies in my past as a security guy. But the rootkits that they install have gotten quite a bit more sophisticated over the years…if a script kiddie has root on your box, and he/she installs one of the better root kits, you won’t see any logs about their activity. They’ll be effectively invisible unless you know where to look (and even then, it can be a challenge).
The lame server bit is probably triggered by one or more attempts to send mail to that domain. But there are other ways such errors can show up. And you’re right that it is usually misconfiguration of the target server.
The su could be a number of things–many processes su to the user during the normal course of operation. procmail, ProFTPd, Usermin (but it might get there via another mechanism, I don’t recall), cron probably does, etc.