How can I make my server as secure as possible
 

Having suffered a very sever spammer attack I have decided to setup a new server and transfer all the web sites.
I would appreciate any help and advice on how to make my server as secure as possible.

What I have done up to now is:

1. Blocked ‘root login’.
2. Limited SSH login to specific ip numbers via iptables.
3. Installed OSSEC
4. Installed RKHUNTER.

I am now looking for advice on what to do next.
I have in mind to stop all processes that I don’t need.
I must admit that when I run ‘ps ax’ I don’t know what most of the processes are.
This is what I do need:

1. I run web sites.
2. I run mysql
3. I run php
4. I run perl
5. I run sendmail as my MTA
6. I run dovecot and imap for pop3
7. I tried to run spamassassin but I couldn’t get the upgrade to work.
8. I run Webmin
9. I run vsftpd

If any body has any suggestions I would love to hear them.

Thanks,

Couple of ideas to google?
SSH - disable keyboard interactive logins(public/private keys), change port number, port knocking, DenyHosts, pam_abl

What kind of budget are you working with? Are proprietary products out of the question? What is your projected userbase and how much traffic will the servers see? Do you have any performance requirements you must meet? Is this corporate or are you running a blog about cheese sandwiches? I ask these questions because depending on what you're doing will depend on how you should set up your servers. I'll assume it's corporate for my response here.

Read this.

Stop running php. That's the biggest security hole in your system with almost 20,000 security vulnerability bulletins about it. If you insist on running something with the security of Swiss cheese then be sure to chroot jail apache. Static pages or other technologies are better from a security perspective (Java, ASP, Perl, Django, etc). VHosts are better than just straight up Apache.

For every web interface that must be accessed from the world do not directly expose the server to the internet. Allow the internet to access the server through a proxy server. I usually set up a server with an Apache proxy pass that all the traffic goes through and then gets split up to different internal services.

System monitoring using Icinga with escalations and alerts, use passive checks for the most security. Passive checks can be achieved with simple perl/python, Nagios Plugins, and nsca on the client systems. System statistics using PNP4Nagios (runs integrated with Icinga) or using munin (can run standalone). Whenever you look up Nagios plugins for Icinga, Icinga is equivalent to Nagios 3.x.

Enable SELinux. That is a great security tool. Use a root account with more than 15 character password that's randomly generated and save that password in a KeyPass keystore. Then only access root account using /etc/sudoers that way commands are logged and you get more advantageous security with SELinux. Restrict ssh logins to a wheel group, and create a separate group for sudoers.

You should use RedHat for the OS and if that's out of your price range then go with CentOS.

Separate your services on to separate servers. Use something like VMWare ESX or use the free VMWare vSphere. Then use an auto install system like Cobbler which uses kickstart, PXE, and other scripts to make creating new servers for more systems very simple. For IO performance purposes you should have your database on a standalone dedicated (non-VM) machine.

Centralize your logs using syslog and syslog-ng. Create log filtering using perl filtering out regular entries and only alerting you of non-normal log entries. At my place of work we have an hourly email of non-regular log entries from the centralized log server. The way we format the emails makes it very easy to write a script which can filter through an entire mbox format of emails and display only servers of interest if something specific needs to be looked at.

I can recommend security all day but I'll wait for a response from you so I'm not writing a book here. It is best to know what you are capable of and what your budget for this security is before I recommend any more. Security is a living breathing animal so either you or a dedicated sysadmin should be monitoring it on a regular basis throughout the day.

Somewhat in contrast to sag47's posting ... but without disagreeing categorically with anything (s)he said in it ... I suggest that you should start by considering how someone could intrude into your system, or use some software that is already running there to cause mischief, and focus your attentions there.

