Re: [CentOS] Securing SSH wiki article outdated

[Ned Slider]

On 12/02/15 20:03, Warren Young wrote:
 Hi, just a quick note to whoever is maintaining this page:
 
   http://wiki.centos.org/HowTos/Network/SecuringSSH
 
 The procedure is missing the firewall-cmd calls necessary in EL7:
 
   firewall-cmd --add-port 2345/tcp
   firewall-cmd --add-port 2345/tcp --permanent
 
 Also, it may be worth mentioning that semanage is in the 
 policycoreutils-python package, which isn’t installed by default in all stock 
 configurations.


Thank you, and copying to the centos-docs list for reference.

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Securing SSH wiki article outdated

[James Hogarth]

 On 12/02/15 20:03, Warren Young wrote:
  Hi, just a quick note to whoever is maintaining this page:
 
http://wiki.centos.org/HowTos/Network/SecuringSSH
 
  The procedure is missing the firewall-cmd calls necessary in EL7:
 
firewall-cmd --add-port 2345/tcp
firewall-cmd --add-port 2345/tcp --permanent
 

This is horrible advice anyway. It's not a good idea to run SSH on a port
greater than 1024 since if a crash exploit is used to kill the process a
non-root trojan process faking SSH to gather credentials could then bind on
that port trivially totally compromising the system.

If you really want to SSH to a port other than 22 for a little obscurity
use an iptables dnat to map the high port to local host 22 and block 22
from external connections.

That way SSH is still binding to a low port restricted to the root user and
you can still get a little of that security through obscurity being desired.
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Securing SSH wiki article outdated

[Always Learning]

On Fri, 2015-02-13 at 09:46 -0500, Lamar Owen wrote:

 On 02/13/2015 09:15 AM, Chris Adams wrote:
  Yeah, the old move stuff to alternate ports thing is largely a waste 
  of time and just makes it more difficult for legitimate use. With 
  large bot networks and tools like zmap, finding services on alternate 
  ports is not that hard for the bad guys. 

 Having SSH on 22 is lower-hanging fruit than having SSH on a different 
 port.  Sure, an NBA all-star will be able to reach the apples at the top 
 of the tree easily, but most people are not NBA all-stars.  Most 
 port-scanners do not scan all possible ports.
 
 And I am fully aware that people in the 'it's a waste of time' camp are 
 unmoved by that.  It's not worth arguing about; those who move to 
 non-standard ports are going to want to do it anyway.

Lamar's comments are very sensible.

I always change the SSH port to something conspicuously different. Every
server has a different and difficult to guess SSH port number with
access restricted to a few IP addresses.

Waste of time = all the time and energy required to clean-up after a
hacker's breech when a few seconds work selecting a different port could
make a beneficial improvement to security. 

-- 
Regards,

Paul.
England, EU.  Je suis Charlie.


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Securing SSH wiki article outdated

[Chris Adams]

Once upon a time, James Hogarth james.hoga...@gmail.com said:
 If you really want to SSH to a port other than 22 for a little obscurity
 use an iptables dnat to map the high port to local host 22 and block 22
 from external connections.

Yeah, the old move stuff to alternate ports thing is largely a waste
of time and just makes it more difficult for legitimate use.  With large
bot networks and tools like zmap, finding services on alternate ports is
not that hard for the bad guys.
-- 
Chris Adams li...@cmadams.net
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Securing SSH wiki article outdated

[Lamar Owen]

On 02/13/2015 09:15 AM, Chris Adams wrote:
Yeah, the old move stuff to alternate ports thing is largely a waste 
of time and just makes it more difficult for legitimate use. With 
large bot networks and tools like zmap, finding services on alternate 
ports is not that hard for the bad guys. 


Having SSH on 22 is lower-hanging fruit than having SSH on a different 
port.  Sure, an NBA all-star will be able to reach the apples at the top 
of the tree easily, but most people are not NBA all-stars.  Most 
port-scanners do not scan all possible ports.


