Default Passwords

[Jab]

I recently started a job at a small accounting firm and I'm the only person in the IT department. The person who setup our mail server has left the company. I know a little about linux and I learn something new everyday. I was going through the logs today I noticed that someone was trying to login into one or more of the default user accounts to read or send mail. I'm not sure if they were successful. So my question is what is the worst that can happen if I change all the passwords on the default accounts. I don't imagine the world will end but if I change some of the passwords and something stops working (like the email) I'll have 50 people crapping on my head.

 

I think my system has been compromised:

 

Users logging in through sshd: root:

10.10.2.57 (J_Bailey_Desktop): 2 times

spam:

58.213.125.25: 1 time

 

I have no idea what the password for the spam account is and spam's shell is set to bin/false so how could this have happened? I have disabled login for this account and added a rule to the firewall to reject packets from that IP address.

 

Below you can see most of the accounts were tried 19 times except spam which was tried 10 times.

--------------------- Dovecot Begin ------------------------  

Dovecot disconnects:

Logged out: 299 Time(s)

no reason: 2 Time(s)

 

**Unmatched Entries**

dovecot: pop3-login: Aborted login (1 authentication attempts): user=<adm>, method=PLAIN,

rip=200.73.3.50, lip=192.168.4.200: 19 Time(s)

dovecot: pop3-login: Aborted login (1 authentication attempts): user=<admin>,

method=PLAIN, rip=200.73.3.50, lip=192.168.4.200: 19 Time(s)

dovecot: pop3-login: Aborted login (1 authentication attempts): user=<guest>,

method=PLAIN, rip=200.73.3.50, lip=192.168.4.200: 19 Time(s)

dovecot: pop3-login: Aborted login (1 authentication attempts): user=<notice>,

method=PLAIN, rip=200.73.3.50, lip=192.168.4.200: 19 Time(s)

dovecot: pop3-login: Aborted login (1 authentication attempts): user=<office>,

method=PLAIN, rip=200.73.3.50, lip=192.168.4.200: 19 Time(s)

dovecot: pop3-login: Aborted login (1 authentication attempts): user=<qwerty>,

method=PLAIN, rip=200.73.3.50, lip=192.168.4.200: 19 Time(s)

dovecot: pop3-login: Aborted login (1 authentication attempts): user=<spam>,

method=PLAIN, rip=200.73.3.50, lip=192.168.4.200: 10 Time(s)

dovecot: pop3-login: Aborted login (1 authentication attempts): user=<support>,

method=PLAIN, rip=200.73.3.50, lip=192.168.4.200: 19 Time(s)

dovecot: pop3-login: Aborted login (1 authentication attempts): user=<temp>,

method=PLAIN, rip=200.73.3.50, lip=192.168.4.200: 19 Time(s)

dovecot: pop3-login: Aborted login (1 authentication attempts): user=<test>,

method=PLAIN, rip=200.73.3.50, lip=192.168.4.200: 19 Time(s)

dovecot: pop3-login: Aborted login (1 authentication attempts): user=<users>,

method=PLAIN, rip=200.73.3.50, lip=192.168.4.200: 19 Time(s)

dovecot: pop3-login: Aborted login (1 authentication attempts): user=<webmaster>,

method=PLAIN, rip=200.73.3.50, lip=192.168.4.200: 19 Time(s)

dovecot: pop3-login: Aborted login (1 authentication attempts): user=<website>,

method=PLAIN, rip=200.73.3.50, lip=192.168.4.200: 38 Time(s)

 

---------------------- Dovecot End -------------------------

 

I only have an A+ and a N+, this is starting to get a bit much for me. Any help would be appreciated.

[Dungeon-Dave]

You're doing the right thing with checking. One of my machines was cracked via a "default account" left unsecured - totally my fault, but I've taken steps to prevent it from occuring again.

 

Check /etc/passwd, look for all the accounts that have valid shells, and investigate those. Use the last command to check last logins for these people - be suspicious of the output from last being truncated, as this is often an indication of a cracker trying to cover their tracks.

 

