6:47 a.m.
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?
--
Claude Jones
Bluemont, VA, USA
6:56 a.m.
On 11/19/05, Claude Jones <claude_jones(a)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.
7:57 p.m.
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.
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
7:07 a.m.
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(a)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/
7:16 a.m.
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(a)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?
--
Claude Jones
Bluemont, VA, USA
7:21 a.m.
On 11/19/05, Claude Jones <claude_jones(a)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(a)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.
3:12 p.m.
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.
--
E-mail address: james | You know you've been computing too long when you see a
@westexe.demon.co.uk | BBC News headline "MS damage repair mechanism found",
| and wonder why that's news. Then you wonder why it's
| listed under Health...
7:19 a.m.
On 11/19/05, Alejandro Flores <alejandrorflores(a)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(a)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.
7:46 a.m.
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/
9:41 a.m.
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/>
9:41 a.m.
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/>
12:41 a.m.
Tony Nelson <tonynelson(a)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
--
Wolfgang S. Rupprecht http://www.wsrcc.com/wolfgang/
10:58 a.m.
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
4:05 p.m.
Jiann-Ming Su <sujiannming(a)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
--
Wolfgang S. Rupprecht http://www.wsrcc.com/wolfgang/
5:47 p.m.
On 11/21/05, Wolfgang S. Rupprecht
<wolfgang+gnus200511(a)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
8:14 p.m.
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...
10:21 p.m.
"Knute Johnson" <knute(a)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
--
Wolfgang S. Rupprecht http://www.wsrcc.com/wolfgang/
10:30 p.m.
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.
8:52 a.m.
>>>> "j" == jludwig
<wralphie(a)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<
4:04 p.m.
On Tuesday 22 November 2005 2:52 pm, Jason L Tibbitts III wrote:
>>>>> "j" == jludwig
<wralphie(a)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
11:03 a.m.
--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(a)blue-labs.org for that one)
--
Tony Placilla, RHCT
anthony_placilla(a)suth.com
6:16 p.m.
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
--
http://dannyman.toldme.com/
9:55 a.m.
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
10:31 a.m.
On 11/19/05, Claude Jones <claude_jones(a)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
12:35 p.m.
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.
--
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D
10:24 a.m.
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.
--
regards,
Oleksandr Korneta
10:32 a.m.
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
4:40 p.m.
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*
/TeC Productions Studios/
Cell #: (767) 225 4472
IM
MSN: trevorc98(a)hotmail.com / trevor(a)bouyon.dalive.com
YM : trevorc01(a)yahoo.com
AIM: DoubleOTeC
GoogleTalk: doubleOTeC(a)gmail.com
------------------------------------------------------------------------
Home Page <http://trevor.bouyon.dalive.com/>
Curriculum Vitae <http://bouyon.dalive.com/cv/>
Dalive Market <http://www.dalivemarket.com/>
5:36 p.m.
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(a)charityweb.net
3 p.m.
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,
>
> http://denyhosts.sourceforge.net/
>
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
3:05 p.m.
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.
--
Claude Jones
Bluemont, VA, USA
6:57 a.m.
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
--
Louis Lagendijk <louis(a)lagendijk.xs4all.nl>
6:38 p.m.
>>>> "LL" == Louis Lagendijk
<louis(a)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<
6713
days inactive
6726
days old
32 comments
20 participants
participants (20)
-
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