And I am fully aware that people in the 'it's a waste of time' camp are 
unmoved by that.  It's not worth arguing about; those who move to 
non-standard ports are going to want to do it anyway.


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Securing SSH wiki article outdated

[Lamar Owen]

On 02/13/2015 05:41 AM, James Hogarth wrote:

This is horrible advice anyway. It's not a good idea to run SSH on a port
greater than 1024 since if a crash exploit is used to kill the process a
non-root trojan process faking SSH to gather credentials could then bind on
that port trivially totally compromising the system.


This is where an SELinux policy on your server can come to your aid.  
You could set up your SELinux policy to allow binding to the desired SSH 
port by sshd alone, which would prevent the trojan process from 
rebinding it.  But I think the '2345' is just there as an example.  
Perhaps a line in the HOWTO mentioning that it is preferred to have it 
listen to a port below 1024 would be appropriate.



That way SSH is still binding to a low port restricted to the root user and
you can still get a little of that security through obscurity being desired.

I hate to break it to you, but all security is security through 
obscurity in some form or fashion.  Some forms of obscurity (such as RSA 
private keys) are just more obscure than other forms of obscurity (like 
which of a mere 65,535 ports SSH is listening to today, or what knock 
code you need for the port knocker to access port 22, or whatever).  
Brute-forcing is just a way of breaking the obscurity of a password, 
etc.  Even layered security is only as secure as the obscurity of how 
the layers interact.