Start with the old stock-market admonition: "Know what you own, and know why you own it." Inventory every application that is running on your system or that could possibly be started through xinetd. Eliminate every one that you do not require. Learn what everything that remains does (and if you don't know yet, take no action until you positively do.)

Now, look for "convenient features" that were "helpfully" left behind by, say, your ISP. phpmyadmin, for example, or any sort of “administrative console” they might have dreamed up.

Lock down ssh such that the only way to connect to the system is by means of digital certificates. Be aware that this tool will start with the most-secure method of authentication but will then offer successively weaker and weaker(!) alternatives. "Always trying to please," I suppose. Stop it short of passwords. Obviously exclude "root." (Firewalls are not equivalent, since IP-addresses can be faked!)

Make certain that all of your daemon processes demote themselves to a less-powerful userid such as nobody. Or, allocate separate (non-privileged) userids for each process and cause each of them to demote to that particular userid.

Beyond this, you are now getting into the realm of subsystem-specific configuration changes. For example, if you were "hit by a spammer," this person might simply have caused your inbound and outbound mail-service processes to do what they ordinarily are designed to do! First of all, do you have an actual business need at all to run your own mail server? (I mean, "really... do you??") If so, are there rules that you can think of which define what you want your mail server to do or to not-do? If this is a "corporate" mail server such that only "insiders" (i.e. "within this range of IP-addresses ...") should be able to send mail from here, firewall everything else out. (Hint: tools like "Shorewall" are worth their weight in gold since they avoid :banghead: dealing with iptables rule-writing directly...) Things like that.

Hi andywebsdale...
Many thanks for your advice.
I had already changed the port number. I just forgot to mention it.
I'm not sure about the disable keyboard interactive logins(public/private keys) suggestion.
As I don't fully understand it. I often need to login to my server from a remore location, so I don't think that this would allow me to do it.
I had a look at port knockin but I couldn't make 'head nor tail' of it.
I have now installed DenyHosts and pam_abl
Many thanks for your suggestions.

Hi sag47...
Many thanks for your contribution to securing my server.
WOW !!!
What a lot to take in and understand.
Yes. Proprietary products out of the question.
This is a corporate server, although I only have around 20 clients. These clients are mainly clients who I design and host web sites for. I also provide their email facilities.
I believe that an email address me@mydomain.com looks better that xyz@hotmail.com. and it helps to promote their web site.
I cannot drop PHP. It is the main basis for my web sites. I struggle with perl, although I did use in the first instance, and I just cannot get my head rough javacsript.
I use Centos 5. I can't afford RedHat since they started to charge for it.
I must admit. I turned off SELinux because I couldn't ftp into the server with it on.
I always intended to find out more about it but never did. I will do now though.
My capabilities are very limited and my budget is even more limited
The useage on my server is quite low, less that 50Gb per month, which includes all web sites.

However, you have given me lots to think about and ponder over and I am very very grateful for that.

THANK YOU

Without meaning to be (too) trite, the most secure box I have isn't connected to anything.
Not phone, not internet, not even power.

When I want to "play", it's secure - on batteries. Fsck all use to anyone else, but secure. Batteries get recharged when it's turned off.
It's had all sort of attacks - by me. But it's secure.

Bet that's not what you wanted to hear.

Hi sundialsvcs...

Many thanks for your advice.
This is one of the problems that I have.
I don't know what most of the running processes do, or if they are necessary.
Looking in /etc/sysconfig/xinetd: the only entry is XINETD_LANG="en_US" which I suppose is harmless.

These are some of the running processes that I have no idea what they are, or more importantly, if they are needed.
Will I be able to login remotely if this is the method used ???

Im going to take a closer look at this.
Meanwhile, my server is not Open Relay. Neither can clients send mail through my server, with odd exceptions when I list their ip number in /etc/mail/access and then it is only a temporart measure.

Many thanks to all who have contributed to this thread.
I now have a lot to work on

THANK YOU

NO...
Mine is a working server, although not very hard.

lol.

I bet my tax records are way more secure than anything you have ...

Here's a link for you:

CentOS Wiki - Securing SSH

What records ????

@all: please keep this thread on topic. For OT talk please see the /General forum, TIA.

Are we not allowed to have a bit of fun whilst conducting a serious topic???

If that is the case then I still recommend you split the services onto different machines. It will help isolate problems. Better to have only one or some of your services go down rather than all of them. BTW I probably should have asked this before but what are you doing for backups, if any? Security is all well and good until someone rm -rf / your whole filesystem as root user.

Well here let me try to help in that category so you don't have to spend all day reading SELinux docs. I was running a simple Apache ProxyPass server this past Thursday but it wouldn't work. Turns out it was because of SELinux. I'll give you the overall commands which I used to fix it. Then you can read up on them. Though I still recommend you read through all of SELinux to more thoroughly understand it. Remember that people are the weakest link in security and what you don't know can hurt you in the sysadmin world; even professionally.

Another command you should know and look up is restorecon and ls -Z.

Well even considering your capabilities after SELinux I would prioritize setting up an Icinga server with PNP4Nagios. Then start the other stuff at your leisure. You're basically flying by the seat of your pants if you don't know what your servers are doing historically. You can see performance trends and it will even assist you in fixing problems you didn't even know you had.

Well in all likely hood they are located in /etc/init.d/. So learn about them.

Is just one way to start learning about them. Google is another such as "centos 5 acpid what is it?" or "what is acpid centos5". You can even look up tutorials on minimal services (note I have not tested the legitimacy of this article nor it's validity). You should really make an effort to read the man pages and learn more about rpm and yum; such as what options you have available to you. Trust me, as you do things more thorough like this you'll get used to the tools of your trade.

All the commands I have outlined I have run on RedHat 5 and 6. It should properly translate to CentOS.

SAM