Greetings, everybody
I've browsed around a bit, but there seems to be no single practical list of this kind.
What would you do to make a new Centos server which must run apache, IMAP (Dovecot) and SMTP (PostFix) and nothing else for a few domains as secure from attacks as possible, using only standard RPM packages as much as possible?
(Please note that choice of other IMAP and SMTP servers is not possible in my case, for a lot of reasons really not pertinent on the list, so let's not go there, please)
Here's a first absolutely uncomplete draft off the top of my head:
- remove as many unnecessary packages as possible (best way to find them?)
- install dovecot (not included in centos, IIRC) and other extra packages you do need
- run yum update
- enable long passwords
- set up only ssh2 on a non standard port
- set up Single Packet Authorization?
- set up itables (what would the safest iptables script to do all and only the services listed above?
- what else?
Feel free to rearrange, cut, add, give links, whatever: personally, I'm interested in securing the whole box, meaning how to glue things together in the safest possible way, without forgetting anything, while things like how to make Postfix not an open relay, for example, are already covered in detail in the Postfix docs.
TIA, Marco
On 7/20/07, M. Fioretti mfioretti@mclink.it wrote:
Greetings, everybody
I've browsed around a bit, but there seems to be no single practical list of this kind.
My first point is going over the long list http://iase.disa.mil/stigs/stig/unix-stig-v5r1.pdf and figuring out what meets the local environment.
What would you do to make a new Centos server which must run apache, IMAP (Dovecot) and SMTP (PostFix) and nothing else for a few domains as secure from attacks as possible, using only standard RPM packages as much as possible?
(Please note that choice of other IMAP and SMTP servers is not possible in my case, for a lot of reasons really not pertinent on the list, so let's not go there, please)
Here's a first absolutely uncomplete draft off the top of my head:
remove as many unnecessary packages as possible (best way to find them?)
install dovecot (not included in centos, IIRC) and other extra packages you do need
run yum update
enable long passwords
set up only ssh2 on a non standard port
Depending on the environment, I have found that this is not a useful tool. The problems I have encountered is that it just turns off some of the attacks. But if the target is considered worthwhile it does nothing as a slow nmap will point out that SSH is running on another port.
The problems I have with security through obscurity is that too many people rely on it too much. [Oh I will put ssh on the telnet port as no one would explain that.. and that way I can use a 5 letter password.]
Other issues are that it can flag other security tools that might be used in an environment looking for non-standard traffic.
- set up Single Packet Authorization?
I do not know enough about this to answer, but its name does not imbue trust in me :). [E.G. I would believe more in a 3-5 packet approach. Query, ReverseQuery, Answer-To-RQuery, Authorization]
- set up itables (what would the safest iptables script to do all and only the services listed above?
I think that if security is essential, then one should know iptables first.. then use a script. Not knowing iptables and relying on a script usually ends up with lots of email to some firewall list about why I cant talk to my remote server anymore.
- what else?
Feel free to rearrange, cut, add, give links, whatever: personally, I'm interested in securing the whole box, meaning how to glue things together in the safest possible way, without forgetting anything, while things like how to make Postfix not an open relay, for example, are already covered in detail in the Postfix docs.
TIA, Marco -- The Family Guide to Digital Freedom: http://digifreedom.net _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Fri, Jul 20, 2007 15:12:34 PM -0600, Stephen John Smoogen (smooge@gmail.com) wrote:
My first point is going over the long list http://iase.disa.mil/stigs/stig/unix-stig-v5r1.pdf and figuring out what meets the local environment.
- set up only ssh2 on a non standard port
Depending on the environment, I have found that this is not a useful tool. The problems I have encountered is that it just turns off some of the attacks.
I agree, but I have noticed in the past, and read in several places, that it's not security through obscurity: its main usefulness would not as much extra security as saving a bit of bandwidth and server load from automated attacks with off the shelf scripts.
But if the target is considered worthwhile it does nothing as a slow nmap will point out that SSH is running on another port.
of course, but that's why I listed it together with SPA
[Oh I will put ssh on the telnet port as no one would explain that.. and that way I can use a 5 letter password.]
long passwords are another item on the list.
Other issues are that it can flag other security tools that might be used in an environment looking for non-standard traffic.
sorry, I am not sure I understand this. Care to elaborate?
I do not know enough about this to answer, but its name does not imbue trust in me :). [E.G. I would believe more in a 3-5 packet approach. Query, ReverseQuery, Answer-To-RQuery, Authorization]
Is this scheme documented anywhere?
- set up itables (what would the safest iptables script to do all and
only the services listed above?
I think that if security is essential, then one should know iptables first.. then use a script.
Me too, but it's a chicken-and-egg situation. iptables and ssl are among the worst documented areas of what a learning sysadmin should learn. I have NO trouble to study iptables, but doing it with a tutorial or man page on one side, and a working, _recent_ script (some of the most readable docs I've found are relatively old) would be much more efficient. Hence my request of sharing iptables commands working today.
Not knowing iptables and relying on a script usually ends up with lots of email to some firewall list about why I cant talk to my remote server anymore.
Of course, I wouldn't run such a script, or any new tool suggested in this discussion, before being sure to understand what each line and option does.
Any further feedback is welcome!
Marco
-- The Family Guide to Digital Freedom: http://digifreedom.net
For ssh I highly recommend disabling password login, use only key pairs, this will really help improve your security with SSH, another thing you can do is monitor SSH logs, you will find that at times there will be someone trying to loging using a dictionary of users, you can easily create a script that checks for failed logins, count them and ban the IP in your firewall with iptables, there is also some pre-made scripts for this too.
Generally only open ports for services that you really need to have exposed to the WAN (Internet).
On 7/21/07, M. Fioretti mfioretti@mclink.it wrote:
On Fri, Jul 20, 2007 15:12:34 PM -0600, Stephen John Smoogen (smooge@gmail.com) wrote:
My first point is going over the long list http://iase.disa.mil/stigs/stig/unix-stig-v5r1.pdf and figuring out what meets the local environment.
- set up only ssh2 on a non standard port
Depending on the environment, I have found that this is not a useful tool. The problems I have encountered is that it just turns off some of the attacks.
I agree, but I have noticed in the past, and read in several places, that it's not security through obscurity: its main usefulness would not as much extra security as saving a bit of bandwidth and server load from automated attacks with off the shelf scripts.
But if the target is considered worthwhile it does nothing as a slow nmap will point out that SSH is running on another port.
of course, but that's why I listed it together with SPA
[Oh I will put ssh on the telnet port as no one would explain that.. and that way I can use a 5 letter password.]
long passwords are another item on the list.
Other issues are that it can flag other security tools that might be used in an environment looking for non-standard traffic.
sorry, I am not sure I understand this. Care to elaborate?
I do not know enough about this to answer, but its name does not imbue trust in me :). [E.G. I would believe more in a 3-5 packet approach. Query, ReverseQuery, Answer-To-RQuery, Authorization]
Is this scheme documented anywhere?
- set up itables (what would the safest iptables script to do all and
only the services listed above?
I think that if security is essential, then one should know iptables first.. then use a script.
Me too, but it's a chicken-and-egg situation. iptables and ssl are among the worst documented areas of what a learning sysadmin should learn. I have NO trouble to study iptables, but doing it with a tutorial or man page on one side, and a working, _recent_ script (some of the most readable docs I've found are relatively old) would be much more efficient. Hence my request of sharing iptables commands working today.
Not knowing iptables and relying on a script usually ends up with lots of email to some firewall list about why I cant talk to my remote server anymore.
Of course, I wouldn't run such a script, or any new tool suggested in this discussion, before being sure to understand what each line and option does.
Any further feedback is welcome!
Marco-- The Family Guide to Digital Freedom: http://digifreedom.net _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 7/21/07, M. Fioretti mfioretti@mclink.it wrote:
On Fri, Jul 20, 2007 15:12:34 PM -0600, Stephen John Smoogen (smooge@gmail.com) wrote:
My first point is going over the long list http://iase.disa.mil/stigs/stig/unix-stig-v5r1.pdf and figuring out what meets the local environment.
- set up only ssh2 on a non standard port
Depending on the environment, I have found that this is not a useful tool. The problems I have encountered is that it just turns off some of the attacks.
I agree, but I have noticed in the past, and read in several places, that it's not security through obscurity: its main usefulness would not as much extra security as saving a bit of bandwidth and server load from automated attacks with off the shelf scripts.
denyhosts or fail2ban also can help that. THe main issues I had was that I had automated scans against SSH on other ports. Not as many as I did with SSH on 22... but they do show up... the attacks seem to be based on the principle that a lot of backdoors are hacked ssh servers running at a high port with usually a poor password. So some hack-teams are just looking for existing backdoors and pounding away at them until they figure out which 'default' backdoor it is.
But if the target is considered worthwhile it does nothing as a slow nmap will point out that SSH is running on another port.
of course, but that's why I listed it together with SPA
[Oh I will put ssh on the telnet port as no one would explain that.. and that way I can use a 5 letter password.]
long passwords are another item on the list.
Other issues are that it can flag other security tools that might be used in an environment looking for non-standard traffic.
sorry, I am not sure I understand this. Care to elaborate?
At several places I have worked, our snort/etc servers would look for SSH on high ports due to the backdoor problem listed above. A lot of the intrustion prevention tools will auto-block that as bad traffic also. We spent a couple of days dealing with a client who kept saying SSH wasnt working.. and it was due to his providers IPS blocking stuff at 22122 as SSH was only to occur at 22.
I do not know enough about this to answer, but its name does not imbue trust in me :). [E.G. I would believe more in a 3-5 packet approach. Query, ReverseQuery, Answer-To-RQuery, Authorization]
Is this scheme documented anywhere?
- set up itables (what would the safest iptables script to do all and
only the services listed above?
I think that if security is essential, then one should know iptables first.. then use a script.
Me too, but it's a chicken-and-egg situation. iptables and ssl are among the worst documented areas of what a learning sysadmin should learn. I have NO trouble to study iptables, but doing it with a tutorial or man page on one side, and a working, _recent_ script (some of the most readable docs I've found are relatively old) would be much more efficient. Hence my request of sharing iptables commands working today.
Not knowing iptables and relying on a script usually ends up with lots of email to some firewall list about why I cant talk to my remote server anymore.
Of course, I wouldn't run such a script, or any new tool suggested in this discussion, before being sure to understand what each line and option does.
Any further feedback is welcome!
Will try to send some iptables stuff later this week.
On Sun, Jul 22, 2007 23:45:38 PM -0600, Stephen John Smoogen (smooge@gmail.com) wrote:
- set up only ssh2 on a non standard port
I agree, but I have noticed in the past, and read in several places, that it's not security through obscurity: its main usefulness would not as much extra security as saving a bit of bandwidth and server load from automated attacks with off the shelf scripts.
denyhosts or fail2ban also can help that.
OK, I'll study their documentation and come back if I have specific questions on these tools. Related tips, tricks and comments are very welcome anyway, of course.
Not knowing iptables and relying on a script usually ends up with lots of email to some firewall list about why I cant talk to my remote server anymore.
Of course, I wouldn't run such a script, or any new tool suggested in this discussion, before being sure to understand what each line and option does.
Any further feedback is welcome!
Will try to send some iptables stuff later this week.
I really appreciate that! Thanks Steven!
Marco
--On Saturday, July 21, 2007 9:22 AM +0200 "M. Fioretti" mfioretti@mclink.it wrote:
- set up only ssh2 on a non standard port
Depending on the environment, I have found that this is not a useful tool. The problems I have encountered is that it just turns off some of the attacks.
I agree, but I have noticed in the past, and read in several places, that it's not security through obscurity: its main usefulness would not as much extra security as saving a bit of bandwidth and server load from automated attacks with off the shelf scripts.
There's some automated attack that fills one's logs with noise, and it's useful to move ssh to a non-standard port simply to quiet the logs, so that "real" attacks will stand out. For port 22, one can either use iptables to drop the connection attempts, or use tcpwrappers and set up a dummy script or even a honeypot to trap the script kiddies.
M. Fioretti wrote:
- install dovecot (not included in centos, IIRC) and other extra packages you do need
dovecot is included in CentOS - so no need to get it from somewhere else.
- set up itables (what would the safest iptables script to do all and only the services listed above?
Depends on from where you want to connect to your imap server. From everywhere? And ssh? The same?
If you only run sshd, imap, postfix and apache I don't really see a need for iptables. But you might want to restrict access to sshd to a few ip addresses if you can.
- what else?
Don't turn off SELinux.
Cheers,
Ralph
On Sat, Jul 21, 2007 10:33:14 AM +0200, Ralph Angenendt (ra+centos@br-online.de) wrote:
- set up itables (what would the safest iptables script to do all and only the services listed above?
Depends on from where you want to connect to your imap server. From everywhere?
yes. More exactly, dovecot must serve both local webmail via squirrelmail and my (and other users) home boxes
If you only run sshd, imap, postfix and apache I don't really see a need for iptables. But you might want to restrict access to sshd to a few ip addresses if you can.
Unfortunately, this is not an option. Sorry I forgot to specify it in the initial message.
- what else?
Don't turn off SELinux.
Hmmm... I had also forgotten this side of the package. I will be running on a rented VPS, can SELinux be used in such contexts?
Also, frankly I am not up to date on this, but I do remember reading a lot of "Just turn off selinux, isn't worth it" and "selinux isn't mature/ documented enough yet" in relatively recent times, both on Fedora and Centos lists.
Is this still the case?
Thanks! Marco
M. Fioretti wrote:
On Sat, Jul 21, 2007 10:33:14 AM +0200, Ralph Angenendt (ra+centos@br-online.de) wrote:
- set up itables (what would the safest iptables script to do all and only the services listed above?
Depends on from where you want to connect to your imap server. From everywhere?
yes. More exactly, dovecot must serve both local webmail via squirrelmail and my (and other users) home boxes
If you only run sshd, imap, postfix and apache I don't really see a need for iptables. But you might want to restrict access to sshd to a few ip addresses if you can.
Unfortunately, this is not an option. Sorry I forgot to specify it in the initial message.
- what else?
Don't turn off SELinux.
Hmmm... I had also forgotten this side of the package. I will be running on a rented VPS, can SELinux be used in such contexts?
Also, frankly I am not up to date on this, but I do remember reading a lot of "Just turn off selinux, isn't worth it" and "selinux isn't mature/ documented enough yet" in relatively recent times, both on Fedora and Centos lists.
Is this still the case?
It was never the case ... SELinux has been turned on by default by Red Hat in RHEL4 and RHEL5.
People who say "turn it off" do so because the either don't understand what it does OR they don't know how to use it.
That said, you don't HAVE to use it. However, it is another layered security feature AND the largest enterprise linux outfit in the world thinks it is very important.
On Sat, Jul 21, 2007 12:19:23 PM -0500, Johnny Hughes (johnny@centos.org) wrote:
Don't turn off SELinux.
Hmmm... I had also forgotten this side of the package. I will be running on a rented VPS, can SELinux be used in such contexts?
Also, frankly I am not up to date on this, but I do remember reading a lot of "Just turn off selinux, isn't worth it" and "selinux isn't mature/ documented enough yet" in relatively recent times, both on Fedora and Centos lists.
Is this still the case?
It was never the case ... SELinux has been turned on by default by Red Hat in RHEL4 and RHEL5.
Yes, but I do remember several threads on the confusion this caused, hence my comment
People who say "turn it off" do so because the either don't understand what it does OR they don't know how to use it.
Sure. This could be due to the feature not being sufficiently documented (see my earlier comments in the thread on ssl, for example), something that in practice would still make it hardly usable for all but the most competent, full-time sysadmins. Regardless of how well it's working or is packaged in any distro.
'night, Marco
M. Fioretti wrote:
People who say "turn it off" do so because the either don't understand what it does OR they don't know how to use it.
Sure. This could be due to the feature not being sufficiently documented (see my earlier comments in the thread on ssl, for example), something that in practice would still make it hardly usable for all but the most competent, full-time sysadmins. Regardless of how well it's working or is packaged in any distro.
If you're staying with software supplied by CentOS and use the standard paths for apache, postfix, squirrelmail and so on, you probably won't be able to tell that SELinux is turned on.
As soon as you're beginning to add software from somewhere else, things can get funny. But even for those solution aren't that far away :)
Cheers,
Ralph
Feel free to rearrange, cut, add, give links, whatever: personally, I'm interested in securing the whole box, meaning how to glue things together in the safest possible way, without forgetting anything, while things like how to make Postfix not an open relay, for example, are already covered in detail in the Postfix docs.
I have found that the checklist/scripts/documents at http://www.cisecurity.org/ are a pretty good starting point.
Craig ======================================================================= Attention: The information contained in this message and/or attachments from AgResearch Limited is intended only for the persons or entities to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipients is prohibited by AgResearch Limited. If you have received this message in error, please notify the sender immediately. =======================================================================
-
Carlos Daniel Ruvalcaba Valenzuela -
Johnny Hughes -
Kenneth Porter -
M. Fioretti -
Miskell, Craig -
Ralph Angenendt -
Stephen John Smoogen