So I setup ssh on a server so I could do some work from home and I think the second I opened it every sorry monkey from around the world has been trying every account name imaginable to get into the system. What's a good way to deal with this?
iptables, disallow root login via ssh, no valid shell for users that don't need one, strong passwords, keys would be a good start. Mike On Tue, Mar 25, 2008 at 11:48 AM, Tim Alberts <talberts at msiscales.com> wrote:> So I setup ssh on a server so I could do some work from home and I think > the second I opened it every sorry monkey from around the world has been > trying every account name imaginable to get into the system. > > What's a good way to deal with this? > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos >
Tim Alberts wrote:> So I setup ssh on a server so I could do some work from home and I > think the second I opened it every sorry monkey from around the world > has been trying every account name imaginable to get into the system. > > What's a good way to deal with this? > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos >1. Change the default port 2. use only SSH protocol 2 3. Install some brute force protection which can automatically ban an IP on say 5 / 10 failed login attempts 4. ONLY allow SSH access from your IP, if it's static. Or signup for a DynDNS account, and then only allow SSH access from your DynDNS domain -- Kind Regards Rudi Ahlers CEO, SoftDux Web: http://www.SoftDux.com Check out my technical blog, http://blog.softdux.com for Linux or other technical stuff, or visit http://www.WebHostingTalk.co.za for Web Hosting stugg
Tim Alberts wrote:> So I setup ssh on a server so I could do some work from home and I > think the second I opened it every sorry monkey from around the world > has been trying every account name imaginable to get into the system.actually, those 'attempts' are coming from virus infected systems which randomly probe for SSH servers. they try the same sorry 10 or 15 accounts with the same lame 10 or 15 passwords, so its really just an annoyance if you're anal about logwatch output.
Tim Alberts wrote:> So I setup ssh on a server so I could do some work from home and I > think the second I opened it every sorry monkey from around the world > has been trying every account name imaginable to get into the system. >FYI, here's a list of the losers (so far). I suggest everyone wish horrible things happen to these people. *201.70.39.3 **201.6.116.177 **200.161.198.16 **164.164.33.73 **66.114.252.200 **24.202.149.253 **218.201.147.80 **200.42.174.109 **128.135.195.122 **67.19.188.210 **24.202.149.253 **203.82.65.252 **124.1.204.61 **210.206.124.211 **61.128.122.13 **202.106.62.197 *
On Tue, Mar 25, 2008 at 12:48 PM, Tim Alberts <talberts at msiscales.com> wrote:> So I setup ssh on a server so I could do some work from home and I think > the second I opened it every sorry monkey from around the world has been > trying every account name imaginable to get into the system. > > What's a good way to deal with this?DenyHosts - http://denyhosts.sourceforge.net/ Also, when you set it up, set it to download the lists from their website. These lists are IPs that other users have found scanning their network. -- -matt
Tim Alberts wrote:> So I setup ssh on a server so I could do some work from home and I > think the second I opened it every sorry monkey from around the world > has been trying every account name imaginable to get into the system. > > What's a good way to deal with this? > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos >You could consider to disallow password access. Use only public key authentication. The "attacks" will remain, but can never succeed. (The scripts are not smart so they keep trying for hours sometimes) sshd_config: PasswordAuthentication no Now create a public/private ssh keypair and put the public key in ~/.ssh/authorized_keys on the remote machine. # local machine* ssh-keygen -t dsa* *scp** ~/.ssh/id_dsa.pub remote_host:.ssh/authorized_keys *# remote host* **chmod 600 ~/.ssh/authorized_keys chmod 700 ~/.ssh * To be really save, only allow access from a limited number of IP addresses: ** cat ~/.ssh/authorized_keys from="123.345.133.123,home.com,work.com" ssh-dss AAAAB3NzaC1kc3MA<snip>AqNY= my at email Theo
On Tue, Mar 25, 2008 at 09:48:17AM -0700, Tim Alberts wrote:> So I setup ssh on a server so I could do some work from home and I think > the second I opened it every sorry monkey from around the world has been > trying every account name imaginable to get into the system. > > What's a good way to deal with this?This is what I do. http://wiki.xdroop.com/space/Linux/Limited+SSH+Access -- /\oo/\ / /()\ \ David Mackintosh | dave at xdroop.com | http://www.xdroop.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://lists.centos.org/pipermail/centos/attachments/20080325/9cbe345e/attachment-0002.sig>
David Mackintosh wrote:> On Tue, Mar 25, 2008 at 09:48:17AM -0700, Tim Alberts wrote: > >> So I setup ssh on a server so I could do some work from home and I think >> the second I opened it every sorry monkey from around the world has been >> trying every account name imaginable to get into the system. >> >> What's a good way to deal with this? >> > > This is what I do. > > http://wiki.xdroop.com/space/Linux/Limited+SSH+Access > >That sounds great for getting around a remote dynamic IP address, but some more authentication/security on that web page is necessary, otherwise, anyone who finds that web page is given access?
Tony Placilla <bofh at jhu.edu> Sr. UNIX Systems Administrator The Sheridan Libraries Johns Hopkins University>>> On Tue, Mar 25, 2008 at 12:48 PM, in message <47E92CD1.3060804 at msiscales.com>,Tim Alberts <talberts at msiscales.com> wrote:> So I setup ssh on a server so I could do some work from home and I think > the second I opened it every sorry monkey from around the world has been > trying every account name imaginable to get into the system. > > What's a good way to deal with this? >I am subject to this on an all too frequent basis. Here's what we've put in place that seems to work. DenyHosts. It's available through the rpmforge (or Dag's) repo. Just be sure you edit the config to allow SNYC_DOWNLOAD & create an appropriate allowed.hosts file based upon your needs. sshd in protocol 2 privilege separation no root logins and a nifty little PAM trick is to create a group called ssh_users & and those that should be able to access the server are put into that as their supplementary group. Edit sshd_config & add AllowGroups ssh_users it's part & parcel of the whole "layered security" idea it's cut the noise in my logs down by 99.9% plus I sleep better :)
Tim, The important ones, imho -- 1. disallow root login 2. disallow password authentication (use keys, as someone else has described) 3. prevent multiple failed attempts using iptables: # Log and block repeated attempts to access SSH # See /proc/net/ipt_recent file for low-level data # Block attempts to access SSH if 4 or more attempts made in the last 60 secs -A RH-Firewall-1-INPUT -p tcp --syn --dport 22 -m recent --name sshattack --set -A RH-Firewall-1-INPUT -p tcp --dport 22 --syn -m recent --name sshattack --rcheck --seconds 60 --hitcount 4 -j LOG --log-prefix "SSH REJECT: " -A RH-Firewall-1-INPUT -p tcp --dport 22 --syn -m recent --name sshattack --rcheck --seconds 60 --hitcount 4 -j REJECT 4. if possible, limit ssh access to your static ip. That all seems reasonably secure to me! Liam Tim Alberts wrote:> So I setup ssh on a server so I could do some work from home and I > think the second I opened it every sorry monkey from around the world > has been trying every account name imaginable to get into the system. > > What's a good way to deal with this? > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos >-- Liam Kirsher PGP: http://liam.numenet.com/pgp/
Kai Schaetzl wrote:> Robert Spangler wrote on Wed, 26 Mar 2008 08:03:48 -0400: > > > If you are going to use VPN then why not setup your remote site to > > use VPN and bypass SSH altogether then? > > There could be several reasons, for instance: > 1. SSH is all what is necessary > 2. it's probably easier to have *one* VPN and then be able to ssh to > dozens of other machines instead of setting up VPN on all of them and > running several VPN tunnels at onceUse VPN to connect to your network and then ssh through the VPN tunnel to any machines you need to work with. This way only the VPN is exposed to the Internet.> > Bottom line is if you want to be secure don't use passwords for > > login. > > Still doesn't stop those brute-force attacks. It just makes them > fail. That's the point about moving port etc., not the security.Agreed. I have one machine on my network that exposes an ssh connection on a non-standard port. My logs for the last month do not show a single failed connection attempt. -- Bowie
>> 3. Install some brute force protection which can automatically ban an >> IP on say 5 / 10 failed login attempts >The only software I know that could do this isn't supported anymore(trisentry) or is too confusing and I don't know it yet (snort). Suggestions? OSSEC-HIDS is pretty good.
Kai Schaetzl wrote:> Bowie Bailey wrote on Wed, 26 Mar 2008 09:18:56 -0500: > > > Use VPN to connect to your network and then ssh through the VPN > > tunnel to any machines you need to work with. This way only the > > VPN is exposed to the Internet. > > if the machines are within the LAN, yes. My original point was that > if you have a static IP address for your local LAN *and* you want to > restrict the *remote* machines to be ssh-connectable only from that > LAN (which is a good security measure) *and* you are on the road you > can still work on your remote machine by VPNing into your LAN. There > are other solutions, but VPN is probably the easiest one as most SOHO > routers should be able to terminate a VPN and it's likely that you > want to connect to your LAN via VPN for other purposes, anyway. Doing > that for the machines *within* your LAN is granted.Ok. I was thinking of a simpler "traveling user needs access to machines on the LAN" scenario. :) -- Bowie
Tim Alberts wrote:> So I setup ssh on a server so I could do some work from home and I > think the second I opened it every sorry monkey from around the world > has been trying every account name imaginable to get into the system. > > What's a good way to deal with this? >SSH question. Can I setup a group of users who can access SSH from the local network. Then a separate list of users that can access SSH from the internet?
Tim Alberts wrote:> So I setup ssh on a server so I could do some work from home and I > think the second I opened it every sorry monkey from around the world > has been trying every account name imaginable to get into the system. > > What's a good way to deal with this?- keep your ssh up to date. - only enable protocol version 2 - disable root login - create a group and only allow login to members of this group. - the authorized users should have a strong password, if password authentication is enabled - better not use logins that are the same as email addresses as these can be eaisly harvested and tried. - use public key authentication - depending on your situation, you can disable password authentication. however, make sure you don't lock yourself. also, if your users need to connect from anywhere, they can't use a key (except if they have a usb key or the like) - if possible, only allow access from a specific set of IPs/networks. - "rate limit". you can use iptables recent module to catch multiple attempts. - "punish". you can parse your logs and add offenders to a blacklist (to be used in iptables). denyhosts, fail2ban, ... can be used here. make sure not to lock yourself. so always have a rule to allow access from some trusted IP before the rule that blocks access. - you can restrict access to IPv6, IPSec or any VPN if you can always use these. but if you have a VPN, you may or may not need ssh. - if you have multiple machines, consider allowing free access to only few of these, and then use them as gateways. not very practical though. - change the port. while this doesn't make your system more secure, your logs will become silent. This may not be practical (need to specify the port in scripts... etc). you can use two ports (using two Port statements in sshd_config) and have different configurations (only allow port 22 from specific networks for example). - a log parser could run geoiplookup and add IPs to an iptables blacklist if they are in a "far away" country. - you can add a "pre-authorization" mechanism: user must do something before trying to ssh. In these web days, a web form is both easy to setup and use (compare this to "port knocking", SPA, ...). One problem here is that you don't want to give the web user the ability to change your iptables configuration without extreme care. - configure a banner so that your users get used to see it. if they connect and don't see your banner, they should alert you. ( Note. if your users connect with passwords from "unsafe" places, keyloggers and the like can steal their login/password or their key file and passphrase.
Tim Alberts wrote:> So I setup ssh on a server so I could do some work from home and I think > the second I opened it every sorry monkey from around the world has been > trying every account name imaginable to get into the system. > > What's a good way to deal with this? > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos~> cat sshd_config ... IgnoreRhosts yes PermitEmptyPasswords no UsePAM yes Use PAM (Pluggable Authentication Modules). Did anyone mention it here? http://www.kernel.org/pub/linux/libs/pam/whatispam.html "Basically, it is a flexible mechanism for authenticating users." Regards, Daniel -- Daniel Andrzejewski student IT Administrator Elec Engr & Comp Science University of Tennessee (865) 974 - 4388 (work) "Investment in knowledge always pays the best interest" Benjamin Franklin --