There's an article on slashdot about the Duqu team wiping all their intermediary c&c servers on 20 Oct. Interestingly, the report says that they were all (?) not only linux, but CentOS. There's a suggestion of a zero-day exploit in openssh-4.3, but both the original article, and Kaspersky labs (who have a *very* interesting post of the story) consider that highly unlikely, and the evidence points to brute-force attacks against the root password. Then they update openssh and openssh-server. And then, at some point, they apparently take an ubuntu/debian openssh 5.9p1 (then p2) source package, and install *that*
My manager suggest updating openssh to block other attackers (who actually might screw their attack). It still seems odd to me to yum update, then build the software from source.
Are your root passwords strong?
mark
PS: Oh, yes: http://it.slashdot.org/story/11/11/30/1610228/duqu-attackers-managed-to-wipe-cc-servers
On Wed, Nov 30, 2011 at 12:05 PM, m.roth@5-cent.us wrote:
Are your root passwords strong?
I've always wondered why something as complex as sshd doesn't do anything to protect you from the simplest form of attack - like rate-limiting failed attempts.
Les Mikesell wrote:
On Wed, Nov 30, 2011 at 12:05 PM, m.roth@5-cent.us wrote:
Are your root passwords strong?
I've always wondered why something as complex as sshd doesn't do anything to protect you from the simplest form of attack - like rate-limiting failed attempts.
Well, it does take time to respond to failed passwords, in my experience.
From the example in the Kaspersky Labs post, either they tried over a
period of time (low-level persistent threat), or it was a stupidly weak password (or had never been changed).
We also run fail2ban, that slows them down a *lot* more.
mark
Les Mikesell wrote:
On Wed, Nov 30, 2011 at 12:05 PM, m.roth@5-cent.us wrote:
Are your root passwords strong?
I've always wondered why something as complex as sshd doesn't do anything to protect you from the simplest form of attack - like rate-limiting failed attempts.
Passwords?? Why? Remote root login via ssh?? Why? This is why they invented cyphers and rsa and 3des etc - use these and it makes it MUCH harder for the black hackers.
On Wed, Nov 30, 2011 at 12:42 PM, Rob Kampen rkampen@kampensonline.com wrote:
I've always wondered why something as complex as sshd doesn't do anything to protect you from the simplest form of attack - like rate-limiting failed attempts.
Passwords?? Why?
Because they are there and enabled by default...
Remote root login via ssh?? Why?
Because that is necessary (or a way to escalate to root) to do anything useful like backups or remote administration.
This is why they invented cyphers and rsa and 3des etc - use these and it makes it MUCH harder for the black hackers.
Sure, but you could just use a separate VPN to get in if you want to make things complicated. Ssh is mostly about being able to log in.
On 30 Nov 2011, at 18:51, Les Mikesell lesmikesell@gmail.com wrote:
Ssh is mostly about being able to log in.
I've always adopted the policy of disabling root logins, making admins use a separate account with public/private key authentication and then requiring them to use su to elevate privileges.
Has the advantage that your logs will tell you who logged in and performed an action rather than the vague 'root'.
Ben
Sent from my iPhone
On 11/30/2011 1:55 PM, Benjamin Donnachie wrote:
On 30 Nov 2011, at 18:51, Les Mikeselllesmikesell@gmail.com wrote:
Ssh is mostly about being able to log in.
I've always adopted the policy of disabling root logins, making admins use a separate account with public/private key authentication and then requiring them to use su to elevate privileges.
Has the advantage that your logs will tell you who logged in and performed an action rather than the vague 'root'.
Ben
How would you automate daily logins from another server to do something like rsync the entire /etc directory to a backup system?
On Wed, Nov 30, 2011 at 1:01 PM, John Hinton webmaster@ew3d.com wrote:
How would you automate daily logins from another server to do something like rsync the entire /etc directory to a backup system?
Key restrictions in authorized_keys from="10.10.10.10" command="rsync -azv blah/blah/." ssh-key-info-here
better than nothing.
On Wed, Nov 30, 2011 at 1:01 PM, John Hinton webmaster@ew3d.com wrote:
On 11/30/2011 1:55 PM, Benjamin Donnachie wrote:
Ssh is mostly about being able to log in.
I've always adopted the policy of disabling root logins, making admins use a separate account with public/private key authentication and then requiring them to use su to elevate privileges.
Has the advantage that your logs will tell you who logged in and performed an action rather than the vague 'root'.
How would you automate daily logins from another server to do something like rsync the entire /etc directory to a backup system?
You can set up a passwordless sudo that is passed as part of the ssh command. And I agree that this is likely to be a safer approach as long as the private key which is much like a written-down password can be protected well enough.
On 30-11-11 20:01, John Hinton wrote:
On 11/30/2011 1:55 PM, Benjamin Donnachie wrote:
On 30 Nov 2011, at 18:51, Les Mikeselllesmikesell@gmail.com wrote:
Ssh is mostly about being able to log in.
I've always adopted the policy of disabling root logins, making admins use a separate account with public/private key authentication and then requiring them to use su to elevate privileges.
Has the advantage that your logs will tell you who logged in and performed an action rather than the vague 'root'.
Ben
How would you automate daily logins from another server to do something like rsync the entire /etc directory to a backup system?
Maybe the sshd_config option "PermitRootLogin forced-commands-only" could help? This allows root logins but limits which command(s) can be executed. There is a description of how this works here: http://troy.jdmz.net/rsync/index.html
Regards, Patrick
On Wed, 30 Nov 2011 14:01:36 -0500 John Hinton webmaster@ew3d.com wrote:
On 11/30/2011 1:55 PM, Benjamin Donnachie wrote:
On 30 Nov 2011, at 18:51, Les Mikeselllesmikesell@gmail.com wrote:
Ssh is mostly about being able to log in.
I've always adopted the policy of disabling root logins, making admins use a separate account with public/private key authentication and then requiring them to use su to elevate privileges.
Has the advantage that your logs will tell you who logged in and performed an action rather than the vague 'root'.
Ben
How would you automate daily logins from another server to do something like rsync the entire /etc directory to a backup system?
You shouldn't do that *from* another server, you should do that *to* another server.
Plus: if there is a reason for logging in remotely with root, you're doing something wrong 99.999% of the time.
Rui
Benjamin Donnachie wrote:
On 30 Nov 2011, at 18:51, Les Mikesell lesmikesell@gmail.com wrote:
Ssh is mostly about being able to log in.
I've always adopted the policy of disabling root logins, making admins use a separate account with public/private key authentication and then requiring them to use su to elevate privileges.
Has the advantage that your logs will tell you who logged in and performed an action rather than the vague 'root'.
+1
Ben
Sent from my iPhone _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 11/30/2011 12:05 PM, m.roth@5-cent.us wrote:
There's an article on slashdot about the Duqu team wiping all their intermediary c&c servers on 20 Oct. Interestingly, the report says that they were all (?) not only linux, but CentOS. There's a suggestion of a zero-day exploit in openssh-4.3, but both the original article, and Kaspersky labs (who have a *very* interesting post of the story) consider that highly unlikely, and the evidence points to brute-force attacks against the root password. Then they update openssh and openssh-server. And then, at some point, they apparently take an ubuntu/debian openssh 5.9p1 (then p2) source package, and install *that*
My manager suggest updating openssh to block other attackers (who actually might screw their attack). It still seems odd to me to yum update, then build the software from source.
Are your root passwords strong?
mark
PS: Oh, yes: http://it.slashdot.org/story/11/11/30/1610228/duqu-attackers-managed-to-wipe-cc-servers
The problem with that theory is that Red Hat has backported patches for all know exploits.
I am going to specifically research which exploit they think is being used ...
Now, note that people were running 5.2 or 5.3, etc and not 5.7 like they should have been, so there might well have been an openssh exploit available ... just not a zero day one from 4.3.
I am very interested and will be researching this thoroughly.
My initial gut reaction is that they got in via a password though.
On Wed, Nov 30, 2011 at 12:40 PM, Johnny Hughes johnny@centos.org wrote:
On 11/30/2011 12:05 PM, m.roth@5-cent.us wrote:
There's an article on slashdot about the Duqu team wiping all their intermediary c&c servers on 20 Oct. Interestingly, the report says that they were all (?) not only linux, but CentOS. There's a suggestion of a zero-day exploit in openssh-4.3, but both the original article, and Kaspersky labs (who have a *very* interesting post of the story) consider that highly unlikely, and the evidence points to brute-force attacks against the root password. Then they update openssh and openssh-server. And then, at some point, they apparently take an ubuntu/debian openssh 5.9p1 (then p2) source package, and install *that*
My manager suggest updating openssh to block other attackers (who actually might screw their attack). It still seems odd to me to yum update, then build the software from source.
Are your root passwords strong?
mark
PS: Oh, yes: http://it.slashdot.org/story/11/11/30/1610228/duqu-attackers-managed-to-wipe-cc-servers
The problem with that theory is that Red Hat has backported patches for all know exploits.
I am going to specifically research which exploit they think is being used ...
Now, note that people were running 5.2 or 5.3, etc and not 5.7 like they should have been, so there might well have been an openssh exploit available ... just not a zero day one from 4.3.
I am very interested and will be researching this thoroughly.
My initial gut reaction is that they got in via a password though.
Any luck on the specific attack path yet? The linked article suggests Centos up to 5.5 was vulnerable.
On 12/06/2011 08:09 PM, Les Mikesell wrote:
Any luck on the specific attack path yet? The linked article suggests Centos up to 5.5 was vulnerable.
We dont have access to the actual machines that were broken into - so pretty much everything is second hand info.
But based on what we know and what we have been told and what we have worked out ourselves as well, its almost certainly bruteforced ssh passwords.
- KB
On Tue, Dec 6, 2011 at 2:18 PM, Karanbir Singh mail-lists@karan.org wrote:
On 12/06/2011 08:09 PM, Les Mikesell wrote:
Any luck on the specific attack path yet? The linked article suggests Centos up to 5.5 was vulnerable.
We dont have access to the actual machines that were broken into - so pretty much everything is second hand info.
But based on what we know and what we have been told and what we have worked out ourselves as well, its almost certainly bruteforced ssh passwords.
So, coincidence that they were CentOS, and pre-5.6? Did they have admins in common?
Les Mikesell wrote:
On Tue, Dec 6, 2011 at 2:18 PM, Karanbir Singh mail-lists@karan.org wrote:
On 12/06/2011 08:09 PM, Les Mikesell wrote:
Any luck on the specific attack path yet? The linked article suggests Centos up to 5.5 was vulnerable.
We dont have access to the actual machines that were broken into - so pretty much everything is second hand info.
But based on what we know and what we have been told and what we have worked out ourselves as well, its almost certainly bruteforced ssh passwords.
So, coincidence that they were CentOS, and pre-5.6? Did they have admins in common?
Just incompetent ones. I believe I remember a map on the article, and they had one or more in Poland, and some in southeast Asia, etc.
mark
On Tue, Dec 6, 2011 at 2:40 PM, m.roth@5-cent.us wrote:
But based on what we know and what we have been told and what we have worked out ourselves as well, its almost certainly bruteforced ssh passwords.
So, coincidence that they were CentOS, and pre-5.6? Did they have admins in common?
Just incompetent ones. I believe I remember a map on the article, and they had one or more in Poland, and some in southeast Asia, etc.
I'm not convinced, having seen some very sophisticated attacks here, using combinations of known low level web service exploits combined with recently published local exploits to get root access. The ones I saw used a java/structs exploit plus a glib bug that should have been fixed in 5.4, but it was pretty clear that attempts were being made in a coordinated way to use recently published vulnerabilities. Not sure what might have been left in 5.5, though.
On 12/06/2011 02:36 PM, Les Mikesell wrote:
On Tue, Dec 6, 2011 at 2:18 PM, Karanbir Singh mail-lists@karan.org wrote:
On 12/06/2011 08:09 PM, Les Mikesell wrote:
Any luck on the specific attack path yet? The linked article suggests Centos up to 5.5 was vulnerable.
We dont have access to the actual machines that were broken into - so pretty much everything is second hand info.
But based on what we know and what we have been told and what we have worked out ourselves as well, its almost certainly bruteforced ssh passwords.
So, coincidence that they were CentOS, and pre-5.6? Did they have admins in common?
Kaspersky has access to the images ... but they were mostly cleaned/erased and only what they can recover from erased ext3 files are there to see.
The attackers used something to 00000 out the files that they wanted to wipe directly ... so only things like old logs (that were deleted by logrotate and not wiped by the attackers) are on there.
There is one major possibility for something that could be an entry point besides brute force, and that is exim:
http://rhn.redhat.com/errata/RHSA-2010-0970.html
However, they do not know yet if exim was in use on those machines.
Note: CentOS released our update within 24 hours of that update from upstream ... but people who have < 5.5 and exim are vulnerable to that.
If I had to guess, I would say that the attackers probably developed their code on CentOS, so they were looking for a CentOS machine to deploy their code on in the wild. That would be why I would say CentOS was the OS used.
On Tuesday, December 06, 2011 04:45:04 PM Johnny Hughes wrote:
If I had to guess, I would say that the attackers probably developed their code on CentOS, so they were looking for a CentOS machine to deploy their code on in the wild. That would be why I would say CentOS was the OS used.
I read the Kaspersky article and the comments, and the use of 'up2date' in the transcript could possibly point to someone used to upstream EL. But it does illustrate three major points:
1.) Keep up to date as much as possible (and a 24 hour window is quite short, honestly, compared to the timeframes this attack appears to have occupied); 2.) Keep up with your servers and have tripwires for modifications; 3.) Keep good passwords. This can't be stressed enough: if your password was successfully brute-forced it is now in the brute-forcer's *dictionary* of passwords to try in the future and should never be used again, regardless of how secure it might seem. I happen to have a copy of an older brute-forcer dictionary here (somewhere) and it's very large and has lots of very secure-seeming passwords in it.
Of course, this points to a fourth (and fifth) item: don't run services you don't need, and have multiple layers of security.
Dec 7, 2011 5:58 AM Lamar Owen lowen@pari.edu 작성:
On Tuesday, December 06, 2011 04:45:04 PM Johnny Hughes wrote:
If I had to guess, I would say that the attackers probably developed their code on CentOS, so they were looking for a CentOS machine to deploy their code on in the wild. That would be why I would say CentOS was the OS used.
I read the Kaspersky article and the comments, and the use of 'up2date' in the transcript could possibly point to someone used to upstream EL. But it does illustrate three major points: 3.) Keep good passwords. This can't be stressed enough: if your password was successfully brute-forced it is now in the brute-forcer's *dictionary* of passwords to try in the future and should never be used again, regardless of how secure it might seem. I happen to have a copy of an older brute-forcer dictionary here (somewhere) and it's very large and has lots of very secure-seeming passwords in it.
Why not don't allow root login from ssh? That's basic yet effective.
On Tuesday, December 06, 2011 05:31:58 PM Fajar Priyanto wrote:
Dec 7, 2011 5:58 AM Lamar Owen lowen@pari.edu 작성:
I happen to have a copy of an older brute-forcer dictionary here (somewhere) and it's very large and has lots of very secure-seeming passwords in it.
Why not don't allow root login from ssh? That's basic yet effective.
This particular brute-forcer didn't require root access to spread.
It can work under a normal user without any problem.
Dec 7, 2011 7:05 AM Lamar Owen lowen@pari.edu 작성:
On Tuesday, December 06, 2011 05:31:58 PM Fajar Priyanto wrote:
Dec 7, 2011 5:58 AM Lamar Owen lowen@pari.edu 작성:
I happen to have a copy of an older brute-forcer dictionary here (somewhere) and it's very large and has lots of very secure-seeming passwords in it.
Why not don't allow root login from ssh? That's basic yet effective.
This particular brute-forcer didn't require root access to spread.
It can work under a normal user without root....
You miss my point.
2011/12/6 Fajar Priyanto fajarpri@arinet.org:
I happen to have a copy of an older brute-forcer dictionary here (somewhere) and it's very large and has lots of very secure-seeming passwords in it.
Why not don't allow root login from ssh? That's basic yet effective.
This particular brute-forcer didn't require root access to spread.
It can work under a normal user without root....
You miss my point.
I'd expect it to be at least typical to firewall direct ssh access from the internet.
On Tue, 2011-12-06 at 18:12 -0600, Les Mikesell wrote:
I'd expect it to be at least typical to firewall direct ssh access from the internet.
A Linux newcomer, untrained and a self-learner, I made an abrupt immersion into Linux on 1 June 2010. It was a steep learning-curve.
The first thing I did was to make a 20-odd character password for Root with lowercase, uppercase and digits (using my former address in Germany).
The next thing I did was to change the default SSH port number AND restrict access to 3 approved IP addresses only.
Anyone who leaves SSH on a default port open to any IP address is stupid.
Anyone not wanting to allow SSH access into their machine should consider:-
chkconfig --list|grep ssh chkconfig sshd off service sshd stop
Long, not easy to guess and totally beyond the reach of dictionary attacks, passwords for Root are absolutely essential. Security begins with a minimum password length of 12 characters for ALL users.
Rootkits are another essential.
There is a real war on. No sensible person lays down and lets the enemy walk all over them. Constant and widespread defence is vitally important. Every day I see evidence of many hacked computers all around the world. It persuades me to think many admins are simply incompetent - they seem to use Windoze.
A professional qualification in basic server security would be a useful attribute.
----- Original Message ----- | On Tue, 2011-12-06 at 18:12 -0600, Les Mikesell wrote: | | > I'd expect it to be at least typical to firewall direct ssh access | > from the internet. | | A Linux newcomer, untrained and a self-learner, I made an abrupt | immersion into Linux on 1 June 2010. It was a steep learning-curve. | | The first thing I did was to make a 20-odd character password for Root | with lowercase, uppercase and digits (using my former address in | Germany).
Great! I'll do a little Google'ing and see if I can find out what that might be. While this is great advice, I have a long password too, most users are completely incapable of remembering their 6-8 character passwords without righting them down.
| The next thing I did was to change the default SSH port number AND | restrict access to 3 approved IP addresses only.
This is good. I mean the restricting part at least. Changing the port is a joke.
| Anyone who leaves SSH on a default port open to any IP address is | stupid.
This is completely and utterly retarded. You have done *NOTHING* to secure SSH by doing this. You have instead made it only slightly, and I mean ever so slightly, more secure. A simple port scan of your network would find it within seconds and start to utilize it.
| Anyone not wanting to allow SSH access into their machine should | consider:- | | chkconfig --list|grep ssh | chkconfig sshd off | service sshd stop | | Long, not easy to guess and totally beyond the reach of dictionary | attacks, passwords for Root are absolutely essential. Security begins | with a minimum password length of 12 characters for ALL users.
Good advice for sure, but not allowing password log in through SSH at all, instead relying on Public/Private keys (preferably those with passwords), would be much better.
| Rootkits are another essential.
Yes. I love it when my machines have rootkits! I think you meant rootkit detectors. LOL.
| There is a real war on. No sensible person lays down and lets the | enemy | walk all over them. Constant and widespread defence is vitally | important. Every day I see evidence of many hacked computers all | around | the world. It persuades me to think many admins are simply incompetent | - | they seem to use Windoze.
Admins are not the incompetent ones. The users are! Any decent admin is going to ensure that there are the most layers and defensive systems in place to ensure a level of security that doesn't require the *USERS* to be rocket scientists. Security is all about balance not magic bullets. Having systems in place that protect the systems while not getting terribly in the way. This BS about Windows (Windoze, Window$, etc) is just that BS. I know many *VERY GOOD* Windows admins. A bad admin is a bad admin no matter what platform you put them in front of.
| A professional qualification in basic server security would be a | useful | attribute.
A basic qualification to operate a computer would also be nice. Sad thing is, there is no such thing.
On Tue, Dec 6, 2011 at 7:06 PM, James A. Peltier jpeltier@sfu.ca wrote:
Admins are not the incompetent ones. The users are! Any decent admin is going to ensure that there are the most layers and defensive systems in place to ensure a level of security that doesn't require the *USERS* to be rocket scientists. Security is all about balance not magic bullets. Having systems in place that protect the systems while not getting terribly in the way.
Security should also be about assuming that any/all complex software has exploitable flaws that you don't know about yet. If you aren't convinced, just look back through the changelogs of just about every program that has network access, kernel interactions, or runs suid or as root. And security is very much about keeping your system updated with the fixes for those flaws as quickly as possible when they are discovered.
This BS about Windows (Windoze, Window$, etc) is just that BS. I know many *VERY GOOD* Windows admins. A bad admin is a bad admin no matter what platform you put them in front of.
There's a historical reason for that bias, since early windows versions weren't designed with network security in mind - but current versions are much better. So again, staying up to date is the key.
| A professional qualification in basic server security would be a | useful | attribute.
A basic qualification to operate a computer would also be nice. Sad thing is, there is no such thing.
And if there were, it would always be out of date.
On Tue, 2011-12-06 at 17:06 -0800, James A. Peltier wrote:
| The first thing I did was to make a 20-odd character password for Root | with lowercase, uppercase and digits (using my former address in | Germany).
Great! I'll do a little Google'ing and see if I can find out what that might be. While this is great advice, I have a long password too, most users are completely incapable of remembering their 6-8 character passwords without righting them down.
Don't judge everyone by your own standards. You will be wasting your time. Do you really think I would put on here anything that might compromise my servers' security ???? That address is 30+ years old and I had several addresses in der BRD.
The point about using an address for a password is - it is easy to remember even when substituting lowercase for uppercase and digits for letters. AND it is also LONGER than 6 characters.
| The next thing I did was to change the default SSH port number AND | restrict access to 3 approved IP addresses only.
This is good. I mean the restricting part at least. Changing the port is a joke.
Leaving it with the original port number is surely like waving a flag saying 'Open for Business'. At least make some effort.
| Anyone who leaves SSH on a default port open to any IP address is | stupid.
This is completely and utterly retarded. You have done *NOTHING* to secure SSH by doing this. You have instead made it only slightly, and I mean ever so slightly, more secure. A simple port scan of your network would find it within seconds and start to utilize it.
No. Your interpretation of what I wrote is defective. I never wrote it was the ONLY action, did I ????
| Anyone not wanting to allow SSH access into their machine should | consider:- | | chkconfig --list|grep ssh | chkconfig sshd off | service sshd stop | | Long, not easy to guess and totally beyond the reach of dictionary | attacks, passwords for Root are absolutely essential. Security begins | with a minimum password length of 12 characters for ALL users.
Good advice for sure, but not allowing password log in through SSH at all, instead relying on Public/Private keys (preferably those with passwords), would be much better.
Doing that already. I never said my posting contained everything I do.
| Rootkits are another essential.
Yes. I love it when my machines have rootkits! I think you meant rootkit detectors. LOL.
Agreed :-)
| There is a real war on. No sensible person lays down and lets the | enemy | walk all over them. Constant and widespread defence is vitally | important. Every day I see evidence of many hacked computers all | around | the world. It persuades me to think many admins are simply incompetent | - | they seem to use Windoze.
Admins are not the incompetent ones.
Some clearly are. Allowing machines to be used to send spam and launch web hacking attacks is something no competent admin should do. Admins first job, these days, is to make their machines secure and invasion resilient.
The users are! Any decent admin is going to ensure that there are the most layers and defensive systems in place to ensure a level of security that doesn't require the *USERS* to be rocket scientists.
Don't blame ignorant users for the omissions of the security responsible admins !
Security is all about balance not magic bullets. Having systems in place that protect the systems while not getting terribly in the way. This BS about Windows (Windoze, Window$, etc) is just that BS. I know many *VERY GOOD* Windows admins. A bad admin is a bad admin no matter what platform you put them in front of.
Security these days is not about an abstract illusion called 'balance'. It is about vigilant and vigorous defence because there is a real war going on every minute of every day.
Most hacked/compromised machines are Windoze especially servers.
| A professional qualification in basic server security would be a | useful attribute.
A basic qualification to operate a computer would also be nice. Sad thing is, there is no such thing.
Employers will welcome learning their computer staff have a Computer Security qualification. Eventually it should be more difficult for those lacking it to get jobs.
Whilst Windoze is primarily a system for playing-on, rather than doing serious work, your comment 'A basic qualification to operate a computer would also be nice.' is never going to happen.
On Tuesday, December 06, 2011 08:06:55 PM James A. Peltier wrote:
[Changing the port #] is completely and utterly retarded. You have done *NOTHING* to secure SSH by doing this. You have instead made it only slightly, and I mean ever so slightly, more secure. A simple port scan of your network would find it within seconds and start to utilize it.
Simple port scans don't scan all 65,536 possible port numbers; those scans are a bit too easy for IDS detection and mitigation. Most scans only scan common ports; the ssh brute-forcer I found in the wild only scanned port 22; if it wasn't open, it went on to the next IP address.
Unusual port numbers, port knocking, and similar techniques obfuscate things enough to eliminate the 'honest' script-kiddie (that is, the one that doesn't know any more that what the log of the brute-forcer I found showed, that the kiddie was going by a rote script, including trying to download and install a *windows 2000 service pack* on the Linux server in question). This will cut down the IDS noise, that's for sure. And cutting down the information overload for the one tasked with reading those logs is important.
Of course, it could be argued that if you have port 22 open and you get those kiddies, you can block all access from those addresses with something like fail2ban (and pipe into your border router's ACL, if that ACL table has enough entries available.....).
A basic qualification to operate a computer would also be nice. Sad thing is, there is no such thing.
Microsoft has proposed such... of course, the prerequisites would likely include running the latest Windows....
If you get an 'Internet driver's license' you then have to have a licensing authority, and any time you get that sort of thing involved.... well, you can imagine how it could pan out.
On Wed, 2011-12-07 at 07:07 -0500, Lamar Owen wrote:
On Tuesday, December 06, 2011 08:06:55 PM James A. Peltier wrote:
A basic qualification to operate a computer would also be nice. Sad thing is, there is no such thing.
Microsoft has proposed such... of course, the prerequisites would likely include running the latest Windows....
If you get an 'Internet driver's license' you then have to have a licensing authority, and any time you get that sort of thing involved.... well, you can imagine how it could pan out.
BUT every country has unlicensed drivers !
It is in the economic interests of every country, world wide, to prevent computer hacking, invasion of computer systems and the inevitable abuse of computer facilities.
Even if only some of the sys admins became proficient in basic server security it would be a de facto improvement. What is needed is a web site offering free lessons on how to secure servers. An ideal task for a willing and knowledge Linux volunteer with help from non-English speakers translating the information into their language.
Centos is probably the most widely used operating system for servers. Data centres offer Centos to every Tom, Dick & Harry and even Eva & Ida too - usually it for VPS. This means Linux newcomers are using it.
My experience is most hacking attacks, mail and web, come from VPSs in Data Centres - the cheaper the hire cost, the more likely it is used.
Therefore these unknown newcomers to Linux would benefit from a few basics. At present they have to hunt for the information.
If a basic security web site, internally recognised and endorsed by governments (and no Ads) existed offering basic security information for Linux servers, I am reasonably confident many ISPs would point their server users to it - all flavours of Linux users.
The common good, and how it can be greatly improved, should concern all of us. The solution is amazingly simple. Propagation of the web site's existence is harder but with press, government, Usenet, Twitter, Facebook etc. a vast improvement to the status quo can be achieved for the benefit of all except the hackers and attackers.
The essential aspect of this suggestion is such a web site must be Linux non-denominational. Centos fans working with Ubuntu fans working with other flavours too including Red Hat et al. A genuine community Enterprise benefiting the entire community.
On Wednesday, December 07, 2011 07:37:34 AM Always Learning wrote: ...
The essential aspect of this suggestion is such a web site must be Linux non-denominational. Centos fans working with Ubuntu fans working with other flavours too including Red Hat et al. A genuine community Enterprise benefiting the entire community.
I've left this paragraph in; I could have chosen any paragraph, though.
Such tutorials exist; most of the really good ones are not freely available, though. SANS.org is one place to look, and where you can purchase training in various security things. Sites like packetstormsecurity.org have lots of files, including whitepapers and such, but finding what you need can be difficult.
I have found that the difficulty with free tutorials, whether it's at howtoforge or elsewhere, is that the author is going to write about the system they are using; and you can't expect otherwise from a free tutorial. You have to translate to your own setup, and/or you have to do things the standard way. Well, unless the author has an 'agenda' for a particular way of doing things, and virtually all do, even if they're not aware of it.
That in and of itself is one of the biggest mistakes admins make: they have a 'preferred way' of doing things, but that preferred way may not be the way that is most secure on that particular distribution.
On Wed, Dec 07, 2011 at 07:07:33AM -0500, Lamar Owen wrote:
On Tuesday, December 06, 2011 08:06:55 PM James A. Peltier wrote:
[Changing the port #] is completely and utterly retarded. You have
done *NOTHING* to secure SSH by doing this. You have instead made it only slightly, and I mean ever so slightly, more secure. A simple port scan of your network would find it within seconds and start to utilize it.
Simple port scans don't scan all 65,536 possible port numbers; those scans are a bit too easy for IDS detection and mitigation. Most scans only scan common ports; the ssh brute-forcer I found in the wild only scanned port 22; if it wasn't open, it went on to the next IP address.
In theory James is correct. In practice Lamar appears to be. About a year back I changed my ssh port and have not since seen password hack attempts, so the port scanners are definitely not pervasively scanning all ports. (Not that they'd have logged in; but it was causing noise and annoyance in the logs)
Now the same wouldn't be true if I was managing firewalls for Chase or Bank Of America or Citi or HSBC; you can be sure that they're being scanned on all ports and better not have external ssh connections open to the world!
On 12/07/2011 08:17 AM, Stephen Harris wrote:
On Wed, Dec 07, 2011 at 07:07:33AM -0500, Lamar Owen wrote:
On Tuesday, December 06, 2011 08:06:55 PM James A. Peltier wrote:
[Changing the port #] is completely and utterly retarded. You have
done *NOTHING* to secure SSH by doing this. You have instead made it only slightly, and I mean ever so slightly, more secure. A simple port scan of your network would find it within seconds and start to utilize it.
Simple port scans don't scan all 65,536 possible port numbers; those scans are a bit too easy for IDS detection and mitigation. Most scans only scan common ports; the ssh brute-forcer I found in the wild only scanned port 22; if it wasn't open, it went on to the next IP address.
In theory James is correct. In practice Lamar appears to be. About a year back I changed my ssh port and have not since seen password hack attempts, so the port scanners are definitely not pervasively scanning all ports. (Not that they'd have logged in; but it was causing noise and annoyance in the logs)
Now the same wouldn't be true if I was managing firewalls for Chase or Bank Of America or Citi or HSBC; you can be sure that they're being scanned on all ports and better not have external ssh connections open to the world!
Right ... they need a reason to look somewhere else. If they specifically wanted that machine, they would scan all ports. If they are drive bye script kiddies, then if it is not on port 22 that will cut down significantly on the drive byes.
Lots of times, they look for a port 22 open to back later, etc.
So, Lamar is correct. It does not do anything to prevent a determined attack ... but it does greatly reduce the chance someone will randomly pick your machine for an attack.
On 12/7/2011 7:07 AM, Lamar Owen wrote:
On Tuesday, December 06, 2011 08:06:55 PM James A. Peltier wrote:
[Changing the port #] is completely and utterly retarded. You have done *NOTHING* to secure SSH by doing this. You have instead made it only slightly, and I mean ever so slightly, more secure. A simple port scan of your network would find it within seconds and start to utilize it.
Simple port scans don't scan all 65,536 possible port numbers; those scans are a bit too easy for IDS detection and mitigation. Most scans only scan common ports; the ssh brute-forcer I found in the wild only scanned port 22; if it wasn't open, it went on to the next IP address.
Unusual port numbers, port knocking, and similar techniques obfuscate things enough to eliminate the 'honest' script-kiddie (that is, the one that doesn't know any more that what the log of the brute-forcer I found showed, that the kiddie was going by a rote script, including trying to download and install a *windows 2000 service pack* on the Linux server in question). This will cut down the IDS noise, that's for sure. And cutting down the information overload for the one tasked with reading those logs is important.
Of course, it could be argued that if you have port 22 open and you get those kiddies, you can block all access from those addresses with something like fail2ban (and pipe into your border router's ACL, if that ACL table has enough entries available.....).
Now there's an idea. Run your SSH server on a non-standard port and put something on port 22 that does nothing but listen for connections and then block any IP that tries to connect (via fail2ban or whatever). That way the script kiddies have no chance of getting in on port 22 and anyone who tries is now blocked on all ports or even blocked from the entire network.
Vreme: 12/07/2011 03:37 PM, Bowie Bailey piše:
On 12/7/2011 7:07 AM, Lamar Owen wrote:
On Tuesday, December 06, 2011 08:06:55 PM James A. Peltier wrote:
[Changing the port #] is completely and utterly retarded. You have done *NOTHING* to secure SSH by doing this. You have instead made it only slightly, and I mean ever so slightly, more secure. A simple port scan of your network would find it within seconds and start to utilize it.
Simple port scans don't scan all 65,536 possible port numbers; those scans are a bit too easy for IDS detection and mitigation. Most scans only scan common ports; the ssh brute-forcer I found in the wild only scanned port 22; if it wasn't open, it went on to the next IP address.
Unusual port numbers, port knocking, and similar techniques obfuscate things enough to eliminate the 'honest' script-kiddie (that is, the one that doesn't know any more that what the log of the brute-forcer I found showed, that the kiddie was going by a rote script, including trying to download and install a *windows 2000 service pack* on the Linux server in question). This will cut down the IDS noise, that's for sure. And cutting down the information overload for the one tasked with reading those logs is important.
Of course, it could be argued that if you have port 22 open and you get those kiddies, you can block all access from those addresses with something like fail2ban (and pipe into your border router's ACL, if that ACL table has enough entries available.....).
Now there's an idea. Run your SSH server on a non-standard port and put something on port 22 that does nothing but listen for connections and then block any IP that tries to connect (via fail2ban or whatever). That way the script kiddies have no chance of getting in on port 22 and anyone who tries is now blocked on all ports or even blocked from the entire network.
Better yet. sshd could be upgraded to have dummy daemon on port 22. He will accept connections, ask for password but will not be able to resolve any usernames. Now THAT would be something.
On Wed, Dec 7, 2011 at 10:12 AM, Ljubomir Ljubojevic office@plnet.rs wrote:
Better yet. sshd could be upgraded to have dummy daemon on port 22. He will accept connections, ask for password but will not be able to resolve any usernames. Now THAT would be something.
Or, it could simply rate-limit failures with logging/notifications to make brute force attacks difficult and visible.
On 12/07/11 8:12 AM, Ljubomir Ljubojevic wrote:
Better yet. sshd could be upgraded to have dummy daemon on port 22. He will accept connections, ask for password but will not be able to resolve any usernames. Now THAT would be something.
heh. connect port 22 to a honeypot running in a VM that has a hacked openssl that delays every packet response by 15 or 20 seconds... heck, delay the SYN-ACK's and such too. :)
anyways, this is getting very far afield for a centos specific list, and should instead be discussed on a security list or forum somewhere.
On 12/07/2011 06:59 PM, John R Pierce wrote:
anyways, this is getting very far afield for a centos specific list, and should instead be discussed on a security list or forum somewhere.
I've said this in the past as well - we have some super talent on this list when it comes to admin / management / process and policy - we should setup a list to focus on just that.....
- KB
Vreme: 12/07/2011 01:45 AM, Always Learning piše:
The first thing I did was to make a 20-odd character password for Root with lowercase, uppercase and digits (using my former address in Germany).
I like using serial numbers from Motherboards and other hardware. It's more random.
Op Woensdag, 7 december 03:45 +0100, Ljubomir Ljubojevic wrote:
Vreme: 12/07/2011 01:45 AM, Always Learning piše:
The first thing I did was to make a 20-odd character password for Root with lowercase, uppercase and digits (using my former address in Germany).
I like using serial numbers from Motherboards and other hardware. It's more random.
The important thing about passwords is being ABLE TO REMEMBER them without writing the password anywhere. People can remember old addresses easier than motherboard serial numbers.
Vreme: 12/07/2011 03:49 AM, Always Learning piše:
Op Woensdag, 7 december 03:45 +0100, Ljubomir Ljubojevic wrote:
Vreme: 12/07/2011 01:45 AM, Always Learning piše:
The first thing I did was to make a 20-odd character password for Root with lowercase, uppercase and digits (using my former address in Germany).
I like using serial numbers from Motherboards and other hardware. It's more random.
The important thing about passwords is being ABLE TO REMEMBER them without writing the password anywhere. People can remember old addresses easier than motherboard serial numbers.
I have no problem remembering 8-10 character password after several uses. And my brother at first wrote them down in his phone, and then just remembered.
If you lose the phone, or the paper you wrote it on, it will not help the attackers from across the globe. If your password is search-able on the internet....
This advice is good for small admins. If you might be victim of the industrial or governmental espionage, then you better be smart enough to remember your passwords.
On 12/6/2011 7:12 PM, Les Mikesell wrote:
2011/12/6 Fajar Priyantofajarpri@arinet.org:
I happen to have a copy of an older brute-forcer dictionary here (somewhere) and it's very large and has lots of very secure-seeming passwords in it.
Why not don't allow root login from ssh? That's basic yet effective.
This particular brute-forcer didn't require root access to spread.
It can work under a normal user without root....
You miss my point.
I'd expect it to be at least typical to firewall direct ssh access from the internet.
This thread is mostly speculation. My 'other speculation' is that this 'could have been' a disgruntled employee. Someone that had root and also a user on the system. It 'could have been' that the user was not removed and the root pass not changed. Simple as that.... no break in per se, but just bad policies. If they were a couple of versions back on updates, there were other bad policies... but I think we 'speculated' on that as well?
Further 'speculation' on this is just more CentOS list garbage unless someone can provide details on what exactly did happen. More than likely some inside C&C do have ideas, but are likely too embarrassed to say it.
Humans are lazy if they can be. Over time, complacent. Look at xBox. Now this. And even if you do run a perfect system, just like with a new virus... somebody has to get it first to turn it in for a signature to be written. A certain number of people will get that virus.... a certain number of servers will get exploited before patches are issued and the delay of putting them into place. Black hats work just as hard as gray hats and white hats and maybe harder.
You will never stop crime... you will never stop terrorism... you can only do what you can to limit it without bankrupting yourself (in time or money) in the process, and try to be prepared for when it hits.
So, when is CentOS 7.0 going to be ready? ;)
On Tuesday, December 06, 2011 04:58:42 PM Lamar Owen wrote:
I happen to have a copy of an older brute-forcer dictionary here (somewhere) and it's very large and has lots of very secure-seeming passwords in it.
I ran down the copy I have; here's an excerpt of one of the dictionaries: ++++++++ root:P7zkJTma root:5D8DY22 root:mc99ZR34Z root:IVEUFc root:JJc9DicA root:zzzzzzz root:4m3ric4n root:3nglish root:g0v3rm3nt root:4zur3 root:bl4ck root:blu3 root:br0wn root:cy4n root:crims0n root:d4rkblu3 root:d4rk root:g0ld ++++++++
Yeah, some of those would ordinarily be relatively secure-seeming passwords.
In the copy I have, there are 5 dictionaries, totalling 68,915 username/password pairs.
The brute-forcer this was taken from does not require root, it can run on any user.
Look for a directory named '.joker' on your filesystems; you might find the one I found.....
Lamar Owen wrote:
On Tuesday, December 06, 2011 04:58:42 PM Lamar Owen wrote:
I happen to have a copy of an older brute-forcer dictionary here (somewhere) and it's very large and has lots of very secure-seeming passwords in it.
I ran down the copy I have; here's an excerpt of one of the dictionaries: ++++++++ root:P7zkJTma root:5D8DY22 root:mc99ZR34Z root:IVEUFc root:JJc9DicA root:zzzzzzz root:4m3ric4n root:3nglish root:g0v3rm3nt root:4zur3 root:bl4ck root:blu3 root:br0wn root:cy4n root:crims0n root:d4rkblu3 root:d4rk root:g0ld ++++++++
Yeah, some of those would ordinarily be relatively secure-seeming passwords.
alphanumeric only isn't so secure-seeming is it? Is this for admins who log in with a cell phone instead of a real keyboard? ;-) seriously: I thought the consensus was that a secure password should contain at least one or more non-alphanumeric characters.
On 12/07/2011 03:59 AM, Nicolas Thierry-Mieg wrote:
Lamar Owen wrote:
On Tuesday, December 06, 2011 04:58:42 PM Lamar Owen wrote:
I happen to have a copy of an older brute-forcer dictionary here (somewhere) and it's very large and has lots of very secure-seeming passwords in it.
I ran down the copy I have; here's an excerpt of one of the dictionaries: ++++++++ root:P7zkJTma root:5D8DY22 root:mc99ZR34Z root:IVEUFc root:JJc9DicA root:zzzzzzz root:4m3ric4n root:3nglish root:g0v3rm3nt root:4zur3 root:bl4ck root:blu3 root:br0wn root:cy4n root:crims0n root:d4rkblu3 root:d4rk root:g0ld ++++++++
Yeah, some of those would ordinarily be relatively secure-seeming passwords.
alphanumeric only isn't so secure-seeming is it? Is this for admins who log in with a cell phone instead of a real keyboard? ;-) seriously: I thought the consensus was that a secure password should contain at least one or more non-alphanumeric characters.
The real bottom line is that the only way you should allow access to your machine is via keys ... having an ssh port exposed to the internet that allows password logins is, at some point, going to be breached if someone wants to breach it.
You could substitute a | or a ! for some i's in the above passwords and the brute force checker will find those as well.
The real issue is that passwords are not going to cut it as your primary security measure to keep people out.
You need to limit the ssh port to allowed IP addresses (or subnets), you need to use keys (maybe even keys with pins as secondary option for more security) to access that "IP address controlled" ssh port, and you need to turn off remote root access and allow access from other users who need to run sudo to get root.
If you leave a password controlled ssh port that allows root login exposed to the Internet, then the only reason it is not breached is that someone has not yet had a desire to breach it.
Vreme: 12/07/2011 11:12 AM, Johnny Hughes piše:
On 12/07/2011 03:59 AM, Nicolas Thierry-Mieg wrote:
Lamar Owen wrote:
On Tuesday, December 06, 2011 04:58:42 PM Lamar Owen wrote:
I happen to have a copy of an older brute-forcer dictionary here (somewhere) and it's very large and has lots of very secure-seeming passwords in it.
I ran down the copy I have; here's an excerpt of one of the dictionaries: ++++++++ root:P7zkJTma root:5D8DY22 root:mc99ZR34Z root:IVEUFc root:JJc9DicA root:zzzzzzz root:4m3ric4n root:3nglish root:g0v3rm3nt root:4zur3 root:bl4ck root:blu3 root:br0wn root:cy4n root:crims0n root:d4rkblu3 root:d4rk root:g0ld ++++++++
Yeah, some of those would ordinarily be relatively secure-seeming passwords.
alphanumeric only isn't so secure-seeming is it? Is this for admins who log in with a cell phone instead of a real keyboard? ;-) seriously: I thought the consensus was that a secure password should contain at least one or more non-alphanumeric characters.
The real bottom line is that the only way you should allow access to your machine is via keys ... having an ssh port exposed to the internet that allows password logins is, at some point, going to be breached if someone wants to breach it.
You could substitute a | or a ! for some i's in the above passwords and the brute force checker will find those as well.
The real issue is that passwords are not going to cut it as your primary security measure to keep people out.
You need to limit the ssh port to allowed IP addresses (or subnets), you need to use keys (maybe even keys with pins as secondary option for more security) to access that "IP address controlled" ssh port, and you need to turn off remote root access and allow access from other users who need to run sudo to get root.
If you leave a password controlled ssh port that allows root login exposed to the Internet, then the only reason it is not breached is that someone has not yet had a desire to breach it.
There is also use of denyhosts and fail2ban. They allow only few attempts from one IP, and all users can share attacking IP's (default is every 30 min) so you are automatically protected from known attacking IP's. Any downside on this protection?
On 12/07/2011 04:32 AM, Ljubomir Ljubojevic wrote:
Vreme: 12/07/2011 11:12 AM, Johnny Hughes piše:
On 12/07/2011 03:59 AM, Nicolas Thierry-Mieg wrote:
Lamar Owen wrote:
On Tuesday, December 06, 2011 04:58:42 PM Lamar Owen wrote:
I happen to have a copy of an older brute-forcer dictionary here (somewhere) and it's very large and has lots of very secure-seeming passwords in it.
I ran down the copy I have; here's an excerpt of one of the dictionaries: ++++++++ root:P7zkJTma root:5D8DY22 root:mc99ZR34Z root:IVEUFc root:JJc9DicA root:zzzzzzz root:4m3ric4n root:3nglish root:g0v3rm3nt root:4zur3 root:bl4ck root:blu3 root:br0wn root:cy4n root:crims0n root:d4rkblu3 root:d4rk root:g0ld ++++++++
Yeah, some of those would ordinarily be relatively secure-seeming passwords.
alphanumeric only isn't so secure-seeming is it? Is this for admins who log in with a cell phone instead of a real keyboard? ;-) seriously: I thought the consensus was that a secure password should contain at least one or more non-alphanumeric characters.
The real bottom line is that the only way you should allow access to your machine is via keys ... having an ssh port exposed to the internet that allows password logins is, at some point, going to be breached if someone wants to breach it.
You could substitute a | or a ! for some i's in the above passwords and the brute force checker will find those as well.
The real issue is that passwords are not going to cut it as your primary security measure to keep people out.
You need to limit the ssh port to allowed IP addresses (or subnets), you need to use keys (maybe even keys with pins as secondary option for more security) to access that "IP address controlled" ssh port, and you need to turn off remote root access and allow access from other users who need to run sudo to get root.
If you leave a password controlled ssh port that allows root login exposed to the Internet, then the only reason it is not breached is that someone has not yet had a desire to breach it.
There is also use of denyhosts and fail2ban. They allow only few attempts from one IP, and all users can share attacking IP's (default is every 30 min) so you are automatically protected from known attacking IP's. Any downside on this protection?
No downside, and they do work.
On 12/07/2011 04:32 AM, Ljubomir Ljubojevic wrote:
There is also use of denyhosts and fail2ban. They allow only few attempts from one IP, and all users can share attacking IP's (default is every 30 min) so you are automatically protected from known attacking IP's. Any downside on this protection?
Which is better for C 5.7 and C 6.x ?
Vreme: 12/07/2011 12:53 PM, Always Learning piše:
On 12/07/2011 04:32 AM, Ljubomir Ljubojevic wrote:
There is also use of denyhosts and fail2ban. They allow only few attempts from one IP, and all users can share attacking IP's (default is every 30 min) so you are automatically protected from known attacking IP's. Any downside on this protection?
Which is better for C 5.7 and C 6.x ?
I personally use denyhosts, it felt better when I installed if several years ago. Cant even remember why I thought it better.
It is best to read about it's features and configuration and choose for your self. They are both good and secure, just have design differences.
On Wed, 2011-12-07 at 12:59 +0100, Ljubomir Ljubojevic wrote:
Vreme: 12/07/2011 12:53 PM, Always Learning piše:
On 12/07/2011 04:32 AM, Ljubomir Ljubojevic wrote:
There is also use of denyhosts and fail2ban. They allow only few attempts from one IP, and all users can share attacking IP's (default is every 30 min) so you are automatically protected from known attacking IP's. Any downside on this protection?
Which is better for C 5.7 and C 6.x ?
I personally use denyhosts, it felt better when I installed if several years ago. Cant even remember why I thought it better.
It is best to read about it's features and configuration and choose for your self. They are both good and secure, just have design differences.
Thank you.
Paul.
On Dec 7, 2011, at 4:49 AM, Johnny Hughes wrote:
There is also use of denyhosts and fail2ban. They allow only few attempts from one IP, and all users can share attacking IP's (default is every 30 min) so you are automatically protected from known attacking IP's. Any downside on this protection?
No downside, and they do work.
---- I am a true believer and use denyhosts everywhere but to say there is no downside, that's not entirely true - I had a co-worker who was dyslexic, and you would be surprised how often he locked himself out ;-) Honestly, I don't know how he got a college degree in CIS being as dyslexic as he was.
Craig
Vreme: 12/07/2011 06:29 PM, Craig White piše:
On Dec 7, 2011, at 4:49 AM, Johnny Hughes wrote:
There is also use of denyhosts and fail2ban. They allow only few attempts from one IP, and all users can share attacking IP's (default is every 30 min) so you are automatically protected from known attacking IP's. Any downside on this protection?
No downside, and they do work.
I am a true believer and use denyhosts everywhere but to say there is no downside, that's not entirely true - I had a co-worker who was dyslexic, and you would be surprised how often he locked himself out ;-) Honestly, I don't know how he got a college degree in CIS being as dyslexic as he was.
hehehe. I whitelisted my internal IP's and other friendly IP's like other networks I maintain (and made secure :-) ).
On Wednesday, December 07, 2011 05:32:00 AM Ljubomir Ljubojevic wrote:
There is also use of denyhosts and fail2ban. They allow only few attempts from one IP, and all users can share attacking IP's (default is every 30 min) so you are automatically protected from known attacking IP's. Any downside on this protection?
Botnets. If a 100,000 host botnet hits you with a coordinated brute-force attack, fail2ban and other similar tools won't help you, as every attempt will come from a different host. This may be one way the brute-forcers appear to get in on the first or second try. And some brute-forcers are the so-called 'slow' brute-forcers that try things very slowly and never trigger some of these protections.
And don't let your guard down just because you have disabled password login and have key-based auth; if a remote exec breach is found in a different daemon that can write (or can execute a local root exploit that can then write) to /etc/ssh/sshd_config, it's game over. This is where SELinux in enforcing mode with properly configured contexts and no unconfined users can save the day. Attach access rights to sshd_config to a local console user or similar (that's one thing ConsoleKit and PolicyKit are for) and make certain other files are not writeable remotely as well.
Don't let your guard down because you have things firewalled, either. As RSA found out the hard way, all it takes is one employee opening one excel attachment with an embedded flash exploit, and 'blammo' you're pwned.
And if you think these sorts of contrivances aren't out in the wild, think again.
I have an example from the 'wild' that, once I have all the data in hand and permission to release it, will blow your mind.
On 7 December 2011 12:46, Lamar Owen lowen@pari.edu wrote:
On Wednesday, December 07, 2011 05:32:00 AM Ljubomir Ljubojevic wrote:
There is also use of denyhosts and fail2ban. They allow only few attempts from one IP, and all users can share attacking IP's (default is every 30 min) so you are automatically protected from known attacking IP's. Any downside on this protection?
Botnets. If a 100,000 host botnet hits you with a coordinated brute-force attack, fail2ban and other similar tools won't help you, as every attempt will come from a different host. This may be one way the brute-forcers appear to get in on the first or second try. And some brute-forcers are the so-called 'slow' brute-forcers that try things very slowly and never trigger some of these protections.
And don't let your guard down just because you have disabled password login and have key-based auth; if a remote exec breach is found in a different daemon that can write (or can execute a local root exploit that can then write) to /etc/ssh/sshd_config, it's game over. This is where SELinux in enforcing mode with properly configured contexts and no unconfined users can save the day. Attach access rights to sshd_config to a local console user or similar (that's one thing ConsoleKit and PolicyKit are for) and make certain other files are not writeable remotely as well.
For passwords get g0tm1lk's list to check out what you use.
http://g0tmi1k.blogspot.com/2011/06/dictionaries-wordlists.html
SELinux is great but didn't save Russell Coker from having his play machine owned with the vmsplice exploit.
http://etbe.coker.com.au/2008/04/03/trust-and-play-machine/ http://www.coker.com.au/selinux/play.html
RSA also showed that social engineering is still an excellent vector.
http://www.f-secure.com/weblog/archives/00002226.html
-the offending exploit had to be retrieved from the spam folder prior to being opened spear phishing ftw
Ultimately you could be running OpenBSD in a datacentre with all manners of precautions yet if the attacker can blag his/her way in then your data is still all gone. It'll cost them a *lot* more money than running autopwn against /8s but the pay off will be higher.
Rigorous patching, non-default ports, key based authentication, fail2ban/denyhosts, port knocking, SELinux &c are useful in increasing the cost of breaking into boxen above the (drive-by/skiddie) breakpoint of almost free but from that point onwards you need to balance potential cost of break-in against cost of prevention.
mike
On Wednesday, December 07, 2011 10:44:10 AM Michael Simpson wrote:
SELinux is great but didn't save Russell Coker from having his play machine owned with the vmsplice exploit.
http://etbe.coker.com.au/2008/04/03/trust-and-play-machine/ http://www.coker.com.au/selinux/play.html
In this particular instance, the 2.6.23 kernel introduced a setting that is a workaround for the general NULL dereference to page zero case, and it requires SELinux to be in enforcing mode to work. Whether upstream backported that to 2.6.18 (in EL5) or not, I don't know. That fix is assuredly in the EL6 2.6.32+patches kernel. April 2008 is a long time ago in terms of SELinux. Russell is quite the brave soul for doing this sort of thing.
Nothing is 100%, of course. That is a given.
RSA also showed that social engineering is still an excellent vector.
Social engineering is the biggest problem, bar none.
Rigorous patching, non-default ports, key based authentication, fail2ban/denyhosts, port knocking, SELinux &c are useful in increasing the cost of breaking into boxen above the (drive-by/skiddie) breakpoint of almost free but from that point onwards you need to balance potential cost of break-in against cost of prevention.
You cannot prevent an intrusion; you can only slow it down. If you make it too slow to be useful, then you can have a chance at being relatively secure. Make it cost the attacker, too, as they are also looking at a cost/benefit balance sheet.
On Wednesday, December 07, 2011 04:59:52 AM Nicolas Thierry-Mieg wrote:
alphanumeric only isn't so secure-seeming is it? Is this for admins who log in with a cell phone instead of a real keyboard? ;-) seriously: I thought the consensus was that a secure password should contain at least one or more non-alphanumeric characters.
Further down in the password files some 'patterned' symbol passwords are to be found, for more than the root user. Things like the obvious: p@ssw0rd !@#$% let!ME!in T!m0+#y (Timothy, if you haven't figured it out, and it just so happened that it was paired with the username 'timothy' ala slashdot).
And there were various iterations of those, with differing lengths and such. But I'll emphasize that the one I found was very rudimentary, and I found it several years ago. Algorithmic brute-forcers can be much more sophisticated than that.
I also found in the searches that I made that there have been numerous instances of the first password tried working and getting in. I have to wonder if the chosen user is based on a leak of information from something like a web forum, or a hotmail account, or something else that has gotten hacked. Don't reuse passwords, in other words. (easier said than done, unfortunately).
Basically, if any account you have is ever compromised through password login, assume that password has made it into someone's dictionary. And I'm not talking just ssh accounts here. I'm thinking about the large e-mail/password lists recently released by lulzsec, for instance. The blackhats I'm sure have many more such lists that haven't been exposed yet.
And I agree with Johnny (and others) that disabling password auth and using keys for SSH access is a way to go; the fly in that ointment is mitigating private key loss and having a mechanism in place to rapidly revoke keys in a secure manner.
That and other avenues of access are used that involve web applications, etc, that bypass SSH-oriented controls.
Two-factor auth is better; but even that is foolable (biometrics, even; Mythbusters defeated simple fingerprint scanners several years ago.....).
Layered security works best; but 'working best' doesn't mean '100% effective.'
On Tue, 2011-12-06 at 16:58 -0500, Lamar Owen wrote:
On Tuesday, December 06, 2011 04:45:04 PM Johnny Hughes wrote: 1.) Keep up to date as much as possible (and a 24 hour window is quite short, honestly, compared to the timeframes this attack appears to have occupied); 2.) Keep up with your servers and have tripwires for modifications; 3.) Keep good passwords.
Disable password authentication.
On Tue, Dec 6, 2011 at 3:45 PM, Johnny Hughes johnny@centos.org wrote:
Any luck on the specific attack path yet? The linked article suggests Centos up to 5.5 was vulnerable.
We dont have access to the actual machines that were broken into - so pretty much everything is second hand info.
But based on what we know and what we have been told and what we have worked out ourselves as well, its almost certainly bruteforced ssh passwords.
So, coincidence that they were CentOS, and pre-5.6? Did they have admins in common?
Kaspersky has access to the images ... but they were mostly cleaned/erased and only what they can recover from erased ext3 files are there to see.
The attackers used something to 00000 out the files that they wanted to wipe directly ... so only things like old logs (that were deleted by logrotate and not wiped by the attackers) are on there.
There is one major possibility for something that could be an entry point besides brute force, and that is exim:
http://rhn.redhat.com/errata/RHSA-2010-0970.html
However, they do not know yet if exim was in use on those machines.
Note: CentOS released our update within 24 hours of that update from upstream ... but people who have < 5.5 and exim are vulnerable to that.
Does this circle get any wider if you assume that some 3rd party library (like the old struts exploit I mentioned) in a web app allows some arbitrary command execution and the OS weakness is rated as a local-only root exploit? The one I saw looked like the first step was a wide scan for the ability to run a command, and the initial use was to send back the vulnerable URL to a site which later used the glibc issue to escalate to root.
On Tue, 06 Dec 2011 15:45:04 -0600 Johnny Hughes johnny@centos.org wrote:
On 12/06/2011 02:36 PM, Les Mikesell wrote:
On Tue, Dec 6, 2011 at 2:18 PM, Karanbir Singh mail-lists@karan.org wrote:
On 12/06/2011 08:09 PM, Les Mikesell wrote:
Any luck on the specific attack path yet? The linked article suggests Centos up to 5.5 was vulnerable.
We dont have access to the actual machines that were broken into
- so pretty much everything is second hand info.
But based on what we know and what we have been told and what we have worked out ourselves as well, its almost certainly bruteforced ssh passwords.
So, coincidence that they were CentOS, and pre-5.6? Did they have admins in common?
Kaspersky has access to the images ... but they were mostly cleaned/erased and only what they can recover from erased ext3 files are there to see.
The attackers used something to 00000 out the files that they wanted to wipe directly ... so only things like old logs (that were deleted by logrotate and not wiped by the attackers) are on there.
There is one major possibility for something that could be an entry point besides brute force, and that is exim:
http://rhn.redhat.com/errata/RHSA-2010-0970.html
However, they do not know yet if exim was in use on those machines.
Note: CentOS released our update within 24 hours of that update from upstream ... but people who have < 5.5 and exim are vulnerable to that.
If I had to guess, I would say that the attackers probably developed their code on CentOS, so they were looking for a CentOS machine to deploy their code on in the wild. That would be why I would say CentOS was the OS used.
The fact that they immediately (first thing, actually) did was to upgrade OpenSSH does suggest that there is a Zero Day bug around.
If you capture a machine to be your C&C of a botnet, you certainly don't want the same bug around so others can take your 0wned machine...
Rui
On Wednesday, December 07, 2011 12:30:27 PM Rui Miguel Silva Seabra wrote:
The fact that they immediately (first thing, actually) did was to upgrade OpenSSH does suggest that there is a Zero Day bug around.
While at first blush that would appear to be so, it may be that the openssh was upgraded to get a valuable tunneling feature not present in the CentOS5 openssh (reading through the comments on the Kaspersky item).
On Wed, 2011-11-30 at 13:05 -0500, m.roth@5-cent.us wrote:
There's an article on slashdot about the Duqu team wiping all their intermediary c&c servers on 20 Oct. Interestingly, the report says that they were all (?) not only linux, but CentOS. There's a suggestion of a zero-day exploit in openssh-4.3, but both the original article, and Kaspersky labs (who have a *very* interesting post of the story) consider that highly unlikely, and the evidence points to brute-force attacks against the root password.
*DISABLE* password authentication on public-facing [and preferably all] servers. Isn't that securing a server rule#1?
Use shared-key authentication.
On Wednesday, December 07, 2011 05:48:24 AM Adam Tauno Williams wrote:
*DISABLE* password authentication on public-facing [and preferably all] servers. Isn't that securing a server rule#1?
Interestingly enough, there are vulnerability scanning tools out there that will flag the lack of a password prompt as indicating that no password is required.... one such tool, which I can't name, is very popular in the PCI-DSS compliance industry.
In my particular case, I was able to convince the person running the scan that ssh with key-based security was better than passwords; but I could see where others would not be swayed, and would insist that having a password prompt is more secure..... (of course, that somewhat ignores how key-based auth works, but when you are just reading the scan tool's output and taking it as fact......)