One of my day job's responsibilities is as site locksmith (and reverse 
engineering rotating constant master key systems using the Edwards 
matrix system is one of my current areas of study, since the site's 
previous occupants didn't leave complete records of the dozen or so RCM 
key systems here); it is tacit knowledge in locksmithing circles that 
all security is security through obscurity (even in safes with included 
hardplate, the security is only as good as the obscurity of the 
locations of the hardplate's inclusions).  But it doesn't matter how 
randomly you pick the progressions, or whether you use TPP or limited 
progression or RCM or even spherical methods, it's still all about 
obscurity, as laid open by Matt Blaze's classic paper Rights 
Amplification in Master-Keyed Mechanical Locks (which caused a bit of a 
firestorm in certain locksmithing circles when it was published, even 
though it was a bit of an open secret anyway). Locksmiths have know for 
decades that security is not ever absolute; this is why safes are rated 
by how  long they can resist knowledgeable attack (and I'm impressed 
that any safe can resist a thermic lance for longer than 30 minutes, but 
some can); this is also why lock hardware you buy is rated on a system 
(and higher rated locks do actually cost more to make).


This is also why the Orange Book and its Rainbow kin exist (Orange Book 
= 5200.28-STD, aka DoD Trusted Computer System Evaluation Criteria).


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Securing SSH wiki article outdated

[m . roth]

Always Learning wrote:

 On Fri, 2015-02-13 at 09:46 -0500, Lamar Owen wrote:

 On 02/13/2015 09:15 AM, Chris Adams wrote:
  Yeah, the old move stuff to alternate ports thing is largely a waste
  of time and just makes it more difficult for legitimate use. With
  large bot networks and tools like zmap, finding services on alternate
  ports is not that hard for the bad guys.

 Having SSH on 22 is lower-hanging fruit than having SSH on a different
 port.  Sure, an NBA all-star will be able to reach the apples at the top
 of the tree easily, but most people are not NBA all-stars.  Most
 port-scanners do not scan all possible ports.

 And I am fully aware that people in the 'it's a waste of time' camp are
 unmoved by that.  It's not worth arguing about; those who move to
 non-standard ports are going to want to do it anyway.

 Lamar's comments are very sensible.

 I always change the SSH port to something conspicuously different. Every
 server has a different and difficult to guess SSH port number with
 access restricted to a few IP addresses.
snip
I disagree - I am in the waste of time camp. The reality is that only
script kiddies start out by trying 22 (and I *do* mean script kiddies -
I've seen attempts to ssh in that were obviously from warez, man, where
they were too stupid to fill in ___ with a username, or salt. All the
others, I figure they don't need to be major league, just someone with a
clue, who'll run a scan; in fact, I'd expect them to run a scan just to
see what IPs were visible, and I know that if I was writing a scan, I
don't assume that I'm *so* brilliant that I'm the only one to think of
scanning ports  1k while looking for systems that I might hit.

mark

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Securing SSH wiki article outdated

[Valeri Galtsev]

On Fri, February 13, 2015 9:05 am, Always Learning wrote:

 On Fri, 2015-02-13 at 09:46 -0500, Lamar Owen wrote:

 On 02/13/2015 09:15 AM, Chris Adams wrote:
  Yeah, the old move stuff to alternate ports thing is largely a waste
  of time and just makes it more difficult for legitimate use. With
  large bot networks and tools like zmap, finding services on alternate
  ports is not that hard for the bad guys.

 Having SSH on 22 is lower-hanging fruit than having SSH on a different
 port.  Sure, an NBA all-star will be able to reach the apples at the top
 of the tree easily, but most people are not NBA all-stars.  Most
 port-scanners do not scan all possible ports.

 And I am fully aware that people in the 'it's a waste of time' camp are
 unmoved by that.  It's not worth arguing about; those who move to
 non-standard ports are going to want to do it anyway.

 Lamar's comments are very sensible.

 I always change the SSH port to something conspicuously different. Every
 server has a different and difficult to guess SSH port number with
 access restricted to a few IP addresses.

 Waste of time = all the time and energy required to clean-up after a
 hacker's breech when a few seconds work selecting a different port could
 make a beneficial improvement to security.


Just to mention (even though someone already mentioned that): changing
port numbers, or, say removing disclosure by the daemon what software,
version, ... it is does not really add security. Security through
obscurity is only considered to be efficient by Windows folks. Quite
wrongfully IMHO.

So, I would suggest to not do these non-standard things fooling yourself
in wrongful feeling of better security. But instead, maintain the daemons
updated. Keep passwords reasonably sophisticated. Do not start unnecessary
services. Defend against brute force attacks (I use --hitcount option of
iptabels on Linuxes and sshguard on FreeBSD). And speaking of security:
maintain system free of local exploits (update, update, update...), that
is if (when I always consider it for my systems) the bad guys are already
in, they can not successfully elevate privileges. Each of the above is
like big chapter on system security each said in one short phrase.

And most importantly, read good fundamental Unix/Linux system book, and
revisit your system configurations (from security point of view) while
reading.

Just my $0.02

Valeri



Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Securing SSH wiki article outdated

[Warren Young]

 On Feb 13, 2015, at 9:03 AM, Valeri Galtsev galt...@kicp.uchicago.edu wrote:
 
 ...changing port numbers...does not really add security. Security through
 obscurity is only considered to be efficient by Windows folks.

“Security through obscurity” is an overused mantra of derision.

Originally, it was a cry against systems where obscurity was the *only* 
security measure taken.  You could legitimately use it today against software 
that uses a Caesar cipher instead of AES, or against an admin who moves a 
publicly-visible file to a nonstandard location to hide it instead of changing 
its permissions away from world-readable.

Obscurity as an addition to other forms of strength has been a useful tactic 
since before the Roman Empire was founded.

“…that general…is successful in defense whose opponent does not know what 
to attack.”

 — Sun Tzu, approx 500 BCE

Moving the sshd listening port greatly cuts down on the amount of log spam you 
get from bots.  Yes, the script kiddies can still find your server.  But before 
you dismiss this tactic, try the experiment.  Move your sshd to a different 
port and see what happens to your log spam.

Another legitimate reason to move the SSH port is to cope with 
overly-restrictive outbound firewalls on other people’s networks.  We have one 
SSH server that listens on port 110 because the site that logs into it has 
unconditionally blocked port 22 outbound, and we can’t get the local admin to 
open that port up for us.

If you want to talk about naive security associated with Windows admins, let’s 
talk about admins who block SSH, which is almost never a *successful* attack 
vector, while still allowing outbound POP3 connections in a world where email 
is probably the #1 vector.  :facepalm:
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Securing SSH wiki article outdated

[Always Learning]

On Fri, 2015-02-13 at 10:03 -0600, Valeri Galtsev wrote:

 On Fri, February 13, 2015 9:05 am, Always Learning wrote:

  I always change the SSH port to something conspicuously different. Every
  server has a different and difficult to guess SSH port number with
  access restricted to a few IP addresses.

 Just to mention (even though someone already mentioned that): changing
 port numbers, or, say removing disclosure by the daemon what software,
 version, ... it is does not really add security. Security through
 obscurity is only considered to be efficient by Windows folks. Quite
 wrongfully IMHO.

Changing the SSH port is the *START* of extra security (no Port 22 here)
- not the end of my efforts. SSH ports are 'protected' by restricting
access from and to designated IPs.


-- 
Regards,

Paul.
England, EU.  Je suis Charlie.


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Securing SSH wiki article outdated

[Always Learning]

On Fri, 2015-02-13 at 11:21 -0500, m.r...@5-cent.us wrote:

 I disagree - I am in the waste of time camp. The reality is that only
 script kiddies start out by trying 22 (and I *do* mean script kiddies -
 I've seen attempts to ssh in that were obviously from warez, man, where
 they were too stupid to fill in ___ with a username, or salt. All the
 others, I figure they don't need to be major league, just someone with a
 clue, who'll run a scan; in fact, I'd expect them to run a scan just to
 see what IPs were visible, and I know that if I was writing a scan, I
 don't assume that I'm *so* brilliant that I'm the only one to think of
 scanning ports  1k while looking for systems that I might hit.

Changing SSH port to a non-standard port is the beginning. Restricting
access to that port to a few IPs is another layer of protection  and
then more things are done to lessen the chances of unauthorised access.


-- 
Regards,

Paul.
England, EU.  Je suis Charlie.


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Securing SSH wiki article outdated

[Earl A Ramirez]

On Fri, 2015-02-13 at 18:27 -0800, PatrickD Garvey wrote:
 On Fri, Feb 13, 2015 at 7:12 AM, Lamar Owen lo...@pari.edu wrote:
  On 02/13/2015 05:41 AM, James Hogarth wrote:
 
  This is also why the Orange Book and its Rainbow kin exist (Orange Book =
  5200.28-STD, aka DoD Trusted Computer System Evaluation Criteria).
 
 
 Should anyone care to learn from the Rainbow Books, they are available
 from the United States of America (USA) National Institute of
 Standards and Technology (NIST) Computer Security Resource Center
 (CSRC) Selected Historical Computer Security Papers,
 http://csrc.nist.gov/publications/secpubs/ There is a caveat however,
 The Rainbow Series of Department of Defense standards is outdated,
 out of print, and provided here for historical purposes ONLY. I
 imagine the CSRC believes some of their other readily available
 publications are not outdated.
 ___
 CentOS mailing list
 CentOS@centos.org
 http://lists.centos.org/mailman/listinfo/centos

Staying on the original post, there are valuable information from this
thread about how to secure ssh, now which one of us are willing to
update the wiki. 

We can include the use of two factor authentication, public key
authentication, challenge response authentication, modifying
the /etc/hosts.allow (I have noticed that libwarp no longer contain ssh
etc...

I will read up on how to contribute to the CentOS wiki and get involved
with the documentation.




___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Securing SSH wiki article outdated

[PatrickD Garvey]

On Fri, Feb 13, 2015 at 7:12 AM, Lamar Owen lo...@pari.edu wrote:
 On 02/13/2015 05:41 AM, James Hogarth wrote:

 This is also why the Orange Book and its Rainbow kin exist (Orange Book =
 5200.28-STD, aka DoD Trusted Computer System Evaluation Criteria).


Should anyone care to learn from the Rainbow Books, they are available
from the United States of America (USA) National Institute of
Standards and Technology (NIST) Computer Security Resource Center
(CSRC) Selected Historical Computer Security Papers,
http://csrc.nist.gov/publications/secpubs/ There is a caveat however,
The Rainbow Series of Department of Defense standards is outdated,
out of print, and provided here for historical purposes ONLY. I
imagine the CSRC believes some of their other readily available
publications are not outdated.
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Securing SSH wiki article outdated

[m . roth]

Warren Young wrote:
 Hi, just a quick note to whoever is maintaining this page:

   http://wiki.centos.org/HowTos/Network/SecuringSSH

 The procedure is missing the firewall-cmd calls necessary in EL7:

   firewall-cmd --add-port 2345/tcp
   firewall-cmd --add-port 2345/tcp --permanent

 Also, it may be worth mentioning that semanage is in the
 policycoreutils-python package, which isn’t installed by default in all
 stock configurations.

Nor is setroubleshoot.

   mark

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Securing SSH

[Chris 'Chipper' Chiapusio]

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:

http://wiki.centos.org/HowTos/Network/SecuringSSH

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

--
--
 Warning 
This e-mail message, without warrant or warning, and despite US law as set
forth in the Foreign Intelligence Surveillance Act of 1978, may be subject
to monitoring by the United States National Security Agency and/or the
Department of Defense. Information contained in this message may be used
against any senders or recipients, now or in the future, in a public trial
or secret tribunal.
  Please encrypt anything important.
   PGP Key: http://wwwkeys.pgp.net:11371/pks/lookup?op=getsearch=0x6CFA486D
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Securing SSH

[Tim Alberts]

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:

http://wiki.centos.org/HowTos/Network/SecuringSSH

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?


begin:vcard
fn:Tim Alberts
n:Alberts;Tim
org:Measurement Systems International;Engineering
adr:Suite 200;;14240 Interurban Avenue South;Seattle;WA;98168;USA
email;internet:[EMAIL PROTECTED]
title:Associate Engineer
tel;work:206-433-0199
tel;fax:206-244-8470
x-mozilla-html:FALSE
url:http://www.msiscales.com/
version:2.1
end:vcard

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

RE: [CentOS] Securing SSH

[CentOS List]

 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 mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Securing SSH

[Ned Slider]

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:

http://wiki.centos.org/HowTos/Network/SecuringSSH

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.


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Securing SSH

[Tim Alberts]

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.


begin:vcard
fn:Tim Alberts
n:Alberts;Tim
org:Measurement Systems International;Engineering
adr:Suite 200;;14240 Interurban Avenue South;Seattle;WA;98168;USA
email;internet:[EMAIL PROTECTED]
title:Associate Engineer
tel;work:206-433-0199
tel;fax:206-244-8470
x-mozilla-html:FALSE
url:http://www.msiscales.com/
version:2.1
end:vcard

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Securing SSH

[Ray Leventhal]

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


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




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

Re: [CentOS] Securing SSH

[Daniel Andrzejewski]

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

--
Daniel Andrzejewski
student IT Administrator
Elec Engr  Comp Science
University of Tennessee
(865) 974 - 4388 (work)

Investment in knowledge always pays the best interest
Benjamin Franklin
--
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Securing SSH

[Rudi Ahlers]

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


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




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  :)


--

Kind Regards
Rudi Ahlers
CEO, SoftDux

Web:   http://www.SoftDux.com
Check out my technical blog, http://blog.softdux.com for Linux or other 
technical stuff, or visit http://www.WebHostingTalk.co.za for Web Hosting stuff

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Securing SSH

[Trey Sizemore]

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

 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


 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...

-- 
Cheers,
Trey

 
Adversity is the trial of principle.
Without it, a man hardly knows whether he is honest or not. 
 --Henry Fielding
 
Linux valkyrie 2.6.22.17-0.1-bigsmp i686 GNU/Linux
  2:21pm  up  19:37,  5 users,  load average: 0.68, 0.68, 0.65
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Securing SSH

[Ned Slider]

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:

http://wiki.centos.org/HowTos/Network/SecuringSSH

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Securing SSH

[Rudi Ahlers]

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



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


  
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

--

Kind Regards
Rudi Ahlers
CEO, SoftDux

Web:   http://www.SoftDux.com
Check out my technical blog, http://blog.softdux.com for Linux or other 
technical stuff, or visit http://www.WebHostingTalk.co.za for Web Hosting stuff

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Securing SSH

[Morten Nilsen]

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



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


  
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



(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.


--
Thank you,
Morten
:wq
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Securing SSH

[Peter Kjellstrom]

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



signature.asc
Description: This is a digitally signed message part.
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

RE: [CentOS] Securing SSH

[Jes Struck]

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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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

RE: [CentOS] Securing SSH

[Jes Struck]

And also try to pay a little with 
AllowUsers user1 user2 user3
There might be a AllowGroup ??


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Securing SSH

[Carlos Daniel Ruvalcaba Valenzuela]

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
[EMAIL PROTECTED] 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
  
1. Change the default port

  Is an option but a waste of time as a scanner will find the port it was moved
  to.


2. use only SSH protocol 2

  Agree


3. Install some brute force protection which can automatically ban an IP
on say 5 / 10 failed login attempts

  Fail2ban comes to mind.


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

  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

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Securing SSH

[Jacques B.]

   3. Install some brute force protection which can automatically ban an IP
   on say 5 / 10 failed login attempts
   The only software I know that could do this isn't supported anymore
   (trisentry) or is too confusing and I don't know it yet (snort).
   Suggestions?

  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.
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Securing SSH

[Kai Schaetzl]

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

-- 
Kai Schätzl, Berlin, Germany
Get your web at Conactive Internet Services: http://www.conactive.com



___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Securing SSH

[Robert Spangler]

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.


-- 

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

Re: [CentOS] Securing SSH

[Kai Schaetzl]

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

-- 
Kai Schätzl, Berlin, Germany
Get your web at Conactive Internet Services: http://www.conactive.com



___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

RE: [CentOS] Securing SSH

[Bowie Bailey]

Kai Schaetzl wrote:
 Robert Spangler wrote on Wed, 26 Mar 2008 08:03:48 -0400:
 
  If you are going to use VPN then why not setup your remote site to
  use VPN and bypass SSH altogether then?
 
 There could be several reasons, for instance:
 1. SSH is all what is necessary
 2. it's probably easier to have *one* VPN and then be able to ssh to
 dozens of other machines instead of setting up VPN on all of them and
 running several VPN tunnels at once

Use VPN to connect to your network and then ssh through the VPN tunnel
to any machines you need to work with.  This way only the VPN is exposed
to the Internet.

  Bottom line is if you want to be secure don't use passwords for
  login. 
 
 Still doesn't stop those brute-force attacks. It just makes them
 fail. That's the point about moving port etc., not the security.

Agreed.  I have one machine on my network that exposes an ssh connection
on a non-standard port.  My logs for the last month do not show a single
failed connection attempt.

-- 
Bowie
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Securing SSH

[Kai Schaetzl]

Bowie Bailey wrote on Wed, 26 Mar 2008 09:18:56 -0500:

 Use VPN to connect to your network and then ssh through the VPN tunnel
 to any machines you need to work with.  This way only the VPN is exposed
 to the Internet.

if the machines are within the LAN, yes. My original point was that if you 
have a static IP address for your local LAN *and* you want to restrict the 
*remote* machines to be ssh-connectable only from that LAN (which is a 
good security measure) *and* you are on the road you can still work on 
your remote machine by VPNing into your LAN. There are other solutions, 
but VPN is probably the easiest one as most SOHO routers should be able to 
terminate a VPN and it's likely that you want to connect to your LAN via 
VPN for other purposes, anyway. Doing that for the machines *within* your 
LAN is granted.

Kai

-- 
Kai Schätzl, Berlin, Germany
Get your web at Conactive Internet Services: http://www.conactive.com



___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Securing SSH

[Tom Brown]

if the machines are within the LAN, yes. My original point was that if you 
have a static IP address for your local LAN *and* you want to restrict the 
*remote* machines to be ssh-connectable only from that LAN (which is a 
good security measure) *and* you are on the road you can still work on 
your remote machine by VPNing into your LAN. There are other solutions, 
but VPN is probably the easiest one as most SOHO routers should be able to 
terminate a VPN and it's likely that you want to connect to your LAN via 
VPN for other purposes, anyway. Doing that for the machines *within* your 
LAN is granted.


  


openvpn is perfect for this sort of situation -

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

RE: [CentOS] Securing SSH

[Bowie Bailey]

Kai Schaetzl wrote:
 Bowie Bailey wrote on Wed, 26 Mar 2008 09:18:56 -0500:
 
  Use VPN to connect to your network and then ssh through the VPN
  tunnel to any machines you need to work with.  This way only the
  VPN is exposed to the Internet.
 
 if the machines are within the LAN, yes. My original point was that
 if you have a static IP address for your local LAN *and* you want to
 restrict the *remote* machines to be ssh-connectable only from that
 LAN (which is a good security measure) *and* you are on the road you
 can still work on your remote machine by VPNing into your LAN. There
 are other solutions, but VPN is probably the easiest one as most SOHO
 routers should be able to terminate a VPN and it's likely that you
 want to connect to your LAN via VPN for other purposes, anyway. Doing
 that for the machines *within* your LAN is granted.

Ok.  I was thinking of a simpler traveling user needs access to
machines on the LAN scenario.  :)

-- 
Bowie
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Securing SSH

[Tim Alberts]

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?


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Securing SSH

[mouss]

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.

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Securing SSH

[Mike Kercher]

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 [EMAIL PROTECTED] 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

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Securing SSH

[Rudi Ahlers]

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


--

Kind Regards
Rudi Ahlers
CEO, SoftDux

Web:   http://www.SoftDux.com
Check out my technical blog, http://blog.softdux.com for Linux or other 
technical stuff, or visit http://www.WebHostingTalk.co.za for Web Hosting stugg

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Securing SSH

[James A. Peltier]

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


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




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. :)



--
James A. Peltier
Technical Director, RHCE
SCIRF | GrUVi @ Simon Fraser University - Burnaby Campus
Phone   : 778-782-3610
Fax : 778-782-3045
Mobile  : 778-840-6434
E-Mail  : [EMAIL PROTECTED]
Website : http://gruvi.cs.sfu.ca | http://scirf.cs.sfu.ca
MSN : [EMAIL PROTECTED]
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Securing SSH

[John R Pierce]

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.



___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Securing SSH

[Tim Alberts]

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

*
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Securing SSH

[Matt Shields]

On Tue, Mar 25, 2008 at 12:48 PM, Tim Alberts [EMAIL PROTECTED] wrote:
 So I setup ssh on a server so I could do some work from home and I think
  the second I opened it every sorry monkey from around the world has been
  trying every account name imaginable to get into the system.

  What's a good way to deal with this?

DenyHosts - http://denyhosts.sourceforge.net/  Also, when you set it
up, set it to download the lists from their website.  These lists are
IPs that other users have found scanning their network.


-- 
-matt
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Securing SSH

[Tim Alberts]

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.

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Securing SSH

[Tim Alberts]

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


1. 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).



2. use only SSH protocol 2

got it.
3. Install some brute force protection which can automatically ban an 
IP on say 5 / 10 failed login attempts
The only software I know that could do this isn't supported anymore 
(trisentry) or is too confusing and I don't know it yet (snort).  
Suggestions?


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


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.


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Securing SSH

[Ray Van Dolson]

 1. 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. :)

 2. use only SSH protocol 2
 got it.
 3. Install some brute force protection which can automatically ban an IP 
 on say 5 / 10 failed login attempts
 The only software I know that could do this isn't supported anymore 
 (trisentry) or is too confusing and I don't know it yet (snort).  
 Suggestions?

