Hello,
is there a security issue on CentOS 5.3 with openssh 4.3? I ask that cause of http://www.h-online.com/security/Rumours-of-critical-vulnerability-in-OpenSS... and http://secer.org/hacktools/0day-openssh-remote-exploit.html.
Should ssh login from internet on CentOS better be disabled?
regards Olaf
is there a security issue on CentOS 5.3 with openssh 4.3?
If this is a real zero-day exploit.. then yes, there is an issue. The following link may be the best source of information at the moment:
http://isc.sans.org/diary.html?storyid=6742
FWIW, I think the second comment about RHEL/Centos in the referenced post is a little off-base. After all, you have to know that a bug exists before you can fix it.
-geoff
--------------------------------- Geoff Galitz Blankenheim NRW, Germany http://www.galitz.org/ http://german-way.com/blog/
On Tue, Jul 07, 2009 at 10:31:36PM +0200, Geoff Galitz wrote:
is there a security issue on CentOS 5.3 with openssh 4.3?
If this is a real zero-day exploit.. then yes, there is an issue. The following link may be the best source of information at the moment:
http://isc.sans.org/diary.html?storyid=6742
FWIW, I think the second comment about RHEL/Centos in the referenced post is a little off-base. After all, you have to know that a bug exists before you can fix it.
This link[1] seems to show a RHEL 5.3 machine being exploited (could be wrong though). Not sure which version of the openssh-server package it is however beyond the base 4.3.
And a post[2] by a RH engineer to the openssh list.
Ray
[1] http://secer.org/hacktools/0day-openssh-remote-exploit.html [2] http://marc.info/?l=openssh-unix-dev&m=124699121213120&w=2
On Tuesday 07 July 2009, Ray Van Dolson wrote:
On Tue, Jul 07, 2009 at 10:31:36PM +0200, Geoff Galitz wrote:
is there a security issue on CentOS 5.3 with openssh 4.3?
If this is a real zero-day exploit.. then yes, there is an issue. The following link may be the best source of information at the moment:
http://isc.sans.org/diary.html?storyid=6742
FWIW, I think the second comment about RHEL/Centos in the referenced post is a little off-base. After all, you have to know that a bug exists before you can fix it.
This link[1] seems to show a RHEL 5.3 machine being exploited (could be wrong though).
The only thing indicating that this is RHEL-5.3 is, afaict, the title. The kernel version is not EL, the mysql version is not etc.
Worth keeping an eye on though.
/Peter
Am 07.07.2009 um 22:31 schrieb Geoff Galitz:
is there a security issue on CentOS 5.3 with openssh 4.3?
If this is a real zero-day exploit.. then yes, there is an issue. The following link may be the best source of information at the moment:
http://isc.sans.org/diary.html?storyid=6742
FWIW, I think the second comment about RHEL/Centos in the referenced post is a little off-base. After all, you have to know that a bug exists before you can fix it.
Well, there are usually behind-the-scenes communications between various vendors to get security-relevant bugs fixed in a coordinated fashion. This community is very small and closely knit - few stuff (if at all) spills out before it should. So, there might be fixes waiting to be released, too. We just don't know.
Unless it's a real 0day. Those are rare, though ;-)
Rainer
This appeared today on Macworld, an article saying this is probably a hoax:
http://www.macworld.com/article/141628/2009/07/openssh_securityhoax.html?lsr...
Bill
On Thu, 2009-07-09 at 15:18 -0700, Bill Campbell wrote:
This appeared today on Macworld, an article saying this is probably a hoax:
http://www.macworld.com/article/141628/2009/07/openssh_securityhoax.html?lsr...
Bill
In my iptables setup I have the following rule: (excuse the ugly line breaks)
/sbin/iptables -A INPUT -i eth0 -p tcp -s 196.1.1.0/24 -d 196.1.1.31 \ --dport 22 -m state -m recent --state NEW --update --seconds 15 -j \ DROPLOG
/sbin/iptables -A INPUT -i eth0 -p tcp -s 196.1.1.0/24 -d 196.1.1.31 \ --dport 22 -m state -m recent --state NEW --set -j ACCEPT
/sbin/iptables -A INPUT -i eth0 -p tcp -s 196.1.1.0/24 -d 196.1.1.31 \ --dport 22 -m state --state ESTABLISHED --state RELATED -j ACCEPT
it only allows one NEW connection to ssh per minute.
That is also a good protection right?
Regards, Coert
Coert Waagmeester wrote:
On Thu, 2009-07-09 at 15:18 -0700, Bill Campbell wrote:
This appeared today on Macworld, an article saying this is probably a hoax:
http://www.macworld.com/article/141628/2009/07/openssh_securityhoax.html?lsr...
Bill
In my iptables setup I have the following rule: (excuse the ugly line breaks)
/sbin/iptables -A INPUT -i eth0 -p tcp -s 196.1.1.0/24 -d 196.1.1.31 \ --dport 22 -m state -m recent --state NEW --update --seconds 15 -j \ DROPLOG
/sbin/iptables -A INPUT -i eth0 -p tcp -s 196.1.1.0/24 -d 196.1.1.31 \ --dport 22 -m state -m recent --state NEW --set -j ACCEPT
/sbin/iptables -A INPUT -i eth0 -p tcp -s 196.1.1.0/24 -d 196.1.1.31 \ --dport 22 -m state --state ESTABLISHED --state RELATED -j ACCEPT
it only allows one NEW connection to ssh per minute.
That is also a good protection right?
Regards, Coert
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Not really protection - rather a deterrent - it just makes it slower for the script kiddies that try brute force attacks - they have to pace themselves to one try per minute rather than one or two per second. Thus they normally move on to an easier target. You can also use iptables to allow say four attempts from an IP and then block for 5 or more minutes - this is what I use. HTH Rob
Rob Kampen schrieb:
Not really protection - rather a deterrent - it just makes it slower for the script kiddies that try brute force attacks - they have to pace themselves to one try per minute rather than one or two per second. Thus they normally move on to an easier target. You can also use iptables to allow say four attempts from an IP and then block for 5 or more minutes - this is what I use.
Not really, either ;-) Brute-forcing has long-since started to go distributed, fooling fail2ban and similar scripts with just 3 or 4 checks per single source-host.
The bad guys do cloud-computing, too....
Rainer
On 07/10/2009 02:59 PM, Rainer Duffner wrote:
Brute-forcing has long-since started to go distributed, fooling fail2ban and similar scripts with just 3 or 4 checks per single source-host.
I've never been a big fan of either denyhosts or fail2ban, both of them are just making it easier for someone else to ddos you, and achieve little in terms of the real problem, as you said here the brute forcing has gone into the spam-botnets a long time back.
as an example : one of my machines got ssh attempts from > 3500 different ip's in under an hour a few weeks back.
pam_shield and similar solutions offer a slightly gentler way to implement similar stuff, but iptables and perhaps a creative netlables solution to lock in what you need and how you need it, is a far better solution.
- KB
On Friday 10 July 2009, Rob Kampen wrote:
Coert Waagmeester wrote:
...
it only allows one NEW connection to ssh per minute.
That is also a good protection right?
...
Not really protection - rather a deterrent - it just makes it slower for the script kiddies that try brute force attacks
Basically it's not so much about protection in the end as it is about keeping your secure-log readable. Or maybe also a sense of being secure...
It's always good to limit your exposure but you really have to weigh cost against the win. Two examples:
Limit from which hosts you can login to a server: Configuration cost: trivial setup (one iptables line) Additional cost: between no impact and some impact depending on your habits Positive effect: 99.9+% of all scans and login attempts are now gone Verdict: Clear win as long as the set of servers are easily identifiable
Elaborate knocking/blocking setup: Configuration cost: significant (include keeping it up-to-date) Additional cost: setup of clients for knocking, use of -p XXX for new port Positive effect: "standard scans" will probably miss but not air tight Verdict: Harder to judge, I think it's often not worth it
Other things worth looking into are, for example, access.conf (pam_access.so) and ensuring that non-trivial passwords are used.
my €0.02, Peter
On Fri, Jul 10, 2009 at 9:33 AM, Peter Kjellstromcap@nsc.liu.se wrote:
On Friday 10 July 2009, Rob Kampen wrote:
Coert Waagmeester wrote:
...
it only allows one NEW connection to ssh per minute.
That is also a good protection right?
...
Not really protection - rather a deterrent - it just makes it slower for the script kiddies that try brute force attacks
Basically it's not so much about protection in the end as it is about keeping your secure-log readable. Or maybe also a sense of being secure...
It's always good to limit your exposure but you really have to weigh cost against the win. Two examples:
Limit from which hosts you can login to a server: Configuration cost: trivial setup (one iptables line) Additional cost: between no impact and some impact depending on your habits Positive effect: 99.9+% of all scans and login attempts are now gone Verdict: Clear win as long as the set of servers are easily identifiable
Elaborate knocking/blocking setup: Configuration cost: significant (include keeping it up-to-date) Additional cost: setup of clients for knocking, use of -p XXX for new port Positive effect: "standard scans" will probably miss but not air tight Verdict: Harder to judge, I think it's often not worth it
Other things worth looking into are, for example, access.conf (pam_access.so) and ensuring that non-trivial passwords are used.
my €0.02, Peter
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Virtual Networks are such as tinc-vpn.org or hamachi create an encrypted network only accessible to members of the virtual network. So if your server's virtual nic has an address of 5.4.3.2, then the only other host that may see your server would be your laptop with address 5.4.3.3. No other internet hosts would even see 5.4.3.2... It is like IPSec, but much easier.
I think if you use double authentication (both keys and a password) and put your SSH server on a different port then you are doing the best you can. You hope to prevent a 0-day but you cannot fully protect yourself...
James
On Fri, Jul 10, 2009 at 7:06 PM, Rob Townley rob.townley@gmail.com wrote:
On Fri, Jul 10, 2009 at 9:33 AM, Peter Kjellstromcap@nsc.liu.se wrote:
On Friday 10 July 2009, Rob Kampen wrote:
Coert Waagmeester wrote:
...
it only allows one NEW connection to ssh per minute.
That is also a good protection right?
...
Not really protection - rather a deterrent - it just makes it slower for the script kiddies that try brute force attacks
Basically it's not so much about protection in the end as it is about
keeping
your secure-log readable. Or maybe also a sense of being secure...
It's always good to limit your exposure but you really have to weigh cost against the win. Two examples:
Limit from which hosts you can login to a server: Configuration cost: trivial setup (one iptables line) Additional cost: between no impact and some impact depending on your
habits
Positive effect: 99.9+% of all scans and login attempts are now gone Verdict: Clear win as long as the set of servers are easily identifiable
Elaborate knocking/blocking setup: Configuration cost: significant (include keeping it up-to-date) Additional cost: setup of clients for knocking, use of -p XXX for new
port
Positive effect: "standard scans" will probably miss but not air tight Verdict: Harder to judge, I think it's often not worth it
Other things worth looking into are, for example, access.conf
(pam_access.so)
and ensuring that non-trivial passwords are used.
my €0.02, Peter
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Virtual Networks are such as tinc-vpn.org or hamachi create an encrypted network only accessible to members of the virtual network. So if your server's virtual nic has an address of 5.4.3.2, then the only other host that may see your server would be your laptop with address 5.4.3.3. No other internet hosts would even see 5.4.3.2... It is like IPSec, but much easier. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
is there a security issue on CentOS 5.3 with openssh 4.3? I ask that cause of http://www.h-online.com/security/Rumours-of-critical-vulnerabi lity-in-OpenSSH-in-Red-Hat-Enterprise-Linux--/news/113712 and http://secer.org/hacktools/0day-openssh-remote-exploit.html.
Should ssh login from internet on CentOS better be disabled?
You should always limit access to sensitive services on a machine. Remote login should be included in that list. Either limit it by firewall or in the openssh daemon to certain ips. Even if you can only limit it to a class c or class a, you've still chopped out a number of possibly malicious hosts.
Patrick
On 08/07/2009, Flaherty, Patrick pflaherty@wsi.com wrote:
is there a security issue on CentOS 5.3 with openssh 4.3? I ask that cause of http://www.h-online.com/security/Rumours-of-critical-vulnerabi lity-in-OpenSSH-in-Red-Hat-Enterprise-Linux--/news/113712 and http://secer.org/hacktools/0day-openssh-remote-exploit.html.
this from sans
http://isc.sans.org/diary.html?storyid=6760
another good reason for using pki rather than password auth so no magic 0day just another brute force tool
mike
-
Bill Campbell -
Coert Waagmeester -
Flaherty, Patrick -
Geoff Galitz -
James Matthews -
Karanbir Singh -
Michael Simpson -
Olaf Mueller -
Peter Kjellstrom -
Rainer Duffner -
Ray Van Dolson -
Rob Kampen -
Rob Townley