Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I've built my own mail server using Debian 5.0. So far I have not had any security issues, but I would like some advice on how I can be sure I can secure my server. I've been getting brute force attempts, but so far nothing has penetrated my current defenses.
For SSH I have changed the listening port, disabled root login, given my account sudoer privileges and a pretty strong password (but not ridiculously strong, a mix of upper and lowercase, numbers and symbols, 9 chars long). For other user accounts that I have created, I have disabled shell access (usr/bin/nologin) and insisted on at least letters, numbers and symbols. For my honeypot account (where all non-personal and system mails go) I have some crazy 48-bit hex password that I only have in a password database. I've left file permissions largely the way they are, but I set up all log files to be readable by all, since having to sudo to read logs kind of sucks...
For mail processes I have Postfix, Dovecot, and saslauthd. I use SSL connection encryption, username + plain password authentication on both IMAP and SMTP connections. No anonymous SMTP connections are allowed. Amavisd scans for viruses, Spamassassin scans for spam. Maildrop puts it in the right folder.
I also run Apache which runs a minimal website/webmail client on one domain and a forum on another. Both the forum (PHPBB3) and webmail client (RoundCube Mail) connect to the same MySQL server, which only listens to localhost TCP connections. Both MySQL users only have access to their respective databases, and have ridiculous-strength passwords.
I also have fail2ban installed, which tracks failed login attempts and bans IPs for 10 minutes if they fail 5 times, and bans them again for a week if they get banned 5 times in a row.
Should I take any other precautions? Should I go through all system accounts and disable shell access? If so, which ones, and will I break the system if I modify the wrong one?
Should I set up iptables to actively block not-in-use ports? As far as I can tell, there are no other open ports other than my SSH port, IMAP, SMTP, HTTP and HTTPS.
I was thinking about setting my SSH up to only accept logins using keys, but I kind of like the username-password only flexibility. Should I forego the flexibility and set up private keys?
It sounds to me like you have done a pretty good job! There are a few more things that I can think of, off the top of my head, for you to start look into which I think start to go beyond these basics.
First, lets address your questions. 1 - Should you use a firewall to close the ports? By default, in Linux, ports are closed unless a service is listening on them. Using iptables to close the ports is a good precaution, in that it will prevent a port and service from becoming opened unintentionally. 2 - Should you use key based authentication? Key based authentication is superior to passwords and will effectively eliminate brute force attempts to gain SSH access. As long as your password is good and you are using an uncommon user name and you are actively responding with fail2ban you will probably avoid troubles. This one is a matter of convenience versus additional security.
Now, some additional suggestions:
1 - learning to use iptables will provide you with some more advanced techniques should you need them in the future, such as rate limiting and region blocking. If you haven't yet, be sure to spend some time learning this tool. Doing so will also increase your understanding of TCP/IP connections and states.
2 - Use a HIDS on your system such as Aide, Samhain, or Ossec, which will alert you to changes in your system.
3 - Use packet monitoring software, such as Snort to analyze the traffic getting past your physical firewall. If you don't have a firewall in front, this can be noisy and will generate a lot of false positives.
4 - Add mod_security to your Apache.
5 - In iptables or other firewall, log the connections that get dropped and periodically review this.
6 - Set up a tool like logwatch to give you daily summaries of your log entries.
7 - Run a root kit detection program and get daily reports. Investigate any anomalies.
8 - Run a mail watch program that will give you a summary of what is happening with your mail server, especially regarding failed attempts, blocked spam, and server malfunctions.
9 - You have done well with your MySQL on a local only port. If you use any web based application, such as MyAdmin, or Postfix Admin, keep these applications on a local port and / or use client certificates to gain access to them.
10 - Be sure you keep your system up to date, though I suspect given everything else you do that this isn't an issue for you.
Lastly, there is a large security references section in this forum as a sticky thread. You will undoubtedly find lots of information there.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.