denyhosts is pretty widely used.  You could probably also make use of
iptables.

 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

 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
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Securing SSH

[Theo Band [GreenPeak]]

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 
B3NzaC1kc3MAsnipAqNY= [EMAIL PROTECTED]


Theo
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Securing SSH

[Ingemar Nilsson]

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
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Securing SSH

[David Mackintosh]

On Tue, Mar 25, 2008 at 09:48:17AM -0700, Tim Alberts wrote:
 So I setup ssh on a server so I could do some work from home and I think 
 the second I opened it every sorry monkey from around the world has been 
 trying every account name imaginable to get into the system.
 
 What's a good way to deal with this?

This is what I do.

http://wiki.xdroop.com/space/Linux/Limited+SSH+Access

-- 
 /\oo/\
/ /()\ \ David Mackintosh | 
 [EMAIL PROTECTED]  | http://www.xdroop.com


pgpDF8dtEQcUQ.pgp
Description: PGP signature
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Securing SSH

[John R Pierce]

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.


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Securing SSH

[Tim Alberts]

David Mackintosh wrote:

On Tue, Mar 25, 2008 at 09:48:17AM -0700, Tim Alberts wrote:
  
So I setup ssh on a server so I could do some work from home and I think 
the second I opened it every sorry monkey from around the world has been 
trying every account name imaginable to get into the system.