Look at disabling the root account from logging in. Disable the TELNET service, and also lock out root from SSH access by editing /etc/ssh/sshd_config (you'll need to restart sshd to pick up those changes).

 

Also look at configuring logwatch to email you daily with this info, then you can see evidence of attempted intrusion attempts. To prevent them on mine, I've changed my sshd_config and bound it to a higher port, then left something running on port 22 to waylay sniffers and crackers. Just moving the SSH port alone reduced my security logs filling up - it doesn't totally secure you, but moves you out of the common "blast radius".

 

Look also at utilities like tripwire and snort to detect unauthorised changes and intrusion attempts, if you're really paranoid. Tripwire can be a bit arduous to configure - I'm still in the process of working it all fully out - but there's a lot of guides around there.

 

Lastly, the only accounts that are likely to barf your mail server are postfix or sendmail service accounts themselves (I'm guessing) and maybe a service account for dovecot or whatever IMAP server you're using. If you stop an account from running and there's complaints, then you know it's doing something important. If you get it in the neck for doing so, you've got an easy defence: if it isn't documented anywhere, then it can't be important.

 

If you get stick for fiddling and told to leave well alone, then feel free to drop support for that box onto the powers that be. One of the WORSE situations for anyone to be in is being expected to support and maintain a box that has no documentation or agreed control policy. It's not a Linux thing, it's a business thing - and the business MUST support you in properly integrating the box into the network to provide business functions, or remove it from the network since nobody properly knows what it does nor knows how it does it. Don't find yourself trapped by those that demand it's your responsibility to make it work being those that being prevented from taking proactive action in the first place. It's a bad position to be in, and a lose-lose situation.

[Jab]

Thanks, I changed the listening port for SSH last week after I read your post. I also disabled ssh from starting up as a service. From now on I'm just going to start the SSH service from webmin when I need it and shut it down when I'm done. The number of attacks on the server has decreased to one (NOOP) since I done that. I haven't changed any of the default passwords yet but i've temporarily disabled login on some of them. So far nothing bad has happened.

[Dungeon-Dave]

It shouldn't be much of an issue having SSH permanently running (just concealed on a higher port). If it were me, I'd probably do it the other way around - keep SSH on and enable webmin only when needed.

 

If you DO use webmin regularly, look at perhaps moving webmin to a different port number out of the way of webmin-sniffers (/etc/webmin/miniserv.conf or so). You may want to compare the number of vulnerabilities in webmin versus sshd.

 

Either way, could also look at using IPtables to lock both services to permitted IP ranges only - don't forget to add in some other servers you use on static IPs in case you lock yourself out from a new IP range. There are forum threads with IPtables stuff, but I can post some rules if you get stuck.

 

Good luck!

[Jab]

Thanks once again for the excellent advice. My Webmin isn't running on port 10000. I have however limited it's access to certain IP addresses and two other outside networks which I occasionally connect from with a dynamic IP. One thing I especially like about our replies is that you mention the names of the config files. I intend to be able to do almost everything by manually editing the config files with in the next two years.

[Dungeon-Dave]

I intend to be able to do almost everything by manually editing the config files with in the next two years.

It's how I learned. Long-term and sometimes complicated, but TAKE NOTES AS YOU GO and USE GOOGLE! Those two steps alone saved my sanity on many an occasion.

 

You'll find *most* config files live in /etc and if they're not a simple file (/etc/logwatch.conf) then it'll be a directory containing several files (/etc/logwatch.d/....), many of which end in .conf for the important ones. Many of them are pretty much guessible.

 

In the case of webmin, I saw the directory then just ran grep '1000' * just to see which files mentioned "1000" (would catch 10000 and 10001) and saw which file - and line - mentioned that port.

 

Good luck! And don't forget to make copies (/etc/webmin/miniserv.conf.older-but-working) so you can bail out in the event of a bad change.

 

nb: one last point to help: although many of the configs are in /etc, sometimes they can be scattered elsewhere. Use "rpm -ql" on a package to list the files (eg: rpm -ql webmin | more) as part of that package, and you may find /usr/lib/server.conf or /opt/application/conf/service.conf cropping up somewhere (they are normally linked to /etc, but not always).

 

And if you want a list of the packages installed? rpm -qa