Re: [gentoo-user] Testing how secure a server is...
Joseph wrote: I have port knocking installed on firewall, to further protect any SSH attacks. So port 22 is closed (in stealth mode) and only opens if it received the right knock sequence, moreover it is only opened to an IP address from which received successful knock sequence; all others see this port as closed (in stealth mode). Hm, never heard of it... How can this methot be installed and used with gentoo/iptables? Any more info about it? Jarry -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Testing how secure a server is...
This document should give you some info http://gentoo-wiki.com/HOWTO_Port_Knocking Peter On 8/4/05, Jarry [EMAIL PROTECTED] wrote: Joseph wrote: I have port knocking installed on firewall, to further protect any SSH attacks. So port 22 is closed (in stealth mode) and only opens if it received the right knock sequence, moreover it is only opened to an IP address from which received successful knock sequence; all others see this port as closed (in stealth mode).Hm, never heard of it...How can this methot be installed and used with gentoo/iptables?Any more info about it? Jarry--gentoo-user@gentoo.org mailing list-- I have plenty of common sense, I just choose to ignore it. --- Calvin
Re: [gentoo-user] Testing how secure a server is...
Colin wrote: On Aug 2, 2005, at 7:50 PM, Raphael Melo de Oliveira Bastos Sales wrote: Hi there, I was wondering what tools should I use to detect security flaws to my server and a few tips on how to use them. What are the most common forms of attack and how do I avoid being attacked by one of them? The services avaliable are only Apache - SSL and SSH. I've installed an firewall, iptables and firestarter to control it, and blocked all ports except 443 and 8080, where the SSH is listening. Apache has PHP installed as a module. Want to know how secure your server is? Try and hack it! a better place to start would be a simple inventory of what you are running, its version, configuration and what you want to run. If there's a delta, justify or fix. no need to do any sort of Port scanning or penetration testing 80% of the time. a simple inventory most of your security questions right off the bat. Of course it's not as sexy or ego inflating as running penetration tools but it gives you one thing the others don't. And audit trail. Something you can show to your lawyers and insurance people that you practiced due diligence in knowing your system vulnerabilities. if you are running Apache however you do need to run some form of attack because it is trivially easy to write an Apache configuration which leaves you butt naked to the world and not know it until you've been had. there are similarly complex services (i.e. Samba) that leave you easily vulnerable. so my advice would be to use more secure and easily secured alternatives whenever possible. A good port scanner like nmap should be a basic check of your firewall. I would also set nmap (if it can do this) to perform a SYN flood as it scans, to see if your server can withstand that basic DoS attack. (Adding --syn to your TCP rules in iptables can prevent SYN flooding when used with SYN cookies.) When you break in, find out why it worked and how it can be patched. Some things I would advise (I'm currently working on a server at the moment as well): - If the server is really important (or if you're paranoid), use the hardened-sources with PIE/SSP to prevent badly-written programs from arbitrarily executing code. you should run this no matter what. There is no excuse to leaving yourself vulnerable to these kinds of attacks if there is a method of catching them. Security is not just a single layer. It's multiple layers of good coding, language used, and operating system provided barriers. Since developers insist on using languages like C, C++ providing features behind most security problems, you really need PIE/SSP in place for when the inevitable mistake happens. - Enable SYN flood protection. There's a kernel option somewhere about IPv4 SYN cookies, enable that, and couple it with --syn attached to your TCP rules in iptables. It's a very popular denial- of-service attack. again, never run without it. That way you don't need to do any testing because the problem is handled. - Whenever you need to login or authenticate yourself, make the system delay five seconds after a bad password is entered. This will make a brute-force attack much much slower (0.2 passwords/sec as opposed to millions passwords/sec without a delay, depending on your server's speed). again should be built-in to system services. Why do it yourself and risk error? - Make sure iptables is set to deny all traffic that isn't explicitly allowed. apparently good statement but let's look at the implications. if the services aren't on and there is nothing listening on the port, this isn't really necessary. if the services are on but not needed, see recommendation above about turning them off. if services are needed on one interface but not the other, bind to the right interface. It would make sense to use a deny rule in case something goes wrong. if you are providing services to the net at large, deny rules are not practical. If you're providing services to a limited number of people on the net at large, you need to worry more about authentication and communications confidentiality. If you are providing services internally, may be practical in some cases, but more likely to bite you in the butt when things change on the internal network. that's all the cases I can think of, any others? - Read through your logs every now and then. I highly advise having the server burn them to a CD/floppy every now and then for an instant backup. Get a log reader/parser, too. very good advice. I personally like the idea of storing logs on another machine. But a log reader/parser to bring out the highlights. Also be prepared to spend hours every day verifying each log quirk. Whenever possible, try to eliminate noise from the logs so you can pull out the real information necessary to detect problems. Naturally, hide the server in the attic or basement. Chain it to
Re: [gentoo-user] Testing how secure a server is...
Raphael Melo de Oliveira Bastos Sales wrote: He claims that if someone invades my machine, it will have direct access to all data. That I have to distribute the database, put it in another machine and have the web application access that database over the network. I feel this is a bit overkill. Not only it would force the data travel through the network, slowing it down, but would also increase the complexity of the security layout, forcing to make the two machines very secure, unstead of just one of them. Besides, I might be wrong, but I feel that a Local Socket is faster and safer than Corba trasmitting data over the internal network. If anybody has any comments, I'd be more than happy to hear it. first, on the issue of distributing, yes, you will have a nominally more secure application. This assumes of course that the attacker cannot take any part of your application and use it against you by accessing the database themselves. the interesting paradox is that by moving your application to another machine and using a network between them for communicating data, the application usually runs faster. Think carefully about the RPC mechanism. Don't try to reinvent the wheel with your own socket connection because you will spend a lot of time getting it right and validating it when you could be doing other things that are more fun, productive, and impressing your boss with your lack of not invented here attitude. corba is complex to get started but it is one of the faster RPC mechanisms available (if memory serves). XML RPC is trivially easy to use but is much slower because of XML. Sun RPC. Well, it's a gray beard. Try not to use it. On the security profile, don't sweat it. The best you can do is set out the local machine firewalls to deny access from each other except for the database connection. ssh should only be permitted from your green network. Everything else really depends on what you need exposed and where. connection security can be handled with SSL. Many database engines support this (if memory serves). ---eric -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Testing how secure a server is...
On Tue, 2005-08-02 at 23:50 +, Raphael Melo de Oliveira Bastos Sales wrote: Hi there, I was wondering what tools should I use to detect security flaws to my server and a few tips on how to use them. What are the most common forms of attack and how do I avoid being attacked by one of them? The services avaliable are only Apache - SSL and SSH. I've installed an firewall, iptables and firestarter to control it, and blocked all ports except 443 and 8080, where the SSH is listening. Apache has PHP installed as a module. Thanks for the attention, Raphael. I have port knocking installed on firewall, to further protect any SSH attacks. So port 22 is closed (in stealth mode) and only opens if it received the right knock sequence, moreover it is only opened to an IP address from which received successful knock sequence; all others see this port as closed (in stealth mode). -- #Joseph -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Testing how secure a server is...
Joseph could you direct me toward a how to on how to set that up, please. Raphael have you gone through http://www.gentoo.org/doc/en/security/index.xml it has some good points and worth going through and ticking off each one. Cheers Rav On 8/3/05, Joseph [EMAIL PROTECTED] wrote: On Tue, 2005-08-02 at 23:50 +, Raphael Melo de Oliveira Bastos Sales wrote: Hi there, I was wondering what tools should I use to detect security flaws to my server and a few tips on how to use them. What are the most common forms of attack and how do I avoid being attacked by one of them? The services avaliable are only Apache - SSL and SSH. I've installed an firewall, iptables and firestarter to control it, and blocked all ports except 443 and 8080, where the SSH is listening. Apache has PHP installed as a module. Thanks for the attention, Raphael. I have port knocking installed on firewall, to further protect any SSH attacks. So port 22 is closed (in stealth mode) and only opens if it received the right knock sequence, moreover it is only opened to an IP address from which received successful knock sequence; all others see this port as closed (in stealth mode). -- #Joseph -- gentoo-user@gentoo.org mailing list -- When you play a Microsoft CD backwards you can hear demonic Voices... that's nothing - when you play it forward it installs Windows Are you fearing my mouse? :3___) -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Testing how secure a server is...
On Wed, 2005-08-03 at 23:37 +0200, Ryan Viljoen wrote: Joseph could you direct me toward a how to on how to set that up, please. I use freesco firewall and they have small package (add-on) called knock, you can install it on a floppy see my howto: http://forums.freesco.org/support/index.php?showtopic=13731 but eventually I moved it to HD (as I had too much problems with 1.68Mb floppies) My intension was to use this setup to print to a remote printer location over SSH, and it works like a charm. The knock demon runs on firewall (that is the best setup) and listen for specific knock sequence. You can open any port this way. If you have a Gentoo based firewall, knock in in portage but your machine must more mussels to run Gentoo; and Freesco will run on any door-stopper starting from 486. -- #Joseph Raphael have you gone through http://www.gentoo.org/doc/en/security/index.xml it has some good points and worth going through and ticking off each one. Cheers Rav On 8/3/05, Joseph [EMAIL PROTECTED] wrote: On Tue, 2005-08-02 at 23:50 +, Raphael Melo de Oliveira Bastos Sales wrote: Hi there, I was wondering what tools should I use to detect security flaws to my server and a few tips on how to use them. What are the most common forms of attack and how do I avoid being attacked by one of them? The services avaliable are only Apache - SSL and SSH. I've installed an firewall, iptables and firestarter to control it, and blocked all ports except 443 and 8080, where the SSH is listening. Apache has PHP installed as a module. Thanks for the attention, Raphael. I have port knocking installed on firewall, to further protect any SSH attacks. So port 22 is closed (in stealth mode) and only opens if it received the right knock sequence, moreover it is only opened to an IP address from which received successful knock sequence; all others see this port as closed (in stealth mode). -- #Joseph -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Testing how secure a server is...
Hi, 2 tools nmap and nessus for network/port scanning and others. For hardering you could use bastille. Of course all found in portage. PeterOn 8/3/05, Raphael Melo de Oliveira Bastos Sales [EMAIL PROTECTED] wrote: Hi there, I was wondering what tools should I use to detect security flaws tomy server and a few tips on how to use them. What are the most commonforms of attack and how do I avoid being attacked by one of them? The services avaliable are only Apache - SSL and SSH. I'veinstalled an firewall, iptables and firestarter to control it, andblocked all ports except 443 and 8080, where the SSH is listening.Apache has PHP installed as a module. Thanks for the attention,Raphael.--gentoo-user@gentoo.org mailing list-- I have plenty of common sense, I just choose to ignore it. --- Calvin
Re: [gentoo-user] Testing how secure a server is...
On Aug 2, 2005, at 7:50 PM, Raphael Melo de Oliveira Bastos Sales wrote: Hi there, I was wondering what tools should I use to detect security flaws to my server and a few tips on how to use them. What are the most common forms of attack and how do I avoid being attacked by one of them? The services avaliable are only Apache - SSL and SSH. I've installed an firewall, iptables and firestarter to control it, and blocked all ports except 443 and 8080, where the SSH is listening. Apache has PHP installed as a module. Want to know how secure your server is? Try and hack it! A good port scanner like nmap should be a basic check of your firewall. I would also set nmap (if it can do this) to perform a SYN flood as it scans, to see if your server can withstand that basic DoS attack. (Adding --syn to your TCP rules in iptables can prevent SYN flooding when used with SYN cookies.) When you break in, find out why it worked and how it can be patched. Some things I would advise (I'm currently working on a server at the moment as well): - If the server is really important (or if you're paranoid), use the hardened-sources with PIE/SSP to prevent badly-written programs from arbitrarily executing code. - Enable SYN flood protection. There's a kernel option somewhere about IPv4 SYN cookies, enable that, and couple it with --syn attached to your TCP rules in iptables. It's a very popular denial- of-service attack. - Whenever you need to login or authenticate yourself, make the system delay five seconds after a bad password is entered. This will make a brute-force attack much much slower (0.2 passwords/sec as opposed to millions passwords/sec without a delay, depending on your server's speed). - Make sure iptables is set to deny all traffic that isn't explicitly allowed. - Turn off any services you don't need. - Read through your logs every now and then. I highly advise having the server burn them to a CD/floppy every now and then for an instant backup. Get a log reader/parser, too. Naturally, hide the server in the attic or basement. Chain it to something, or if it has a security slot, use a security cable. Put a lock on the case door. Unplug your floppy/CD drives if you're not using them. As of this writing, there is no kernel option to keep your computer or its innards from walking away. :-) -- Colin -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Testing how secure a server is...
Thanks Peter. I'm just finishing visiting the home page of almost every package on the net-analyzer category. If I didn't have such a short dead line, I'd test them all. ;) 2005/8/3, Peter De Zutter [EMAIL PROTECTED]: Hi, 2 tools nmap and nessus for network/port scanning and others. For hardering you could use bastille. Of course all found in portage. Peter On 8/3/05, Raphael Melo de Oliveira Bastos Sales [EMAIL PROTECTED] wrote: Hi there, I was wondering what tools should I use to detect security flaws to my server and a few tips on how to use them. What are the most common forms of attack and how do I avoid being attacked by one of them? The services avaliable are only Apache - SSL and SSH. I've installed an firewall, iptables and firestarter to control it, and blocked all ports except 443 and 8080, where the SSH is listening. Apache has PHP installed as a module. Thanks for the attention, Raphael. -- gentoo-user@gentoo.org mailing list -- I have plenty of common sense, I just choose to ignore it. --- Calvin -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Testing how secure a server is...
Hey Colin, I was looking at the /etc/ssh/sshd_config file and found these: LoginGraceTime 600 MaxAuthTries 6 Is the first one what you meant? The second seems like an attempt to avoid brute force login. Also, does Grub need any kind of password protection? I don't know if it was Grub or Lilo that allowed root access unless password protected. Am I mistaken? As you can see, I still have a lot to learn. ;) 2005/8/3, Colin [EMAIL PROTECTED]: On Aug 2, 2005, at 7:50 PM, Raphael Melo de Oliveira Bastos Sales wrote: Hi there, I was wondering what tools should I use to detect security flaws to my server and a few tips on how to use them. What are the most common forms of attack and how do I avoid being attacked by one of them? The services avaliable are only Apache - SSL and SSH. I've installed an firewall, iptables and firestarter to control it, and blocked all ports except 443 and 8080, where the SSH is listening. Apache has PHP installed as a module. Want to know how secure your server is? Try and hack it! A good port scanner like nmap should be a basic check of your firewall. I would also set nmap (if it can do this) to perform a SYN flood as it scans, to see if your server can withstand that basic DoS attack. (Adding --syn to your TCP rules in iptables can prevent SYN flooding when used with SYN cookies.) When you break in, find out why it worked and how it can be patched. Some things I would advise (I'm currently working on a server at the moment as well): - If the server is really important (or if you're paranoid), use the hardened-sources with PIE/SSP to prevent badly-written programs from arbitrarily executing code. - Enable SYN flood protection. There's a kernel option somewhere about IPv4 SYN cookies, enable that, and couple it with --syn attached to your TCP rules in iptables. It's a very popular denial- of-service attack. - Whenever you need to login or authenticate yourself, make the system delay five seconds after a bad password is entered. This will make a brute-force attack much much slower (0.2 passwords/sec as opposed to millions passwords/sec without a delay, depending on your server's speed). - Make sure iptables is set to deny all traffic that isn't explicitly allowed. - Turn off any services you don't need. - Read through your logs every now and then. I highly advise having the server burn them to a CD/floppy every now and then for an instant backup. Get a log reader/parser, too. Naturally, hide the server in the attic or basement. Chain it to something, or if it has a security slot, use a security cable. Put a lock on the case door. Unplug your floppy/CD drives if you're not using them. As of this writing, there is no kernel option to keep your computer or its innards from walking away. :-) -- Colin -- gentoo-user@gentoo.org mailing list -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Testing how secure a server is...
On Aug 2, 2005, at 9:18 PM, Raphael Melo de Oliveira Bastos Sales wrote: Hey Colin, I was looking at the /etc/ssh/sshd_config file and found these: LoginGraceTime 600 MaxAuthTries 6 Is the first one what you meant? The second seems like an attempt to avoid brute force login. Neither is what I was thinking of, but they're quite similar. LoginGraceTime means if nobody logged in within 10 minutes of the connection being opened, then it will be closed. I don't know exactly what MaxAuthTries does, but I imagine after the sixth invalid login, the connection would be closed. I found this site, check it out. It's for Red Hat (Gentoo is better!), but it's the same SSHd: http://www.faqs.org/docs/securing/chap15sec122.html Also, does Grub need any kind of password protection? I don't know if it was Grub or Lilo that allowed root access unless password protected. Am I mistaken? GRUB does have some password protection, but it is optional and only needed IIRC if you want to boot something other than the default entry. As you can see, I still have a lot to learn. ;) Me too. I'm waiting for some more hardware to arrive before I connect this server to the networks (it's primarily a NAT gateway with iptables, but also *for the LAN, not the Internet* runs Apache, ProFTPd, SSHd and rsyncd for Portage). -- Colin -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Testing how secure a server is...
On Tue, Aug 02, 2005 at 09:43:17PM -0400, Colin wrote: Neither is what I was thinking of, but they're quite similar. LoginGraceTime means if nobody logged in within 10 minutes of the connection being opened, then it will be closed. I don't know exactly what MaxAuthTries does, but I imagine after the sixth invalid login, the connection would be closed. Yes, and if the failure reaches half the number, all further failures will be logged. In the case of MaxAuthTries 6 It means that the first three failures will go unnoticed, the fourth through sixth logged, and the connection closes after that. There is, unfortunately, not an option in sshd_config to allow for the behaviour you specified, where after a password failure, the next prompt comes up delayed by five seconds. Perhaps if should be put as a feature request (=. Your best bet against brute forcing sshd is 1) Not allowing password login at all or 2) Use some sort of IDS coupled with a firewall rule to block the particular host after multiple login failures. But even that won't stop a distributed brute force. But then again, if you are guarding a system that really demands that much security against a determined cracker, you really should consider NOT putting the system on the internet. or 3) Maybe port-knocking? Note that just by running ssh on a non-standard port, you probably are avoiding most of the 5||21p7 kiddie attacks... again, only someone who really wants in on your system will take the effort to locate where sshd is listening. I found this site, check it out. It's for Red Hat (Gentoo is better!), but it's the same SSHd: http://www.faqs.org/docs/securing/chap15sec122.html -- It's easy to come up with new ideas; the hard part is letting go of what worked for you two years ago, but will soon be out of date. -- Roger Von Oech Sortir en Pantoufles: up 2 days, 9:25 -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Testing how secure a server is...
Which IDS system do you recommend? I also need to worry about HTTP auth brute force. Know any way to stop it from happening? I've read about HoneyPots, which I can only assume is a decoy for an attacker. Anyone knows how to set one up? I have a feeling that there isn't much I can do if a pro actually tries to break the system. All I can do is avoid the dummies from doing it as well. 2005/8/3, Willie Wong [EMAIL PROTECTED]: On Tue, Aug 02, 2005 at 09:43:17PM -0400, Colin wrote: Neither is what I was thinking of, but they're quite similar. LoginGraceTime means if nobody logged in within 10 minutes of the connection being opened, then it will be closed. I don't know exactly what MaxAuthTries does, but I imagine after the sixth invalid login, the connection would be closed. Yes, and if the failure reaches half the number, all further failures will be logged. In the case of MaxAuthTries 6 It means that the first three failures will go unnoticed, the fourth through sixth logged, and the connection closes after that. There is, unfortunately, not an option in sshd_config to allow for the behaviour you specified, where after a password failure, the next prompt comes up delayed by five seconds. Perhaps if should be put as a feature request (=. Your best bet against brute forcing sshd is 1) Not allowing password login at all or 2) Use some sort of IDS coupled with a firewall rule to block the particular host after multiple login failures. But even that won't stop a distributed brute force. But then again, if you are guarding a system that really demands that much security against a determined cracker, you really should consider NOT putting the system on the internet. or 3) Maybe port-knocking? Note that just by running ssh on a non-standard port, you probably are avoiding most of the 5||21p7 kiddie attacks... again, only someone who really wants in on your system will take the effort to locate where sshd is listening. I found this site, check it out. It's for Red Hat (Gentoo is better!), but it's the same SSHd: http://www.faqs.org/docs/securing/chap15sec122.html -- It's easy to come up with new ideas; the hard part is letting go of what worked for you two years ago, but will soon be out of date. -- Roger Von Oech Sortir en Pantoufles: up 2 days, 9:25 -- gentoo-user@gentoo.org mailing list -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Testing how secure a server is...
On Wed, Aug 03, 2005 at 02:25:29AM +, Raphael Melo de Oliveira Bastos Sales wrote: Which IDS system do you recommend? I also need to worry about HTTP auth brute force. Know any way to stop it from happening? I've read about HoneyPots, which I can only assume is a decoy for an attacker. Anyone knows how to set one up? I have a feeling that there isn't much I can do if a pro actually tries to break the system. All I can do is avoid the dummies from doing it as well. Beats me there? Guys? Thoughts? I don't run an enterprise server. I am just a student q=. All I care about is not having my own server rooted by script kiddies to serve warez. With that said, since I found most IDS too powerful for my needs and difficult to configure (too steep a learning curve for my limited needs), I just code my own IDS in perl q=. I just have scripts that parse the server logs and look for trigger conditions, at which time it blocks off the offending site or the entire service for a set amount of time necessary. Pretty standard way to deal with things I believe. But then, since you are really into security, perhaps you need better systems. Finally, if you are just working with the SSH portion of the brute forcing problem, /. had an article about it a few weeks back. There were MANY IDS systems posted in the comments that specifically works with openssh. HTH, W 2005/8/3, Willie Wong [EMAIL PROTECTED]: On Tue, Aug 02, 2005 at 09:43:17PM -0400, Colin wrote: Neither is what I was thinking of, but they're quite similar. LoginGraceTime means if nobody logged in within 10 minutes of the connection being opened, then it will be closed. I don't know exactly what MaxAuthTries does, but I imagine after the sixth invalid login, the connection would be closed. Yes, and if the failure reaches half the number, all further failures will be logged. In the case of MaxAuthTries 6 It means that the first three failures will go unnoticed, the fourth through sixth logged, and the connection closes after that. There is, unfortunately, not an option in sshd_config to allow for the behaviour you specified, where after a password failure, the next prompt comes up delayed by five seconds. Perhaps if should be put as a feature request (=. Your best bet against brute forcing sshd is 1) Not allowing password login at all or 2) Use some sort of IDS coupled with a firewall rule to block the particular host after multiple login failures. But even that won't stop a distributed brute force. But then again, if you are guarding a system that really demands that much security against a determined cracker, you really should consider NOT putting the system on the internet. or 3) Maybe port-knocking? Note that just by running ssh on a non-standard port, you probably are avoiding most of the 5||21p7 kiddie attacks... again, only someone who really wants in on your system will take the effort to locate where sshd is listening. I found this site, check it out. It's for Red Hat (Gentoo is better!), but it's the same SSHd: http://www.faqs.org/docs/securing/chap15sec122.html -- It's easy to come up with new ideas; the hard part is letting go of what worked for you two years ago, but will soon be out of date. -- Roger Von Oech Sortir en Pantoufles: up 2 days, 9:25 -- gentoo-user@gentoo.org mailing list -- gentoo-user@gentoo.org mailing list -- A nice box of chocolates can provide your total daily intake of calories in one place. Now, isn't that handy? Sortir en Pantoufles: up 2 days, 12:06 -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Testing how secure a server is...
Hi, Raphael Melo de Oliveira Bastos Sales wrote: Which IDS system do you recommend? I also need to worry about HTTP auth brute force. Know any way to stop it from happening? I've read about HoneyPots, which I can only assume is a decoy for an attacker. Anyone knows how to set one up? I have a feeling that there isn't much I can do if a pro actually tries to break the system. All I can do is avoid the dummies from doing it as well. ..SNIP... For a long time using 'prelude+snort' easy to set up and use, all are in portage and there is a guide to setup. Or just snort alone. Simpler easier. HTH. Rumen smime.p7s Description: S/MIME Cryptographic Signature
Re: [gentoo-user] Testing how secure a server is...
Colin wrote: Want to know how secure your server is? Try and hack it! A good port scanner like nmap should be a basic check of your firewall. I would also set nmap (if it can do this) to perform a SYN flood as it scans, to see if your server can withstand that basic DoS attack. (Adding --syn to your TCP rules in iptables can prevent SYN flooding when used with SYN cookies.) When you break in, find out why it worked and how it can be patched. I'd like to put forth a few words of caution. Depending on the complexity of your environment aggressive security scans can be fairly detrimental to your services stability. Make sure you inform the other admins if any that a scan will be taking place and do it in off hours. While most Internet facing applications today are pretty good about handling a scan internal custom built applications or newly released appliances are not. I once had massive load balancer failures across three geographic sites because of an unauthorized port scan by out new security director. Yes they shouldn't have locked up when send a weird packet, but we'd have avoided quite a bit of downtime if we had known what to look for. kashani -- gentoo-user@gentoo.org mailing list