What's a good way to deal with this?



This is what I do.

http://wiki.xdroop.com/space/Linux/Limited+SSH+Access

  
That sounds great for getting around a remote dynamic IP address, but 
some more authentication/security on that web page is necessary, 
otherwise, anyone who finds that web page is given access?


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Securing SSH

[Tim Alberts]

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.  :)


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Securing SSH

[Rudi Ahlers]

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.

http://wiki.xdroop.com/space/Linux/Limited+SSH+Access

  
That sounds great for getting around a remote dynamic IP address, but 
some more authentication/security on that web page is necessary, 
otherwise, anyone who finds that web page is given access?


___


Why?
What is on that site which is very specific to the setup?

--

Kind Regards
Rudi Ahlers
CEO, SoftDux

Web:   http://www.SoftDux.com
Check out my technical blog, http://blog.softdux.com for Linux or other 
technical stuff, or visit http://www.WebHostingTalk.co.za for Web Hosting stugg

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Securing SSH

[Tony Placilla]

Tony Placilla [EMAIL PROTECTED]
Sr. UNIX Systems Administrator
The Sheridan Libraries
Johns Hopkins University
















 On Tue, Mar 25, 2008 at 12:48 PM, in message [EMAIL PROTECTED],
Tim Alberts [EMAIL PROTECTED] 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 :)

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Securing SSH

