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@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@centos.org http://lists.centos.org/mailman/listinfo/centos
Mike Kercher wrote:
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
iptables..add the ip of the attack source to reject? They keep moving IP, this is very time consuming (but I am doing it). I don't allow root login. I think I got a good password, and I got keys setup so I know I'm talking to my server.
Tim Alberts wrote:
I got keys setup so I know I'm talking to my server.
This is probably not what he meant. You can use a key pair to authenticate with the SSH server and turn off password authentication entirely. That makes password guessing attacks utterly impossible, because the server will only accept a response signed with your private key.
ssh-keygen -t rsa
or
ssh-keygen -t dsa
generates a key pair. Do this on your local machine, and append the contents of your $HOME/.ssh/id_rsa.pub (or id_dsa if you chose DSA instead of RSA) to your $HOME/.ssh/authorized_keys file on the remote system.
This method is somewhat more complicated to setup, since all users must have public keys in their $HOME/.ssh/authorized_keys file, or they can't login.
Regards Ingemar
Tim Alberts wrote:
iptables..add the ip of the attack source to reject? They keep moving IP, this is very time consuming (but I am doing it).
...
stop thinking 'they', that implies theres someone intentionally targetting you. its just viruses randomly squirting out connection requests from 1000s of infected hosts around the world.
John R Pierce wrote:
Tim Alberts wrote:
iptables..add the ip of the attack source to reject? They keep moving IP, this is very time consuming (but I am doing it).
...
stop thinking 'they', that implies theres someone intentionally targetting you. its just viruses randomly squirting out connection requests from 1000s of infected hosts around the world.
Oh no..they're out there. They're watching us now. They know we're talking about them. :)
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@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
Rudi Ahlers wrote:
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@centos.org http://lists.centos.org/mailman/listinfo/centos
- Change the default port
- use only SSH protocol 2
- 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
Fail2Ban is a good brute force protector. It works in conjunction with IPTables to block IPs that are "attacking" for a said duration of time. :)
On Tuesday 25 March 2008 17:00:18 James A. Peltier wrote:
Fail2Ban is a good brute force protector. It works in conjunction with IPTables to block IPs that are "attacking" for a said duration of time.
And I can confirm that it's a doddle to set up. The defaults were fine for me - nothing needed changing at all.
Anne
James A. Peltier wrote:
Rudi Ahlers wrote:
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@centos.org http://lists.centos.org/mailman/listinfo/centos
- Change the default port
- use only SSH protocol 2
- 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
Fail2Ban is a good brute force protector. It works in conjunction with IPTables to block IPs that are "attacking" for a said duration of time. :)
I haven't used Fail2Ban, but I do like what I've been experiencing with apf[1] and sim[2]. The Reactive Address Blocking (RAB) feature in apf is a bit timesaver, but I expect Fail2Ban has something similar. apf is basically an easier (for me, anyway) of managing iptables. Manually banning an ip or block is as easy as adding it to the deny_hosts.rules file and restarting apf. RAB really helps, again imo.
HTH, -Ray [1] http://rfxnetworks.com/apf.php [2] http://rfxnetworks.com/sim.php
Ray Leventhal wrote:
James A. Peltier wrote:
Rudi Ahlers wrote:
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@centos.org http://lists.centos.org/mailman/listinfo/centos
- Change the default port
- use only SSH protocol 2
- 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
Fail2Ban is a good brute force protector. It works in conjunction with IPTables to block IPs that are "attacking" for a said duration of time. :)
I haven't used Fail2Ban, but I do like what I've been experiencing with apf[1] and sim[2]. The Reactive Address Blocking (RAB) feature in apf is a bit timesaver, but I expect Fail2Ban has something similar. apf is basically an easier (for me, anyway) of managing iptables. Manually banning an ip or block is as easy as adding it to the deny_hosts.rules file and restarting apf. RAB really helps, again imo.
HTH, -Ray [1] http://rfxnetworks.com/apf.php [2] http://rfxnetworks.com/sim.php _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Here's a quick howto for Suse10.3, but the principles stay the same. Fail2Ban can be used for many other things as well, like FTP, MySQL, SMTP, etc :)
On Fri Mar 28, 2008 07:47PM, Rudi Ahlers wrote:
Ray Leventhal wrote:
James A. Peltier wrote:
Rudi Ahlers wrote:
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@centos.org http://lists.centos.org/mailman/listinfo/centos
- Change the default port
- use only SSH protocol 2
- 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
Fail2Ban is a good brute force protector. It works in conjunction with IPTables to block IPs that are "attacking" for a said duration of time. :)
I haven't used Fail2Ban, but I do like what I've been experiencing with apf[1] and sim[2]. The Reactive Address Blocking (RAB) feature in apf is a bit timesaver, but I expect Fail2Ban has something similar. apf is basically an easier (for me, anyway) of managing iptables. Manually banning an ip or block is as easy as adding it to the deny_hosts.rules file and restarting apf. RAB really helps, again imo.
HTH, -Ray [1] http://rfxnetworks.com/apf.php [2] http://rfxnetworks.com/sim.php _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Here's a quick howto for Suse10.3, but the principles stay the same. Fail2Ban can be used for many other things as well, like FTP, MySQL, SMTP, etc :)
I don't see the how-to...
Trey Sizemore wrote:
On Fri Mar 28, 2008 07:47PM, Rudi Ahlers wrote:
Ray Leventhal wrote:
James A. Peltier wrote:
Rudi Ahlers wrote:
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@centos.org http://lists.centos.org/mailman/listinfo/centos
- Change the default port
- use only SSH protocol 2
- 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
Fail2Ban is a good brute force protector. It works in conjunction with IPTables to block IPs that are "attacking" for a said duration of time. :)
I haven't used Fail2Ban, but I do like what I've been experiencing with apf[1] and sim[2]. The Reactive Address Blocking (RAB) feature in apf is a bit timesaver, but I expect Fail2Ban has something similar. apf is basically an easier (for me, anyway) of managing iptables. Manually banning an ip or block is as easy as adding it to the deny_hosts.rules file and restarting apf. RAB really helps, again imo.
HTH, -Ray [1] http://rfxnetworks.com/apf.php [2] http://rfxnetworks.com/sim.php _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Here's a quick howto for Suse10.3, but the principles stay the same. Fail2Ban can be used for many other things as well, like FTP, MySQL, SMTP, etc :)
I don't see the how-to...
Sorry, here it is
http://howtoforge.net/fail2ban_opensuse10.3
Rudi Ahlers wrote:
Trey Sizemore wrote:
On Fri Mar 28, 2008 07:47PM, Rudi Ahlers wrote:
Ray Leventhal wrote:
James A. Peltier wrote:
Rudi Ahlers wrote:
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@centos.org > http://lists.centos.org/mailman/listinfo/centos > >
- Change the default port
- use only SSH protocol 2
- 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
Fail2Ban is a good brute force protector. It works in conjunction with IPTables to block IPs that are "attacking" for a said duration of time. :)
I haven't used Fail2Ban, but I do like what I've been experiencing with apf[1] and sim[2]. The Reactive Address Blocking (RAB) feature in apf is a bit timesaver, but I expect Fail2Ban has something similar. apf is basically an easier (for me, anyway) of managing iptables. Manually banning an ip or block is as easy as adding it to the deny_hosts.rules file and restarting apf. RAB really helps, again imo.
HTH, -Ray [1] http://rfxnetworks.com/apf.php [2] http://rfxnetworks.com/sim.php _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Here's a quick howto for Suse10.3, but the principles stay the same. Fail2Ban can be used for many other things as well, like FTP, MySQL, SMTP, etc :)
I don't see the how-to...
Sorry, here it is
(leaving quoted text in place for illustrative purposes)
I would really appreciate it, as well as most others I believe, if everyone could begin trimming down their replies..
When I read the emails of this thread, I had to scroll down quite a bit to get to the text, which wastes a few seconds of my time and leaves me slightly annoyed.
This in and of itself is surely no big deal, but multiply that with the number of subscribers on this list, and we are truly getting somewhere.
So, please, in the future when replying to an email, delete all text that isn't directly related to your reply.
Rudi Ahlers wrote:
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@centos.org http://lists.centos.org/mailman/listinfo/centos
- Change the default port
I could do that, but if they already know about it, a simple port scan and they'll probably find it again. Plus I gotta go tell all my client programs the new port and I don't know how to do that on most of them (what a hassle).
- use only SSH protocol 2
got it.
- 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?
- 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
Yeah my home account is on dynamic IP. I'd love to setup the firewall to only allow my home computer. You're talking about these guys? http://www.dyndns.com/ never used them before, but it looks like a good idea. Especially since it's free (for 5 hosts) if I read correctly.
- Change the default port
I could do that, but if they already know about it, a simple port scan and they'll probably find it again. Plus I gotta go tell all my client programs the new port and I don't know how to do that on most of them (what a hassle).
If you're talking about people who are just scanning your machine and then doing brute force on the port, changing the port likely will solve that since these are just automated robots. A human might actually do a portscan, but just a port change will probably stop your security logs from going crazy.
Of course the hassle part may be a show-stopper here. :)
- use only SSH protocol 2
got it.
- 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?
denyhosts is pretty widely used. You could probably also make use of iptables.
- 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
Yeah my home account is on dynamic IP. I'd love to setup the firewall to only allow my home computer. You're talking about these guys? http://www.dyndns.com/ never used them before, but it looks like a good idea. Especially since it's free (for 5 hosts) if I read correctly.
Ray
- 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?
denyhosts is pretty widely used. You could probably also make use of iptables.
I used it a while back and it worked well except the time I locked my own IP out somehow (or perhaps some bot infected PC from my ISP that had that IP previously took care of that for me, not sure as I didn't dig deeper).
One thing I did was set up hosts.deny for ranges of IPs that I knew I would never come from (i.e. overseas), obtaining them from IANA. A bit tedious, but you may deem that option to be worth your while. Alternatively if you only ever come from a given range of IPs (your ISP), then you could deny all in hosts.deny and then in hosts.allow only allow your ISP's range of IPs. But if ever on the road you'll not be able to connect unless you happen to have your home system set up for SSH which would then allow you to SSH to the office from it. The idea being that a person coming from an IP outside of your ISP wanting access to your office PC would have to know that it only allows connection from certain IPs and then seek out a machine on that IP - your home PC - which could be compromised to in turn launch an attach against the office PC from it. The inconvenience to you of having to first go through your home PC to get to the office PC would only apply when away from your ISP connection. Of course if you are on the road alot then this may not be an attractive option.
Jacques B.
On Tuesday 25 March 2008 12:55, Rudi Ahlers wrote:
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@centos.org http://lists.centos.org/mailman/listinfo/centos
- Change the default port
Is an option but a waste of time as a scanner will find the port it was moved to.
- use only SSH protocol 2
Agree
- Install some brute force protection which can automatically ban an IP
on say 5 / 10 failed login attempts
Fail2ban comes to mind.
- 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
I would suggest using keys for logins. No password needed and if the connecting machine doesn't have the key they don't get a chance to guess at the password.
The idea of only allowing for strict ip address is good but what if you are on the move? Now you cannot log in either, but if you are using a key no matter where you are you have access.
We have a public server and we did the following for SSH:
* Only Protocol v2 * Only key authentication, no password and large keys (just for the fun). * Disable root login. * Monitoring, we usually blacklists IPs trying to log in with many unsuccessful attempts, using some custom scripts and iptables, but there is many programs available for this now.
Additionally you could also add:
* Throttling, you could throttle the amount of connections to the port, there is already many tutorials on this on the internet.
I find setting a non standard port useless, all you need is to keep your ssh server updated (including libraries) and follow common security criteria and you should sleep soundly every night.
On Tue, Mar 25, 2008 at 5:33 PM, Robert Spangler mlists@zoominternet.net wrote:
On Tuesday 25 March 2008 12:55, Rudi Ahlers wrote:
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@centos.org http://lists.centos.org/mailman/listinfo/centos
- Change the default port
Is an option but a waste of time as a scanner will find the port it was moved to.
- use only SSH protocol 2
Agree
- Install some brute force protection which can automatically ban an IP
on say 5 / 10 failed login attempts
Fail2ban comes to mind.
- 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
I would suggest using keys for logins. No password needed and if the connecting machine doesn't have the key they don't get a chance to guess at the password.
The idea of only allowing for strict ip address is good but what if you are on the move? Now you cannot log in either, but if you are using a key no matter where you are you have access.
--
Regards Robert
Smile... it increases your face value! Linux User #296285 http://counter.li.org
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Robert Spangler wrote on Tue, 25 Mar 2008 20:33:02 -0400:
Is an option but a waste of time as a scanner will find the port it was moved to.
It's not a waste. Port scanning takes time, so, in general, those brute-force bots just try port 22. Only if someone really wants to hack you and especially you they will go any further. I changed the port on one of my machines because I had to provide SSH access from other nets as well. I have to admit I also reduced accessibility to a few hundredthousand IP numbers from two big providers. Since then (years ago) I haven't seen any brute-force attacks.
The idea of only allowing for strict ip address is good but what if you are on the move?
If you have a static IP address, this is not a problem. You VPN into your home LAN and from there to the restricted machine.
Kai
On Wednesday 26 March 2008 07:31, Kai Schaetzl wrote:
The idea of only allowing for strict ip address is good but what if you are on the move?
If you have a static IP address, this is not a problem. You VPN into your home LAN and from there to the restricted machine.
If you are going to use VPN then why not setup your remote site to use VPN and bypass SSH altogether then?
We could go on for day here with the arguments and counter-arguments. The point is everyone is going to do what they find best for them. What works for one might not for another.
Bottom line is if you want to be secure don't use passwords for login. If you must then make them as hard to crack as possible. The problem with this is people will tend to write them down if they are too hard to remember.
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 once
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.
Kai
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.
John R Pierce wrote:
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.
Just a virus you think? They are some pretty lame account names: judy, frank, bob..However they are mixed with general linux accounts: root, ftp, webmaster, mysql, named, etc. I feel less worried about that (or should I)?
Or are you just trying to lull me into a false sense of security? Muawhahahaha..
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@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.
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@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@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
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.
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?
Tim Alberts wrote:
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.
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?
Why? What is on that site which is very specific to the setup?
Rudi Ahlers wrote:
Tim Alberts wrote:
... 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?
Why? What is on that site which is very specific to the setup?
he's referring to YOUR controlling webpage, which they refer to as my-sshd-access.php there.
John R Pierce wrote:
Rudi Ahlers wrote:
Tim Alberts wrote:
... 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?
Why? What is on that site which is very specific to the setup?
he's referring to YOUR controlling webpage, which they refer to as my-sshd-access.php there.
aah ok. But that's something he should either not use if necessary, or rather secure with a .htaccess password.
on 3-25-2008 11:46 AM Rudi Ahlers spake the following:
John R Pierce wrote:
Rudi Ahlers wrote:
Tim Alberts wrote:
... 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?
Why? What is on that site which is very specific to the setup?
he's referring to YOUR controlling webpage, which they refer to as my-sshd-access.php there.
aah ok. But that's something he should either not use if necessary, or rather secure with a .htaccess password.
Or just hide it and not name it "my-sshd-access.php". It is difficult to find a web page you don't know exists if directory listing is off.
Scott Silva wrote:
Or just hide it and not name it "my-sshd-access.php". It is difficult to find a web page you don't know exists if directory listing is off.
if you post your weblogs online, perhaps via an analysis package such as Analog, DO be sure to exclude this file :)
I often create a hidden folder on my websites, named .secret or something, and have any logging of activity in that folder directed to a different private and secure log
on 3-25-2008 11:28 AM Tim Alberts spake the following:
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.
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?
Not really. Anyone who finds that page is only allowed to try and "access" ssh port. You still need valid key/password and proper knowledge of the port.
On Tue, Mar 25, 2008 at 11:28:45AM -0700, Tim Alberts wrote:
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?
Strictly speaking, yes; however in practice, the number of bots (or, indeed, external users who are not me) who the magic web page to hit (my actual page is not named as the example on the web page is!) before attacking the ssh connection is zero; therefore since the goal was to prevent stupid robots from brute-forcing my ssh and filling my logs, it isn't necessary.
I mean, strictly speaking you'd next have to insist on a proper SSL connection to the web server, otherwise you are at risk of someone sniffing the username and password used in the .htaccess process. And then after that, you'd have to insist on some kind of security on the remote system to ensure that your passwords are not being captured. Etc, etc.
Tony Placilla bofh@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@msiscales.com,
Tim Alberts talberts@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@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?
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?
On Wednesday 26 March 2008, Tim Alberts wrote:
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?
Yes, see /etc/security/access.conf (it's well commented).
/Peter
Hey first of all you need to disables root login. This is done by editing the etc/ssh/sshd_config file Uncominting the PermitRootLogin no or changing the yes to no. After that you could change the port but that would give some difficulties for the users
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Peter Kjellstrom Sent: 27. marts 2008 09:20 To: centos@centos.org Subject: Re: [CentOS] Securing SSH
On Wednesday 26 March 2008, Tim Alberts wrote:
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?
Yes, see /etc/security/access.conf (it's well commented).
/Peter
And also try to pay a little with AllowUsers user1 user2 user3 There might be a AllowGroup ??
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Jes Struck Sent: 27. marts 2008 14:03 To: 'CentOS mailing list' Subject: RE: [CentOS] Securing SSH
Hey first of all you need to disables root login. This is done by editing the etc/ssh/sshd_config file Uncominting the PermitRootLogin no or changing the yes to no. After that you could change the port but that would give some difficulties for the users
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Peter Kjellstrom Sent: 27. marts 2008 09:20 To: centos@centos.org Subject: Re: [CentOS] Securing SSH
On Wednesday 26 March 2008, Tim Alberts wrote:
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?
Yes, see /etc/security/access.conf (it's well commented).
/Peter
_______________________________________________ CentOS mailing list CentOS@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?
- 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@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
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?
The Wiki has an article here on just this:
Ned Slider wrote:
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?
The Wiki has an article here on just this:
I've been experimenting with the iptables filtering with the recent module, but I have not yet had success. I do have my default policy to reject with icmp and I've read the note that the default should be DROP. Is this the problem?
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?
I use denyhosts
CentOS List wrote:
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?
I use denyhosts
Thank you. I saw several posts (thanks again everyone) on different programs to use. failt2ban denyhosts etc. I figure if I already have the tools with iptables, why install more programs.
Tim Alberts wrote:
Ned Slider wrote:
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?
The Wiki has an article here on just this:
I've been experimenting with the iptables filtering with the recent module, but I have not yet had success. I do have my default policy to reject with icmp and I've read the note that the default should be DROP. Is this the problem?
If you just need access from home, I would just open the ssh port to your home IP address. If this isn't possible because you don't have a static IP at home, maybe moving to a non-standard port and/or configuring public/private keys (and disabling password authentication) would be sufficient. IPTables isn't the only way to crack this particular nut.
On Tue, Apr 15, 2008 at 10:29:16AM -0700, Tim Alberts wrote:
Ned Slider wrote:
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?
The Wiki has an article here on just this:
I've been experimenting with the iptables filtering with the recent module, but I have not yet had success. I do have my default policy to reject with icmp and I've read the note that the default should be DROP. Is this the problem?
I use the following iptables rules to halt the hammering:
/sbin/iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 3 -j DROP /sbin/iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set
note wrapping of commands.
Chip
-
Anne Wilson -
Carlos Daniel Ruvalcaba Valenzuela -
CentOS List -
Chris 'Chipper' Chiapusio -
Daniel Andrzejewski -
David Mackintosh -
Ingemar Nilsson -
Jacques B. -
James A. Peltier -
Jes Struck -
John R Pierce -
Kai Schaetzl -
Liam Kirsher -
Matt Shields -
Mike Kercher -
Morten Nilsen -
mouss -
Ned Slider -
Ned Slider -
Peter Kjellstrom -
Ray Leventhal -
Ray Van Dolson -
Robert Spangler -
Rudi Ahlers -
Scott Silva -
Theo Band [GreenPeak] -
Tim Alberts -
Tony Placilla -
Trey Sizemore