I've been reading up, and talking up, various security strategies. One thing that is striking to me in looking at logs for my servers are the endless ssh probes that go on. It appears to be one of the most common. Up till recently, I had dealt with this by using firewall rules to allow ssh access only to selected ip addresses - to all others, the port appears closed (I checked this with port scans). Now, I must change strategies. I need to give access to an associate who gets his dsl ip address via dhcp, so it's always changing. I'm not quite ready to try port knocking, so, the other suggestion I read over and over is to provide ssh on a non-standard port. So, I throw this out to the collective experience - what's your take on that strategy? Won't simple scans reveal the existence of ssh access on a non-standard port? Is this really much protection? Is it merely a question of reducing odds?
On 11/19/05, Claude Jones claude_jones@levitjames.com wrote:
I've been reading up, and talking up, various security strategies. One thing that is striking to me in looking at logs for my servers are the endless ssh probes that go on. It appears to be one of the most common. Up till recently, I had dealt with this by using firewall rules to allow ssh access only to selected ip addresses - to all others, the port appears closed (I checked this with port scans). Now, I must change strategies. I need to give access to an associate who gets his dsl ip address via dhcp, so it's always changing. I'm not quite ready to try port knocking, so, the other suggestion I read over and over is to provide ssh on a non-standard port. So, I throw this out to the collective experience - what's your take on that strategy? Won't simple scans reveal the existence of ssh access on a non-standard port? Is this really much protection? Is it merely a question of reducing odds?
1. Most of these are done by script kiddies. They get a script and run it is tries to connect via standard port 22.
2 Defense in depth.
A. Non-standard port. B. Only allow users that require login via ssh which should never be root. C. Require key login no passwords. D. use sudo and sudrestrictions to prevent loading a shell as root.
-- Leonard Isham, CISSP Ostendo non ostento.
- Most of these are done by script kiddies. They get a script and
run it is tries to connect via standard port 22.
2 Defense in depth.
A. Non-standard port. B. Only allow users that require login via ssh which should never be root. C. Require key login no passwords. D. use sudo and sudrestrictions to prevent loading a shell as root.
I changed the port to 6000, restart sshd /etc/init/sshd restart and login via new port 6000 sucessfully. But it takes a longer time to process a command.
eg. default port 22 ps aux takes 2 sec
on port 6000 ps aux takes 45 sec.
What happened?
regards
Hey,
I've been reading up, and talking up, various security strategies. One thing that is striking to me in looking at logs for my servers are the endless ssh probes that go on. It appears to be one of the most common. Up till recently, I had dealt with this by using firewall rules to allow ssh access only to selected ip addresses - to all others, the port appears closed (I checked this with port scans). Now, I must change strategies. I need to give access to an associate who gets his dsl ip address via dhcp, so it's always changing. I'm not quite ready to try port knocking, so, the other suggestion I read over and over is to provide ssh on a non-standard port. So, I throw this out to the collective experience - what's your take on that strategy? Won't simple scans reveal the existence of ssh access on a non-standard port? Is this really much protection? Is it merely a question of reducing odds?
Here I use a combination of strategies: - Run SSHD on a non-standard port - Do not allow Root Logins PermitRootLogins no - Use AllowUsers to restrict which user can login AllowUser user1 user2 user3@host.something.com - Use strong passwords - Use a program to ask something to the user who logs in.
Yes, a simple scan will reveal that you're running ssh on a non-standard port, but you'll not be knocked by the automated bot scans who use the default ssh port. These bot scans are responsible for about to 99% of those attempts you're seeing. After those changes I see no attempts on my logs anymore.
-- Regards, Alejandro Flores http://www.triforsec.com.br/
On Sat November 19 2005 8:07 am, Alejandro Flores wrote:
Hey,
I've been reading up, and talking up, various security strategies. One thing that is striking to me in looking at logs for my servers are the endless ssh probes that go on. It appears to be one of the most common. Up till recently, I had dealt with this by using firewall rules to allow ssh access only to selected ip addresses - to all others, the port appears closed (I checked this with port scans). Now, I must change strategies. I need to give access to an associate who gets his dsl ip address via dhcp, so it's always changing. I'm not quite ready to try port knocking, so, the other suggestion I read over and over is to provide ssh on a non-standard port. So, I throw this out to the collective experience - what's your take on that strategy? Won't simple scans reveal the existence of ssh access on a non-standard port? Is this really much protection? Is it merely a question of reducing odds?
Here I use a combination of strategies:
- Run SSHD on a non-standard port
- Do not allow Root Logins
PermitRootLogins no
- Use AllowUsers to restrict which user can login
AllowUser user1 user2 user3@host.something.com
- Use strong passwords
- Use a program to ask something to the user who logs in.
Yes, a simple scan will reveal that you're running ssh on a non-standard port, but you'll not be knocked by the automated bot scans who use the default ssh port. These bot scans are responsible for about to 99% of those attempts you're seeing. After those changes I see no attempts on my logs anymore.
You and Leonard are confirming some things I've concluded, but, it reminds me of a second question I haven't really found an answer to. What port? Is it best to choose a high port, or pick one in the below 1024 range?
On 11/19/05, Claude Jones claude_jones@levitjames.com wrote:
On Sat November 19 2005 8:07 am, Alejandro Flores wrote:
Hey,
I've been reading up, and talking up, various security strategies. One thing that is striking to me in looking at logs for my servers are the endless ssh probes that go on. It appears to be one of the most common. Up till recently, I had dealt with this by using firewall rules to allow ssh access only to selected ip addresses - to all others, the port appears closed (I checked this with port scans). Now, I must change strategies. I need to give access to an associate who gets his dsl ip address via dhcp, so it's always changing. I'm not quite ready to try port knocking, so, the other suggestion I read over and over is to provide ssh on a non-standard port. So, I throw this out to the collective experience - what's your take on that strategy? Won't simple scans reveal the existence of ssh access on a non-standard port? Is this really much protection? Is it merely a question of reducing odds?
Here I use a combination of strategies:
- Run SSHD on a non-standard port
- Do not allow Root Logins
PermitRootLogins no
- Use AllowUsers to restrict which user can login
AllowUser user1 user2 user3@host.something.com
- Use strong passwords
- Use a program to ask something to the user who logs in.
Yes, a simple scan will reveal that you're running ssh on a non-standard port, but you'll not be knocked by the automated bot scans who use the default ssh port. These bot scans are responsible for about to 99% of those attempts you're seeing. After those changes I see no attempts on my logs anymore.
You and Leonard are confirming some things I've concluded, but, it reminds me of a second question I haven't really found an answer to. What port? Is it best to choose a high port, or pick one in the below 1024 range?
Most I have seen choose above 1024. I personally avoid any that I know are defaults for other security systems including the firwall specific distros.
-- Leonard Isham, CISSP Ostendo non ostento.
Claude Jones wrote:
You and Leonard are confirming some things I've concluded, but, it reminds me of a second question I haven't really found an answer to. What port? Is it best to choose a high port, or pick one in the below 1024 range?
*Probably* choosing a high port. There are enough services running in the low IP range that it's worth scanning them. Once the SSH daemon has been scanned, an attacker will know that port is open, and a simple telnet connection will tell a potential attacker that it's a SSH daemon.
It takes long enough to scan the entire IP range that it's significantly less common. So you're somewhat less likely to be scanned.
James.
On 11/19/05, Alejandro Flores alejandrorflores@gmail.com wrote: [snip]
Here I use a combination of strategies:
- Run SSHD on a non-standard port
- Do not allow Root Logins
PermitRootLogins no
- Use AllowUsers to restrict which user can login
AllowUser user1 user2 user3@host.something.com
- Use strong passwords
- Use a program to ask something to the user who logs in.
What program do you use to ask the user somethnig? Are there any other programs for this?
-- Leonard Isham, CISSP Ostendo non ostento.
Hello,
What program do you use to ask the user somethnig? Are there any other programs for this?
I have built my own. It can be a simple program who ask "What's the birthday of my dog?" to a clock based key. The main purpose behind this program is to not drop the user to a shell prompt at first. What happens when a user logs in? Shell prompt. How do you know if the user who logs in is not a result of an automated attack? I mean, a result of a sucessfull brute force attack or easy guessable password? That's the idea.
-- Regards, Alejandro Flores http://www.triforsec.com.br/
At 10:07 AM -0300 11/19/05, Alejandro Flores wrote: ...
- Use a program to ask something to the user who logs in.
I don't know much about ssh. Does "ssh <hostname> <command>" bypass this program? Say "ssh your@host /bin/bash"? ____________________________________________________________________ TonyN.:' mailto:tonynelson@georgeanelson.com ' http://www.georgeanelson.com/
At 7:47 AM -0500 11/19/05, Claude Jones wrote:
I've been reading up, and talking up, various security strategies. One thing that is striking to me in looking at logs for my servers are the endless ssh probes that go on. It appears to be one of the most common. Up till recently, I had dealt with this by using firewall rules to allow ssh access only to selected ip addresses - to all others, the port appears closed (I checked this with port scans). Now, I must change strategies. I need to give access to an associate who gets his dsl ip address via dhcp, so it's always changing. I'm not quite ready to try port knocking, so, the other suggestion I read over and over is to provide ssh on a non-standard port. So, I throw this out to the collective experience - what's your take on that strategy? Won't simple scans reveal the existence of ssh access on a non-standard port? Is this really much protection? Is it merely a question of reducing odds?
Disclaimer: I haven't set up SSH myself; this is from reading this list, reading the ssh man page, and general knowledge.
Port obscurity is not much of a strategy. Maybe the current scripts don't try other ports, but it would be simple enough to add a port scan and then probe all open ports. Expect it.
I suggest one of the secure ways to set up SSH: public key pair or encrypted passwords. And only allow SSH 2. Public key should be simple /enough/ to set up; your user would need to make a key with GPG and put the private key in the right place (I think man ssh tells where) and give you the public key to put in the right place.
With strong authentication, you don't need to care about probes anymore. Just ignore them. ____________________________________________________________________ TonyN.:' mailto:tonynelson@georgeanelson.com ' http://www.georgeanelson.com/
Tony Nelson tonynelson@georgeanelson.com writes:
I suggest one of the secure ways to set up SSH: public key pair or encrypted passwords. And only allow SSH 2. Public key should be simple /enough/ to set up; your user would need to make a key with GPG and put the private key in the right place (I think man ssh tells where) and give you the public key to put in the right place.
Just to save folks a bit of time, I wrote up a cheat sheet a while ago for technical folks that weren't really hard-core computer nerds and were struggling with sshd.
http://www.wsrcc.com/wolfgang/sshd-config.html
With strong authentication, you don't need to care about probes anymore. Just ignore them.
Yup. Setting up real public-key authentication is several hundred orders of magnitude stronger against guessing attacks than changing the ssh portnumbers or adding bad hosts into some IP level filter table and hoping the attackers won't guess a good password before they run out of IP addresses to test from.
(And yes, I did really mean hundreds of orders of magnitude. An attacker has 1 chance in 10**308 of guessing the 1024-bit public key on each try if they follow the same brute-force attack. Given a billion tests per second and the whole age of universe up to this time, we are still only talking a 1 in 10**281 chance.)
-wolfgang
On 11/21/05, Wolfgang S. Rupprecht >
Yup. Setting up real public-key authentication is several hundred orders of magnitude stronger against guessing attacks than changing the ssh portnumbers or adding bad hosts into some IP level filter table and hoping the attackers won't guess a good password before they run out of IP addresses to test from.
(And yes, I did really mean hundreds of orders of magnitude. An attacker has 1 chance in 10**308 of guessing the 1024-bit public key on each try if they follow the same brute-force attack. Given a billion tests per second and the whole age of universe up to this time, we are still only talking a 1 in 10**281 chance.)
Even harder, if there's a password on that key. The other part of this discussion, I thought, was the DoS-ability of these ssh attacks. That is, do these ssh attacks prevent legitmate users from accessing regardless of the authentication mechanism configured for sshd?
-- Jiann-Ming Su "I have to decide between two equally frightening options. If I wanted to do that, I'd vote." --Duckman "The system's broke, Hank. The election baby has peed in the bath water. You got to throw 'em both out." --Dale Gribble
Jiann-Ming Su sujiannming@gmail.com writes:
Even harder, if there's a password on that key.
Not that it really matters when we are talking about numbers so insanely large, but just for completeness and 'cause I think ssh is an interesting and useful program...
The password on the key only protects the private-key from being casually read by someone with access to the computer. The private-key-exchange that ssh puts on the wire (eg. on the 'net) has already had the password stripped from it. All that is used is the raw 1024-bit key.
As an aside, the password on the file really only prevents a casual observer from learning the private-key. An attacker that has managed to grab the password-protected private-key file (by having broken into the system that has the private key file) can attack the password by dictionary and guessing attacks. This password protection is no stronger than would have been had had we used the same password as a unix-type password login. In fact, since they have the file on their own computer(s) they can subject it to much faster, more intensive guessing attacks.
My feeling is that you can't ever really be sure that a private-key file hasn't been compromised. It is best to generate a fresh private-key public key pair every once in a while. (say 3-12 mos.) One can even keep the same password protecting the file, the important thing is that the underlying 1024-bit key is changed.
The other part of this discussion, I thought, was the DoS-ability of these ssh attacks. That is, do these ssh attacks prevent legitmate users from accessing regardless of the authentication mechanism configured for sshd?
The DOS aspect is a problem. The initial key public-key exchange is very CPU intensive. Someone banging on a box with password guessing attacks will chew up quite a bit of CPU and life on the box won't be very pleasant.
What I did here for a while was run what amounts to a simple shell script that grabbed the IP's of the attacking machines and stuffed them into an IP-level filter against all traffic from that machine. This still allowed the attacker to have 5-10 seconds of fun, but life got really boring for them after that.
-wolfgang
On 11/21/05, Wolfgang S. Rupprecht wolfgang+gnus200511@dailyplanet.dontspam.wsrcc.com wrote:
The password on the key only protects the private-key from being casually read by someone with access to the computer. The private-key-exchange that ssh puts on the wire (eg. on the 'net) has already had the password stripped from it. All that is used is the raw 1024-bit key.
As an aside, the password on the file really only prevents a casual observer from learning the private-key. An attacker that has managed to grab the password-protected private-key file (by having broken into the system that has the private key file) can attack the password by dictionary and guessing attacks. This password protection is no stronger than would have been had had we used the same password as a unix-type password login. In fact, since they have the file on their own computer(s) they can subject it to much faster, more intensive guessing attacks.
I guess my point is it's another step. Without the public key, they just brute force dictionary guess. With public key, they have to obtain the private key. Hopefully, this is hard. But, I see your point. If getting to the private key is easy, then the password protecting is just for show.
My feeling is that you can't ever really be sure that a private-key file hasn't been compromised. It is best to generate a fresh private-key public key pair every once in a while. (say 3-12 mos.) One can even keep the same password protecting the file, the important thing is that the underlying 1024-bit key is changed.
Hmm... that sounds like a good idea.
What I did here for a while was run what amounts to a simple shell script that grabbed the IP's of the attacking machines and stuffed them into an IP-level filter against all traffic from that machine. This still allowed the attacker to have 5-10 seconds of fun, but life got really boring for them after that.
That sounds like what the "recent" module in iptables does.
-- Jiann-Ming Su "I have to decide between two equally frightening options. If I wanted to do that, I'd vote." --Duckman "The system's broke, Hank. The election baby has peed in the bath water. You got to throw 'em both out." --Dale Gribble
What I did here for a while was run what amounts to a simple shell script that grabbed the IP's of the attacking machines and stuffed them into an IP-level filter against all traffic from that machine. This still allowed the attacker to have 5-10 seconds of fun, but life got really boring for them after that.
-wolfgang
I found an idea that uses the recent module of iptables. Was easy to write and works really well. The first connection gets through but fails because of the public/private key setup and the second connection is dropped. I know that it uses some cpu time and that isn't a consideration on my machine with only one user but after two tries they go away. Before I put the chains into iptables they would attack for as much as an hour or more. I would guess that would use more cpu over time.
Wolf: Thanks again for the instructions on the p/p key setup.
"Knute Johnson" knute@frazmtn.com writes:
I found an idea that uses the recent module of iptables. Was easy to write and works really well. The first connection gets through but fails because of the public/private key setup and the second connection is dropped.
That sounds like its much better than what I'm doing.
My first homebrew hack started out using 'tail -f' which wasted a little time every second. It's not much cpu, but it is embarrassingly hack-ish. (The second version used a perl module that did a variable length poll on the log file. In theory that lowered the CPU usage a bit but was still that same embarrassing hack.) I'm glad to see someone did a proper interface to iptables.
Wolf: Thanks again for the instructions on the p/p key setup.
It was my pleasure!
When I first tried to configure sshd I was fairly worried that I was misunderstanding something and feared that I had opened my system for wide scale intrusions. Sshd has way too many switches and using some of them pretty much negates any security ssh might have offered.
-wolfgang
On Tuesday 22 November 2005 2:14 am, Knute Johnson wrote:
What I did here for a while was run what amounts to a simple shell script that grabbed the IP's of the attacking machines and stuffed them into an IP-level filter against all traffic from that machine. This still allowed the attacker to have 5-10 seconds of fun, but life got really boring for them after that.
-wolfgang
I found an idea that uses the recent module of iptables. Was easy to write and works really well. The first connection gets through but fails because of the public/private key setup and the second connection is dropped. I know that it uses some cpu time and that isn't a consideration on my machine with only one user but after two tries they go away. Before I put the chains into iptables they would attack for as much as an hour or more. I would guess that would use more cpu over time.
Wolf: Thanks again for the instructions on the p/p key setup.
-- Knute Johnson Molon Labe...
A while back there was discussion on the list about a script that monitored /var/messages and /var/secure and would write a rule to block an IP address after "x" number of attempts to log in. I could not find the reference that I kept. You might try searching the list but the scripts were very good.
"j" == jludwig wralphie@comcast.net writes:
j> A while back there was discussion on the list about a script that j> monitored /var/messages and /var/secure and would write a rule to j> block an IP address after "x" number of attempts to log in.
DenyHosts: http://denyhosts.sf.net
It's in extras, so if you have the extras repository set up, you can do "yum install denyhosts".
- J<
On Tuesday 22 November 2005 2:52 pm, Jason L Tibbitts III wrote:
"j" == jludwig wralphie@comcast.net writes:
j> A while back there was discussion on the list about a script that j> monitored /var/messages and /var/secure and would write a rule to j> block an IP address after "x" number of attempts to log in.
DenyHosts: http://denyhosts.sf.net
It's in extras, so if you have the extras repository set up, you can do "yum install denyhosts".
- J<
Thanks
--snip--
-- Knute Johnson Molon Labe...
A while back there was discussion on the list about a script that monitored /var/messages and /var/secure and would write a rule to block an IP address after "x" number of attempts to log in. I could not find the reference that I kept. You might try searching the list but the scripts were very good.
Try this
http://denyhosts.sourceforge.net/
or for quick & dirty:
iptables -A INPUT -i eth0 -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -m recent --set --name sshscans --rsource
iptables -A INPUT -m recent --rcheck --seconds 60 --hitcount 10 --name sshscans --rsource -j DROP
(thanks to david@blue-labs.org for that one)
On Sat, Nov 19, 2005 at 10:41:52AM -0500, Tony Nelson wrote:
Port obscurity is not much of a strategy. Maybe the current scripts don't try other ports, but it would be simple enough to add a port scan and then probe all open ports. Expect it.
The only "advantage" I see to a different port is a slightly reduced performance impact from brute force attempts, and cleaner incidence logs.
I suggest one of the secure ways to set up SSH: public key pair or encrypted passwords. And only allow SSH 2. Public key should be simple /enough/ to set up; your user would need to make a key with GPG and put the private key in the right place (I think man ssh tells where) and give you the public key to put in the right place.
Someone mentioned to me in passing the other day, that you can have sshd require both a key, and password authentication. Which sounds kind of neat, because then you don't have to trust that the user has a password on their key. :)
Cheers, -danny
On Saturday 19 November 2005 06:47, Claude Jones wrote:
Won't simple scans reveal the existence of ssh access on a non-standard port?
Yes.
Is this really much protection? Is it merely a question of reducing odds?
Yes. It'll stop those who use automated scripts that aren't flexible enough to scan for alternative ports.
I need to give access to an associate who gets his dsl ip address via dhcp, so it's always changing.
Do you know what "always changing" means in this context? I too have a few people that log in via an address assigned via dhcp but in practice their address doesn't change but once or twice a year. If this is true in your case a simple exchange of emails to let you know to change the firewall rule for the new address may be the most secure method you're considering.
Regards, Mike Klinke
On 11/19/05, Claude Jones claude_jones@levitjames.com wrote:
I've been reading up, and talking up, various security strategies. One thing that is striking to me in looking at logs for my servers are the endless ssh probes that go on. It appears to be one of the most common. Up till recently, I had dealt with this by using firewall rules to allow ssh access only to selected ip addresses - to all others, the port appears closed (I checked this with port scans). Now, I must change strategies. I need to give access to an associate who gets his dsl ip address via dhcp, so it's always changing. I'm not quite ready to try port knocking, so, the other suggestion I read over and over is to provide ssh on a non-standard port. So, I throw this out to the collective experience - what's your take on that strategy? Won't simple scans reveal the existence of ssh access on a non-standard port? Is this really much protection? Is it merely a question of reducing odds?
http://developedtraffic.com/2005/06/19/server-ssh-login-attempt-throttle/
Be advised that there are some bugs associated with iptable's "recent" module. You should research these bugs before implementing.
-- Jiann-Ming Su "I have to decide between two equally frightening options. If I wanted to do that, I'd vote." --Duckman "The system's broke, Hank. The election baby has peed in the bath water. You got to throw 'em both out." --Dale Gribble
On Sat, Nov 19, 2005 at 07:47:11AM -0500, Claude Jones wrote:
I'm not quite ready to try port knocking, so, the other suggestion I read over and over is to provide ssh on a non-standard port. So, I throw this out to the collective experience - what's your take on that strategy?
First, I must admit that I use this technique myself. But to be honest, other than preventing log bloat, I think there's very little benefit to doing it.
Won't simple scans reveal the existence of ssh access on a non-standard port?
Yes, and no. It depends what you mean. A "simple" port scan will reveal that *something* is listening on the new port, but will not necessarily reveal that it is an ssh daemon. A more sophisticated scan, which tries to make connections for well known protocols, will certainly identify this.
Is this really much protection?
I don't really think so, provided you take other precautions to safeguard your system, namely:
- first and foremost, keep your ssh software up-to-date with the latest available for your distribution. If you're running an older distribution that is no longer supported (or find yourself in this situation in the future), I would strongly urge you to upgrade.
- DO NOT allow passwords of any kind. Use cryptographic keys with the SSH2 protocol.
- THOROUGHLY read the man pages for sshd, sshd_config, and ssh. Understand the software well. Make use of the many other access controls as you see fit.
Is it merely a question of reducing odds?
Yes. But with regard to computer security, that's all you ever can do, really. However, some precautions are a lot more valuable than others. As others have said, changing the port will protect you from script kiddies, but then so will keeping your software updated.
The only real downside of changing the port is that the user has to remember to specify the port all the time, and the command line options for each of the ssh clients (ssh, sftp, scp) all have different options for doing this. If you don't consider that a big deal, then go ahead and do it. But honestly, I think the only real benefit this provides over keeping your system updated is less garbage in your logs... which may be reason enough to do it.
on 11/19/2005 07:47 AM Claude Jones wrote:
I've been reading up, and talking up, various security strategies. One thing that is striking to me in looking at logs for my servers are the endless ssh probes that go on. It appears to be one of the most common. Up till recently,
http://denyhosts.sourceforge.net/
<quote> DenyHosts is a script intended to be run by Linux system administrators to help thwart ssh server attacks.
If you've ever looked at your ssh log (/var/log/secure on Redhat, /var/log/auth.log on Mandrake, etc...) you may be alarmed to see how many hackers attempted to gain access to your server. Hopefully, none of them were successful (but then again, how would you know?). Wouldn't it be better to automatically prevent that attacker from continuing to gain entry into your system? </quote>
I'm using it for couple months. Simple installation, couple minutes for modification of config file and it works like a charm.
oleksandr korneta wrote:
on 11/19/2005 07:47 AM Claude Jones wrote:
I've been reading up, and talking up, various security strategies. One thing that is striking to me in looking at logs for my servers are the endless ssh probes that go on. It appears to be one of the most common. Up till recently,
http://denyhosts.sourceforge.net/
<quote> DenyHosts is a script intended to be run by Linux system administrators to help thwart ssh server attacks.
DenyHosts and pam_abl is in Fedora Extras.
http://fedoraproject.org/wiki/Extras
regards Rahul
oleksandr korneta wrote:
on 11/19/2005 07:47 AM Claude Jones wrote:
I've been reading up, and talking up, various security strategies. One thing that is striking to me in looking at logs for my servers are the endless ssh probes that go on. It appears to be one of the most common. Up till recently,
http://denyhosts.sourceforge.net/
<quote> DenyHosts is a script intended to be run by Linux system administrators to help thwart ssh server attacks.
If you've ever looked at your ssh log (/var/log/secure on Redhat, /var/log/auth.log on Mandrake, etc...) you may be alarmed to see how many hackers attempted to gain access to your server. Hopefully, none of them were successful (but then again, how would you know?). Wouldn't it be better to automatically prevent that attacker from continuing to gain entry into your system?
</quote>
I'm using it for couple months. Simple installation, couple minutes for modification of config file and it works like a charm.
I was just running through the responses to this thread to see if anyone had suggested this application.
Granted it is a defense which is somewhat "after the fact" but it does and has blocked quite a number of onslaughts on servers i maintain - having noted almost 200 attacks on one particular server since installation a couple of months ago.
I too am interested in finding other ways to protect rather than defend.
Trevor "TeC" Christian wrote:
I too am interested in finding other ways to protect rather than defend.
I changed from the standard port 22 to another one. Haven't been attacked since and that was many months ago.
Just choose any port. Be sure to change the config file for your clients, too. Or, just do:
ssh -p XXX
where XXX is the new port when you connect.
Take care,
Kurt Hansen khansen@charityweb.net
On Mon, 2005-11-21 at 18:40 -0400, Trevor "TeC" Christian wrote:
oleksandr korneta wrote:
on 11/19/2005 07:47 AM Claude Jones wrote:
I've been reading up, and talking up, various security strategies. One thing that is striking to me in looking at logs for my servers are the endless ssh probes that go on. It appears to be one of the most common. Up till recently,
I am running DenyHosts on my (Centos) server. It does seem to cause some problems changing security context on /etc/hosts.deny though. I am not sure whether it exhibits the same problem on Fedora, but you better monitor it for some time....
Louis
On Tuesday 22 November 2005 4:00 pm, Louis Lagendijk wrote:
I am running DenyHosts on my (Centos) server. It does seem to cause some problems changing security context on /etc/hosts.deny though. I am not sure whether it exhibits the same problem on Fedora, but you better monitor it for some time....
Could you give a little more detail. What problems regarding what security contexts? I started this whole thread, and today I just installed denyhosts as a first step in implementing some of the suggestions. It immediately picked up some hosts from the logs that tried to break in yesterday, and added them to denyhosts. I also happen to run a Centos server, so I'm doubly curious about your issues.
On Tue, 2005-11-22 at 16:05 -0500, Claude Jones wrote:
On Tuesday 22 November 2005 4:00 pm, Louis Lagendijk wrote:
I am running DenyHosts on my (Centos) server. It does seem to cause some problems changing security context on /etc/hosts.deny though. I am not sure whether it exhibits the same problem on Fedora, but you better monitor it for some time....
Could you give a little more detail. What problems regarding what security contexts? I started this whole thread, and today I just installed denyhosts as a first step in implementing some of the suggestions. It immediately picked up some hosts from the logs that tried to break in yesterday, and added them to denyhosts. I also happen to run a Centos server, so I'm doubly curious about your issues.
My apologies for the late reply: I had to wait for the problem to re-appear. The issue appears to be that DenyHost (run as deamon) appear to change the context for /etc/hosts.deny to:
-rw-r--r-- root root user_u:object_r:etc_t /etc/hosts -rw-r--r-- root root system_u:object_r:etc_t /etc/hosts.allow -rw-rw-rw- root root root:object_r:etc_runtime_t /etc/hosts.deny -rw-rw-rw- root root root:object_r:etc_t /etc/hosts.deny.purge.bak
I have for now solved that with a local policy of:
allow portmap_t etc_runtime_t:file read;
probably not the best solution, but I am not (yet) versed well enough in selinux to solve the issue otherwise
-- Claude Jones Bluemont, VA, USA
"LL" == Louis Lagendijk louis@lagendijk.xs4all.nl writes:
LL> It does seem to cause some problems changing security context on LL> /etc/hosts.deny though.
If you can, please open a bug at http://bugzilla.redhat.com (product "Fedora Extras", component "denyhosts") with as much detail as you can so that I can take it up with the upstream developer. (Or report it to them directly.)
It would be a great help if you could detail in what way the security context changed. On an FC3 host DenyHosts seems to leave /etc/hosts.deny as system_u:object_r:etc_t, which is also the default context on a Centos 4.2 machine. What did yours get changed to?
- J<
-
Alejandro Flores -
Claude Jones -
Danny Howard -
Derek Martin -
James Wilkinson -
Jason L Tibbitts III -
Jiann-Ming Su -
jludwig -
Knute Johnson -
Kurt Hansen -
LC -
Leonard Isham -
Louis Lagendijk -
Mike Klinke -
oleksandr korneta -
Rahul Sundaram -
Tony Nelson -
Tony Placilla -
Trevor "TeC" Christian -
Wolfgang S. Rupprecht