[John R Pierce]

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.



___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Securing SSH

[Rudi Ahlers]

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.


--

Kind Regards
Rudi Ahlers
CEO, SoftDux

Web:   http://www.SoftDux.com
Check out my technical blog, http://blog.softdux.com for Linux or other 
technical stuff, or visit http://www.WebHostingTalk.co.za for Web Hosting stugg

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Securing SSH

[David Mackintosh]

On Tue, Mar 25, 2008 at 11:28:45AM -0700, Tim Alberts wrote:
 http://wiki.xdroop.com/space/Linux/Limited+SSH+Access
   
 That sounds great for getting around a remote dynamic IP address, but 
 some more authentication/security on that web page is necessary, 
 otherwise, anyone who finds that web page is given access?

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.  

-- 
 /\oo/\
/ /()\ \ David Mackintosh | 
 [EMAIL PROTECTED]  | http://www.xdroop.com


pgpheBd6M3mv6.pgp
Description: PGP signature
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Securing SSH

[Anne Wilson]

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


signature.asc
Description: This is a digitally signed message part.
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Securing SSH

[Liam Kirsher]

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


-- 
Liam Kirsher
PGP: http://liam.numenet.com/pgp/

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Securing SSH

[Robert Spangler]

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

  1. Change the default port

Is an option but a waste of time as a scanner will find the port it was moved 
to.

  2. use only SSH protocol 2

Agree

  3. Install some brute force protection which can automatically ban an IP
  on say 5 / 10 failed login attempts

Fail2ban comes to mind.

  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

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