just wanted to get some feedback from the community. Over the last few days I have noticed my web server and email box have attempted to ssh'd to using weird names like admin,appuser,nobody,etc.... None of these are valid users. I know that I can block sshd all together with iptables but that will not work for us. I did a little research on google and found programs like sshguard and sshdfilter. Just wanted to know if anyone had any experience with anything like these programs or have any other advice. I really appreciate it.
-- Bo Lynch
I have been using fail2ban to limit the attacks. It works exactly as they advertise and I am happy with it.
-- Andrew
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Bo Lynch Sent: Monday, July 21, 2008 2:43 PM To: centos@centos.org Subject: [CentOS] Ideas for stopping ssh brute force attacks
just wanted to get some feedback from the community. Over the last few days I have noticed my web server and email box have attempted to ssh'd to using weird names like admin,appuser,nobody,etc.... None of these are valid users. I know that I can block sshd all together with iptables but that will not work for us. I did a little research on google and found programs like sshguard and sshdfilter. Just wanted to know if anyone had any experience with anything like these programs or have any other advice. I really appreciate it.
-- Bo Lynch
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
easiest way with centos board tools is iptable recent module ...
simply limit the amount of connections a host is allowed to the ssh port
iptables -N SSHSCAN iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSHSCAN iptables -A SSHSCAN -m recent --set --name SSH iptables -A SSHSCAN -m recent --update --seconds 300 --hitcount 3 --name SSH -j DROP
limits each host to 3 connections within 5 minutes. enough to make bots stop and still not too annoying for users that mistype their password 3x3 times
On Mon, Jul 21, 2008 at 10:43 PM, Bo Lynch blynch@ameliaschools.com wrote:
just wanted to get some feedback from the community. Over the last few days I have noticed my web server and email box have attempted to ssh'd to using weird names like admin,appuser,nobody,etc.... None of these are valid users. I know that I can block sshd all together with iptables but that will not work for us. I did a little research on google and found programs like sshguard and sshdfilter. Just wanted to know if anyone had any experience with anything like these programs or have any other advice. I really appreciate it.
-- Bo Lynch
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
iptables -N SSHSCAN iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSHSCAN iptables -A SSHSCAN -m recent --set --name SSH iptables -A SSHSCAN -m recent --update --seconds 300 --hitcount 3 --name SSH -j DROP
hey, this is awesome. we're currently filtering log files looking for multiple failed connections, then adding them to iptables for a few minutes. this is much cleaner. :)
thanks.
Michael Gabriel wrote:
just wanted to get some feedback from the community. Over the last few days I have noticed my web server and email box have attempted to ssh'd to using weird names like admin,appuser,nobody,etc.... None of these are valid users. I know that I can block sshd all together with iptables but that will not work for us. I did a little research on google and found programs like sshguard and sshdfilter. Just wanted to know if anyone had any experience with anything like these programs or have any other advice. I really appreciate it.
I don't know if anybody on this list tried SPA (Single Packet Authorization):
http://www.linuxjournal.com/article/9565
As another person mentioned earlier, the idea of using VPN is very good.
I use pfSense and the VPN server inside gives the connecting user an address on a virtual subnet. Each user is given a distinct fixed ip address. Then it's easy to setup firewall rules based on what you allow the user to do. I do 10 Mbps symmetric with a "recycled" 1U Dell PowerEdge 350 (PIII/800, 512 Megs RAM). We do QoS (we have 1 WME Streaming Server, 1 Darwin Streaming On Demand Server, FTP, DNS, SMTP, etc). The CPU usage is very low. I love pfSense a lot. The only thing i struggled a little was when i tried to authenticate the user with Active Directory (M$ IAS = RADIUS). It works but i have yet to find a way to assign a fixed address to each user. I can do this if i use pfSense integrated user manager (for VPN).
In another place, i use a CentOS box as a remote gateway using SSH. I changed the SSH Port, use DenyHost, force SSH V2 and forbid password login (SSH Key login mandatory). I even got a VBS script for our Winblows users that uses plink (member of the PuTTY Family) to connect, authenticate with keys and launch RDP Terminal to connect to the Winblows Terminal Server (all this automated). The only prompt the user has is for entering his remote login name (the user must know it or the connection will be refused).
I did an installer (with Nullsoft's NSIS) so allowed Winblows users can install easily all this: The installer creates icons, protect SSH keys (NTFS Encryption), etc... The installer is protected by a password.
Hope this helped!
Guy Boisvert, ing. IngTegration inc.
On Tue, Jul 22, 2008 at 12:12 AM, Guy Boisvert boisvert.guy@videotron.ca wrote:
Michael Gabriel wrote:
just wanted to get some feedback from the community. Over the last few days I have noticed my web server and email box have attempted to ssh'd to using weird names like admin,appuser,nobody,etc.... None of these are valid users. I know that I can block sshd all together with iptables but that will not work for us. I did a little research on google and found programs like sshguard and sshdfilter. Just wanted to know if anyone had any experience with anything like these programs or have any other advice. I really appreciate it.
I don't know if anybody on this list tried SPA (Single Packet Authorization):
http://www.linuxjournal.com/article/9565
As another person mentioned earlier, the idea of using VPN is very good.
I use pfSense and the VPN server inside gives the connecting user an address on a virtual subnet. Each user is given a distinct fixed ip address. Then it's easy to setup firewall rules based on what you allow the user to do. I do 10 Mbps symmetric with a "recycled" 1U Dell PowerEdge 350 (PIII/800, 512 Megs RAM). We do QoS (we have 1 WME Streaming Server, 1 Darwin Streaming On Demand Server, FTP, DNS, SMTP, etc). The CPU usage is very low. I love pfSense a lot. The only thing i struggled a little was when i tried to authenticate the user with Active Directory (M$ IAS = RADIUS). It works but i have yet to find a way to assign a fixed address to each user. I can do this if i use pfSense integrated user manager (for VPN).
In another place, i use a CentOS box as a remote gateway using SSH. I changed the SSH Port, use DenyHost, force SSH V2 and forbid password login (SSH Key login mandatory). I even got a VBS script for our Winblows users that uses plink (member of the PuTTY Family) to connect, authenticate with keys and launch RDP Terminal to connect to the Winblows Terminal Server (all this automated). The only prompt the user has is for entering his remote login name (the user must know it or the connection will be refused).
I did an installer (with Nullsoft's NSIS) so allowed Winblows users can install easily all this: The installer creates icons, protect SSH keys (NTFS Encryption), etc... The installer is protected by a password.
How do you get the keys to the server the first time after they're generated? Its kind of the chicken and an egg problem without the password authentication -- that's why I still have passwords turned on (but require __very__ strong passwords.)
In article c077d2020807220540u6ecbaa30tc3409678737dc74e@mail.gmail.com, Michael Semcheski mhsemcheski@gmail.com wrote:
How do you get the keys to the server the first time after they're generated? Its kind of the chicken and an egg problem without the password authentication -- that's why I still have passwords turned on (but require __very__ strong passwords.)
I start off with password authentication enabled, then scp my authorized_keys file to the server, check my keys work, and then disable passwords in sshd.
Cheers Tony
Bo Lynch wrote:
just wanted to get some feedback from the community. Over the last few days I have noticed my web server and email box have attempted to ssh'd to using weird names like admin,appuser,nobody,etc.... None of these are valid users. I know that I can block sshd all together with iptables but that will not work for us. I did a little research on google and found programs like sshguard and sshdfilter. Just wanted to know if anyone had any experience with anything like these programs or have any other advice. I really appreciate it.
Perhaps some FAQs on SSH at the CentOS wiki will help you out too.
http://wiki.centos.org/HowTos/Network/SecuringSSH
Regards, Max
On Mon, Jul 21, 2008 at 3:43 PM, Bo Lynch blynch@ameliaschools.com wrote:
just wanted to get some feedback from the community. Over the last few days I have noticed my web server and email box have attempted to ssh'd to using weird names like admin,appuser,nobody,etc.... None of these are valid users. I know that I can block sshd all together with iptables but that will not work for us. I did a little research on google and found programs like sshguard and sshdfilter. Just wanted to know if anyone had any experience with anything like these programs or have any other advice. I really appreciate it.
Possibly begin by not allowing root access. Don't use passwords, use keys.
http://wiki.centos.org/TipsAndTricks/SshTips/SshKeyAuthentication
On Mon, Jul 21, 2008 at 4:08 PM, Lanny Marcus lmmailinglists@gmail.com wrote:
On Mon, Jul 21, 2008 at 3:43 PM, Bo Lynch blynch@ameliaschools.com wrote:
just wanted to get some feedback from the community. Over the last few days I have noticed my web server and email box have attempted to ssh'd to using weird names like admin,appuser,nobody,etc.... None of these are valid users. I know that I can block sshd all together with iptables but that will not work for us. I did a little research on google and found programs like sshguard and sshdfilter. Just wanted to know if anyone had any experience with anything like these programs or have any other advice. I really appreciate it.
Possibly begin by not allowing root access. Don't use passwords, use keys.
http://wiki.centos.org/TipsAndTricks/SshTips/SshKeyAuthentication
The above link is mostly dead. The data isn't there yet.
http://wiki.centos.org/TipsAndTricks/BecomingRoot
if you can sudo into your servers, that might help.
Also, use a different port. Many ways to skin a cat.
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org]On Behalf Of Bo Lynch Sent: Monday, July 21, 2008 3:43 PM To: centos@centos.org Subject: [CentOS] Ideas for stopping ssh brute force attacks
just wanted to get some feedback from the community. Over the last few days I have noticed my web server and email box have attempted to ssh'd to using weird names like admin,appuser,nobody,etc.... None of these are valid users. I know that I can block sshd all together with iptables but that will not work for us. I did a little research on google and found programs like sshguard and sshdfilter. Just wanted to know if anyone had any experience with anything like these programs or have any other advice. I really appreciate it.
-- Bo Lynch
Just change the default port. You can also limit the allowed nocks on door with iptables, but changing the port is much eaieer. Cleans up the logs real nice. Dan
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
On Mon, Jul 21, 2008 at 4:11 PM, Dan Carl danc@bluestarshows.com wrote:
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org]On Behalf Of Bo Lynch Sent: Monday, July 21, 2008 3:43 PM To: centos@centos.org Subject: [CentOS] Ideas for stopping ssh brute force attacks
just wanted to get some feedback from the community. Over the last few days I have noticed my web server and email box have attempted to ssh'd
to
using weird names like admin,appuser,nobody,etc.... None of these are valid users. I know that I can block sshd all together with iptables but that will not work for us. I did a little research on google and found programs like sshguard and sshdfilter. Just wanted to know if anyone had any experience with anything like these programs or have any other
advice.
I really appreciate it.
-- Bo Lynch
Just change the default port. You can also limit the allowed nocks on door with iptables, but changing the port is much eaieer. Cleans up the logs real nice. Dan
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
PortKnocking - ports appear closed until the correct knock on the ports.
Dan Carl wrote:
Just change the default port. You can also limit the allowed nocks on door with iptables, but changing the port is much eaieer. Cleans up the logs real nice. Dan
I'll second that. Combining that with the SSH iptables entries to limit the number of attempts will help as well. Those two actions will, effectively, make the brute force impossible.
Bo Lynch wrote:
just wanted to get some feedback from the community. Over the last few days I have noticed my web server and email box have attempted to ssh'd to using weird names like admin,appuser,nobody,etc.... None of these are valid users. I know that I can block sshd all together with iptables but that will not work for us. I did a little research on google and found programs like sshguard and sshdfilter. Just wanted to know if anyone had any experience with anything like these programs or have any other advice. I really appreciate it.
There's a page on the Wiki with a few suggestions for hardening SSH:
http://wiki.centos.org/HowTos/Network/SecuringSSH
There are a number of measures you can take and employing a few in combination is always a good idea. Strong passwords are a must as is disabling root logins. Firewalling and/or key-based authentication with passwords disabled are great where that is possible. Moving SSH to a non-standard port will certainly reduce your levels of background noise but doesn't necessarily make your setup inherently more secure.
My personal opinion is that there is enough there to work with without having to resort to 3rd party add-ons :)
Provided you have ssh set up to ensure that root cannot login directly and/or keys instead of passwords must be used, you aren't in much danger of being compromised.
To ensure the logs are mostly kept clean however, you need yet another solution such as changing the port, port-knocking, or a script such as fail2ban, denyhosts and blockhosts.
fail2ban is a script which writes blacklisted IPs to iptables then denies them access to every service including ftp and http, not just ssh.
Because I don't believe a solution such as fail2ban will scale (it can't be healthy having tens of thousands of IPs in iptables), I use denyhosts on my servers and have done so successfully for the past 12 months. Denyhosts is a script which writes blacklisted IPs to hosts.deny, preventing them from accessing ssh as well as any other service which uses tcp wrappers. It has a truly wonderful feature where you can sync your results with a central server to share IPs for banning. This means my servers now have about 12000 IPs which are permanently blacklisted. There are just two disadvantages with denyhosts: with a large number of entries in hosts.deny, there is a noticeable delay (several seconds in my case) when logging in with ssh. And you can only deny requests which use tcp wrappers.
I've never used Blockhosts, but I believe it is similar to fail2ban, in that it can disallow blacklisted IPs from accessing any service, not just ssh.
Just one other thing: if you use a script, you need to be careful you don't accidentally ban your own IP (by entering a wrong password too many times) when accessing a remote server. :/
Whatever, you decided to use, the more security you have, the more awkward it will be to access your own server/s.
When using denyhosts, you'll want to keep your IP's in hosts.allow so even if you're "banned" you can still get access. :-)
Tim Nelson Systems/Network Support Rockbochs Inc. (218)727-4332 x105
----- Original Message ----- From: "D Steward" dsteward@internode.on.net To: "CentOS mailing list" centos@centos.org Sent: Monday, July 21, 2008 5:05:13 PM GMT -06:00 Guadalajara / Mexico City / Monterrey Subject: Re: [CentOS] Ideas for stopping ssh brute force attacks
Just one other thing: if you use a script, you need to be careful you don't accidentally ban your own IP (by entering a wrong password too many times) when accessing a remote server. :/
_______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Mon, 2008-07-21 at 17:09 -0500, Tim Nelson wrote:
When using denyhosts, you'll want to keep your IP's in hosts.allow so even if you're "banned" you can still get access. :-)
Yup. Unfortunately, my ISP's plan uses dynamic IPs, so I have to enter various subnets to stay safe. :(
On Tue, Jul 22, 2008, D Steward wrote:
On Mon, 2008-07-21 at 17:09 -0500, Tim Nelson wrote:
When using denyhosts, you'll want to keep your IP's in hosts.allow so even if you're "banned" you can still get access. :-)
Yup. Unfortunately, my ISP's plan uses dynamic IPs, so I have to enter various subnets to stay safe. :(
If you do not allow password authentication and use good pass phrases on your identity, the only thing really gained by restricting on IP ranges is restricting the number of reject messages in your log files. The fail2ban program does a nice job of limiting the number of rejection messages in the logs.
Another possibility is to set up OpenVPN on your system, which authenticates on ssl certificates and works nicely even from dynamic IPs behind NAT. Then you can ssh into the private LAN behind your firewall via OpenVPN.
Bill
On Mon, July 21, 2008 6:47 pm, Bill Campbell wrote:
On Tue, Jul 22, 2008, D Steward wrote:
On Mon, 2008-07-21 at 17:09 -0500, Tim Nelson wrote:
When using denyhosts, you'll want to keep your IP's in hosts.allow so even if you're "banned" you can still get access. :-)
Yup. Unfortunately, my ISP's plan uses dynamic IPs, so I have to enter various subnets to stay safe. :(
If you do not allow password authentication and use good pass phrases on your identity, the only thing really gained by restricting on IP ranges is restricting the number of reject messages in your log files. The fail2ban program does a nice job of limiting the number of rejection messages in the logs.
Another possibility is to set up OpenVPN on your system, which authenticates on ssl certificates and works nicely even from dynamic IPs behind NAT. Then you can ssh into the private LAN behind your firewall via OpenVPN.
Bill
INTERNET: bill@celestial.com Bill Campbell; Celestial Software LLC URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way Voice: (206) 236-1676 Mercer Island, WA 98040-0820 Fax: (206) 232-9186
Foreign aid might be defined as a transfer from poor people in rich countries to rich people in poor countries -- Douglas Casey _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Bill,
we have been looking at implementing OpenVPN to allow access to the internal LAN. For a firewall, we basically have iptables with 2 nics doing NAT. So would the OpenVPN server live inside of our private network and just do some forwards with iptables on the firewall or would it be better to implement it with by itself with 2 nics one on the public and one on the private?
Bo Lynch wrote:
we have been looking at implementing OpenVPN to allow access to the internal LAN. For a firewall, we basically have iptables with 2 nics doing NAT. So would the OpenVPN server live inside of our private network and just do some forwards with iptables on the firewall or would it be better to implement it with by itself with 2 nics one on the public and one on the private?
openvpn uses a simple TCP socket for its transport, so sure, port forwarding would work fine. or running it ON your firewall server, if thats something which openvpn can run on (pfsense, any linux firewall, etc).
On Mon, Jul 21, 2008, John R Pierce wrote:
Bo Lynch wrote:
we have been looking at implementing OpenVPN to allow access to the internal LAN. For a firewall, we basically have iptables with 2 nics doing NAT. So would the OpenVPN server live inside of our private network and just do some forwards with iptables on the firewall or would it be better to implement it with by itself with 2 nics one on the public and one on the private?
openvpn uses a simple TCP socket for its transport, so sure, port forwarding would work fine. or running it ON your firewall server, if thats something which openvpn can run on (pfsense, any linux firewall, etc).
Actually the public interface with OpenVPN is udp by default. We have been using it for a while now with a variety of clients, Windows, Mac OS X, and other Linux boxen.
Bill
D Steward wrote:
Because I don't believe a solution such as fail2ban will scale (it can't be healthy having tens of thousands of IPs in iptables), I use denyhosts
Wherever possible I use layer 2 bridging OpenBSD firewalls in front of my networks, I don't have a problem with brute force attacks but it seems it can scale to tens of thousands of IPs without a problem. I'm not sure if iptables has similar capabilities or not --
http://www.openbsd.org/faq/pf/tables.html
"[..]Lookups against a table are very fast and consume less memory and processor time than lists. For this reason, a table is ideal for holding a large group of addresses as the lookup time on a table holding 50,000 addresses is only slightly more than for one holding 50 addresses"
And the pf equivilent to the iptables throttling:
http://www.openbsd.org/faq/pf/filter.html
An example:
table <abusive_hosts> persist block in quick from <abusive_hosts>
pass in on $ext_if proto tcp to $web_server \ port www flags S/SA keep state \ (max-src-conn 100, max-src-conn-rate 15/5, overload <abusive_hosts> flush)
This does the following:
* Limits the maximum number of connections per source to 100 * Rate limits the number of connections to 15 in a 5 second span * Puts the IP address of any host that breaks these limits into the <abusive_hosts> table * For any offending IP addresses, flush any states created by this rule. ---
I don't like/use OpenBSD for anything other than firewalls. But I do think as a firewall, pf really can't be beat, the configuration for typical rules just 'flows'. IPTables by comparison is so cryptic. (speaking as a past user of ipfwadm, ipfw, ipchains, iptables, pf, and Cisco PIX, which is probably the worst of the ones I've used).
I use linux pretty much everywhere else other than firewalls. Even my preferred network gear - load balancers and switches run linux (commercial variants).
nate
nate wrote:
I don't like/use OpenBSD for anything other than firewalls. But I do think as a firewall, pf really can't be beat, the configuration for typical rules just 'flows'. IPTables by comparison is so cryptic. (speaking as a past user of ipfwadm, ipfw, ipchains, iptables, pf, and Cisco PIX, which is probably the worst of the ones I've used).
while I haven't personally used this, I've heard enough good things about it from folks I know and trust that I'll stick in a mention of pfSense... pfSense is a turnkey BSD hybrid, which uses freeBSD's kernel with openBSD's pf, all wrapped up in a nice easy to use web interface (and you can still get into shell and manipulate the pf scripts directly).
its optimized so it can run off as little as a 128MB flash card (CF).
Pfsense rules...in my humble opinion, does the job better than iptables. and like John said it can be easily configured via web.
Bo Lynch wrote:
just wanted to get some feedback from the community. Over the last few days I have noticed my web server and email box have attempted to ssh'd to using weird names like admin,appuser,nobody,etc.... None of these are valid users. I know that I can block sshd all together with iptables but that will not work for us. I did a little research on google and found programs like sshguard and sshdfilter. Just wanted to know if anyone had any experience with anything like these programs or have any other advice. I really appreciate it.
I have moved sshd to a different port number.
On Mon, Jul 21, 2008 at 04:43:11PM -0400, Bo Lynch wrote:
just wanted to get some feedback from the community. Over the last few days I have noticed my web server and email box have attempted to ssh'd to using weird names like admin,appuser,nobody,etc.... None of these are valid users. I know that I can block sshd all together with iptables but that will not work for us. I did a little research on google and found programs like sshguard and sshdfilter. Just wanted to know if anyone had any experience with anything like these programs or have any other advice. I really appreciate it.
If you have a web server on the same system, you can use php and tcp wrappers to restrict ssh inbound traffic to known systems, plus give you a back-door key to permit yourself access from arbitrary systems on the internet.
http://wiki.xdroop.com/space/Linux/Limited+SSH+Access
No method is perfect, but something that seems to work ok in practice is to just move ssh to a different TCP port, and -j DROP the unused ports.
Failproof? No, but it reduces the noise tremendously.
If the script kiddies learn the new port (unlikely), either move it to another port, or apply one of the other methods already recommended in this thread.
-
Bill Campbell -
Bo Lynch -
D Steward -
Dan Carl -
David Mackintosh -
Eucke -
Florin Andrei -
Guy Boisvert -
John R Pierce -
Lanny Marcus -
Lundgren, Andrew -
Max Hetrick -
Michael Gabriel -
Michael Semcheski -
nate -
Ned Slider -
Rob Townley -
Robert Moskowitz -
Spiro Harvey, Knossos Networks Ltd -
Tim Nelson -
tony＠softins.clara.co.uk -
Victor Padro