Suppose I have a CentOS 5.7 machine running the default Apache with no extra modules enabled, and with the "yum-updatesd" service running to pull down and install updates as soon as they become available from the repository. (Assume further the password is strong, etc.) On the other hand, suppose that as the admin, I'm not subscribed to any security alert mailing lists which send out announcements like "Please disable this feature as a workaround until this hole is plugged", so the machine just hums along with all of its default settings.
So the machine can still be broken into, if there is an unpatched exploit released in the wild, in the window of time before a patch is released for that update. On the other hand, at any point in time where there are no unpatched exploits in the wild, the machine should be much harder to break into.
Roughly what percent of the time is there such an unpatched exploit in the wild, so that the machine can be hacked by someone keeping up with the exploits? 5%? 50%? 95%?
Hopefully this is specific enough that the answer is not "it depends" :) , an actual numeric answer should exist -- although I don't know if anyone has ever tried to work it out. But if not, then what's a good guess, based on observing how frequently root exploits are released in the wild, and how long the patches usually take.
Bennett
On 12/28/2011 03:13 AM, Bennett Haselton wrote:
Roughly what percent of the time is there such an unpatched exploit in the wild, so that the machine can be hacked by someone keeping up with the exploits? 5%? 50%? 95%?
there is no way to tell, and there is no metric to work against unless there is some source that can identify exactly when and how a specific exploit was discovered ( but then again, many exploits are not reported by the people who find them, they just abuse those exploits till such time as they can )
- KB
On Tue, 27 Dec 2011, Bennett Haselton wrote:
Suppose I have a CentOS 5.7 machine running the default Apache with no extra modules enabled, and with the "yum-updatesd" service running to pull down and install updates as soon as they become available from the repository.
So the machine can still be broken into, if there is an unpatched exploit released in the wild, in the window of time before a patch is released for that update.
Roughly what percent of the time is there such an unpatched exploit in the wild, so that the machine can be hacked by someone keeping up with the exploits? 5%? 50%? 95%?
There's no way to give you an exact number, but let me put it this way:
If you've disable as much as you can (which by default, most stuff is disabled, so that's good), and you restart Apache after each update, your chances of being broken into are better by things like SSH brute force attacks. There's always a chance someone will get in, but when you look at the security hole history of Apache, particularly over the past few years, there have been numerous CVE's, but workarounds and they aren't usually earth-shattering. Very few of them have. The latest version that ships with 5.7 is as secure as they come. If it wasn't, most web sites on the Internet would be hacked by now, as most run Apache.
******************************************************************************* Gilbert Sebenste ******** (My opinions only!) ****** *******************************************************************************
On Tue, Dec 27, 2011 at 8:33 PM, Gilbert Sebenste < sebenste@weather.admin.niu.edu> wrote:
On Tue, 27 Dec 2011, Bennett Haselton wrote:
Suppose I have a CentOS 5.7 machine running the default Apache with no extra modules enabled, and with the "yum-updatesd" service running to
pull
down and install updates as soon as they become available from the repository.
So the machine can still be broken into, if there is an unpatched exploit released in the wild, in the window of time before a patch is released
for
that update.
Roughly what percent of the time is there such an unpatched exploit in
the
wild, so that the machine can be hacked by someone keeping up with the exploits? 5%? 50%? 95%?
There's no way to give you an exact number, but let me put it this way:
If you've disable as much as you can (which by default, most stuff is disabled, so that's good), and you restart Apache after each update, your chances of being broken into are better by things like SSH brute force attacks. There's always a chance someone will get in, but when you look at the security hole history of Apache, particularly over the past few years, there have been numerous CVE's, but workarounds and they aren't usually earth-shattering. Very few of them have. The latest version that ships with 5.7 is as secure as they come. If it wasn't, most web sites on the Internet would be hacked by now, as most run Apache
I was asking because I had a server that did get broken into, despite having yum-updatesd running and a strong password. He said that even if you apply all latest updates automatically, there were still windows of time where an exploit in the wild could be used to break into a machine; in particular he said:
"For example, there was a while back ( ~march ) a kernel exploit that affected CentOS / RHEL. The patch came after 1-2 weeks of the security announcement. The initial announcement provided a simple work around until the new version is released."
Was this a sufficiently high-profile incident that you know what he's referring to? If this kind of thing happens once a year or more, than surely this is a much greater threat than "brute forcing the SSH password"? That's what I'm talking about -- how often does this sort of thing happen, where you need to be subscribed to be a security mailing list in order to know what workaround to make to stay safe, as opposed to simply running yum-updatesd to install latest patches automatically.
Bennett
On 12/28/2011 04:29 AM, Bennett Haselton wrote:
I was asking because I had a server that did get broken into, despite having yum-updatesd running and a strong password. He said that even if
the software component compromised was a part of the updates being dished out from the distro ( and therefore likely covered via the yum-updatesd? )
- KB
Everything installed on the machine had been installed with "yum". So I assumed that meant that it would also be updated by "yum" if an update was available from the distro.
On Tue, Dec 27, 2011 at 9:38 PM, Karanbir Singh mail-lists@karan.orgwrote:
On 12/28/2011 04:29 AM, Bennett Haselton wrote:
I was asking because I had a server that did get broken into, despite having yum-updatesd running and a strong password. He said that even if
the software component compromised was a part of the updates being dished out from the distro ( and therefore likely covered via the yum-updatesd? )
- KB
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 12/27/2011 10:42 PM, Bennett Haselton wrote:
Everything installed on the machine had been installed with "yum". So I assumed that meant that it would also be updated by "yum" if an update was available from the distro.
1. Are you running PHP apps on the web server? Perl apps? Bad code in dynamic apps is the main way security breaches happen if via apache. And in those cases is usually the ability to execute some script (sometimes one that the bad guys upload first) that is the issue. Many times this happens because programmers of the dynamic (php, perl, python, ruby, etc.) do not properly vet the input of some form or other item.
2. Why have password logins at all? Using a secure ssh key only for logins makes the most sense.
3. Please do not top post.
On Tue, Dec 27, 2011 at 9:38 PM, Karanbir Singh mail-lists@karan.orgwrote:
On 12/28/2011 04:29 AM, Bennett Haselton wrote:
I was asking because I had a server that did get broken into, despite having yum-updatesd running and a strong password. He said that even if
the software component compromised was a part of the updates being dished out from the distro ( and therefore likely covered via the yum-updatesd? )
On Wed, Dec 28, 2011 at 6:10 AM, Johnny Hughes johnny@centos.org wrote:
On 12/27/2011 10:42 PM, Bennett Haselton wrote:
Everything installed on the machine had been installed with "yum". So I assumed that meant that it would also be updated by "yum" if an update
was
available from the distro.
- Are you running PHP apps on the web server? Perl apps? Bad code in
dynamic apps is the main way security breaches happen if via apache. And in those cases is usually the ability to execute some script (sometimes one that the bad guys upload first) that is the issue. Many times this happens because programmers of the dynamic (php, perl, python, ruby, etc.) do not properly vet the input of some form or other item.
The only popular third-party script on the server was glype from www.glype.com. I don't know if it's popular enough (compared to, say, WordPress) to make it worthwhile for the bad guys to have developed an exploit against it. On the other hand, if they used an automated tool that can be pointed to *any* PHP script and probe it for weaknesses, they could have found something.
2. Why have password logins at all? Using a secure ssh key only for
logins makes the most sense.
Well that's something that I'm curious about the reasoning behind -- if you're already using a completely random 12-character password, why would it be any more secure to use an ssh key? Even though the ssh key is more random, they're both sufficiently random that it would take at least hundreds of years to get in by trial and error.
3. Please do not top post.
My bad. Gmail default. :)
Am 29.12.2011 09:17, schrieb Bennett Haselton:
- Why have password logins at all? Using a secure ssh key only for
logins makes the most sense.
Well that's something that I'm curious about the reasoning behind -- if you're already using a completely random 12-character password, why would it be any more secure to use an ssh key? Even though the ssh key is more random, they're both sufficiently random that it would take at least hundreds of years to get in by trial and error.
because the key is MUCH longer than 12 chars becasue it is NOT bruteforceable because brute-force-attacks are trying password-login
if you really think your 12-chars password is as secure as a ssh-key protcected with this password you should consider to take some education in security
Hello Reindl,
On Thu, 2011-12-29 at 12:29 +0100, Reindl Harald wrote:
Am 29.12.2011 09:17, schrieb Bennett Haselton:
Even though the ssh key is more random, they're both sufficiently random that it would take at least hundreds of years to get in by trial and error.
if you really think your 12-chars password is as secure as a ssh-key protcected with this password you should consider to take some education in security
Bennett clearly states that he understands the ssh key is more random, but wonders why a 12 char password (of roughly 6 bits entropy per byte assuming upper & lower case characters and numbers) wouldn't be sufficient.
I'm fairly confident the 9 to 12 char (54 to 72 bit) passwords I use are sufficiently strong to protect my machines against remote brute force attacks via ssh. Seeing that every login attempt takes at least a second and in the default setup sshd allows a maximum of 10 threads at a time a remote brute force is not really feasible (1/2 . 2 ^ 54 . 1s / 10). Imho of course :)
Regards, Leonard.
Am 29.12.2011 12:56, schrieb Leonard den Ottolander:
Hello Reindl,
On Thu, 2011-12-29 at 12:29 +0100, Reindl Harald wrote:
Am 29.12.2011 09:17, schrieb Bennett Haselton:
Even though the ssh key is more random, they're both sufficiently random that it would take at least hundreds of years to get in by trial and error.
if you really think your 12-chars password is as secure as a ssh-key protcected with this password you should consider to take some education in security
Bennett clearly states that he understands the ssh key is more random, but wonders why a 12 char password (of roughly 6 bits entropy per byte assuming upper & lower case characters and numbers) wouldn't be sufficient.
so explain me why discuss to use or not to use the best currently availbale method in context of security?
this is a secure configuration with no costs so why not use it?
PasswordAuthentication no ChallengeResponseAuthentication no GSSAPIAuthentication no GSSAPICleanupCredentials no RSAAuthentication yes PubkeyAuthentication yes PermitEmptyPasswords no PermitRootLogin without-password AllowGroups root verwaltung AllowUsers root harry IgnoreRhosts yes HostbasedAuthentication no StrictModes yes UseDNS no UsePrivilegeSeparation yes UsePAM yes LoginGraceTime 25 MaxAuthTries 10 MaxStartups 25
On Thursday 29 December 2011 13:07:56 Reindl Harald wrote:
Am 29.12.2011 12:56, schrieb Leonard den Ottolander:
Hello Reindl,
On Thu, 2011-12-29 at 12:29 +0100, Reindl Harald wrote:
Am 29.12.2011 09:17, schrieb Bennett Haselton:
Even though the ssh key is more random, they're both sufficiently random that it would take at least hundreds of years to get in by trial and error.
if you really think your 12-chars password is as secure as a ssh-key protcected with this password you should consider to take some education in security
Bennett clearly states that he understands the ssh key is more random, but wonders why a 12 char password (of roughly 6 bits entropy per byte assuming upper & lower case characters and numbers) wouldn't be sufficient.
so explain me why discuss to use or not to use the best currently availbale method in context of security?
Using the ssh key can be problematic because it is too long and too random to be memorized --- you have to carry it on a usb stick (or whereever). This provides an additional point of failure should your stick get lost or stolen. Human brain is still by far the most secure information-storage device. :-)
It is very inconvenient for people who need to login to their servers from random remote locations (ie. people who travel a lot or work in hardware- controlled environment).
Besides, it is essentially a question of overkill. If password is not good enough, you could argue that the key is also not good enough --- two keys (or a larger one) would be more secure. Where do you draw the line?
Best, :-) Marko
Am 29.12.2011 14:21, schrieb Marko Vojinovic:
so explain me why discuss to use or not to use the best currently availbale method in context of security?
Using the ssh key can be problematic because it is too long and too random to be memorized --- you have to carry it on a usb stick (or whereever). This provides an additional point of failure should your stick get lost or stolen. Human brain is still by far the most secure information-storage device. :-)
this is bullshit most people have their ssh-key on a usb-stick
normally a ssh-key is protected by a password this can be your 12-char password
if you put an non-proctected key on a stick this is really your problem - per default it is requestet from ssh-keygen
the hughe difference is: while having the same password (for the key) it can not be used directly for brute-force und you need the password and at least one time access to the key file
Reindl Harald wrote:
Am 29.12.2011 14:21, schrieb Marko Vojinovic:
so explain me why discuss to use or not to use the best currently availbale method in context of security?
Using the ssh key can be problematic because it is too long and too random to be memorized --- you have to carry it on a usb stick (or whereever). This provides an additional point of failure should your stick get lost or stolen. Human brain is still by far the most secure information-storage device. :-)
this is bullshit most people have their ssh-key on a usb-stick
normally a ssh-key is protected by a password this can be your 12-char password
<snip> Many US companies have gone past that. A number that I've worked for, and the one I work for, all have used RSA keyfobs. To open the VPN link, you need three pieces of information: userid, PIN (which is up to 8 chars min) and the six digit code from the fob.
The US gov't has gone a different way: it issues CaC or PIV-II cards, and you need a) a card reader attached or builtin to your system, b) the card, and c) your PIN (8 digits).
In both cases, once you've got your VPN, *then* it will frequently be asking for username & passwords for each different kind of access.
mark
Am 29.12.2011 15:24, schrieb m.roth@5-cent.us:
Reindl Harald wrote:
Am 29.12.2011 14:21, schrieb Marko Vojinovic:
so explain me why discuss to use or not to use the best currently availbale method in context of security?
Using the ssh key can be problematic because it is too long and too random to be memorized --- you have to carry it on a usb stick (or whereever). This provides an additional point of failure should your stick get lost or stolen. Human brain is still by far the most secure information-storage device. :-)
this is bullshit most people have their ssh-key on a usb-stick
normally a ssh-key is protected by a password this can be your 12-char password
<snip> Many US companies have gone past that.
A number that I've worked for, and the one I work for, all have used RSA keyfobs. To open the VPN link, you need three pieces of information: userid, PIN (which is up to 8 chars min) and the six digit code from the fob.
The US gov't has gone a different way: it issues CaC or PIV-II cards, and you need a) a card reader attached or builtin to your system, b) the card, and c) your PIN (8 digits).
In both cases, once you've got your VPN, *then* it will frequently be asking for username & passwords for each different kind of access.
why do you not tell this the idiot who is argumentating against kyes and thinks using password-login is smart?
Reinl,
On Thu, 2011-12-29 at 15:28 +0100, Reindl Harald wrote:
why do you not tell this the idiot who is argumentating against kyes and thinks using password-login is smart?
I don't like your tone. I'm not sure if it's me or Bennett you are calling an idiot or both, but in any case you should mind your words and try to understand the argument others are making before shooting off your mouth.
I merely responded to Bennett's inquiry why a 12 char password wouldn't be sufficiently strong. I believe Marko also made the point that it is always arbitrary where to draw the line as to what you consider strong/safe enough. I made my point why I believe using 9 to 12 character passwords is sufficiently secure for my purposes (I do not run a military facility).
Now if you have an argument to make about that statement I'm very interested to hear it. On the other hand, if you start calling people idiots on a public channel because you think they do not understand what you are telling (where it's actually you who seems to be missing the point they are making) I don't consider you a suitable conversation partner. You should understand discussions on lists like these are made on arguments not insults.
Leonard.
Leonard den Ottolander wrote:
Reinl,
On Thu, 2011-12-29 at 15:28 +0100, Reindl Harald wrote:
why do you not tell this the idiot who is argumentating against kyes and thinks using password-login is smart?
I don't like your tone. I'm not sure if it's me or Bennett you are calling an idiot or both, but in any case you should mind your words and try to understand the argument others are making before shooting off your mouth.
<snip>
Now if you have an argument to make about that statement I'm very interested to hear it. On the other hand, if you start calling people idiots on a public channel because you think they do not understand what you are telling (where it's actually you who seems to be missing the point they are making) I don't consider you a suitable conversation partner. You should understand discussions on lists like these are made on arguments not insults.
Agreed. I don't even label as idiots the idiots who post here, asking us to tell them how to do the job they were hired for, without any indication that they've read man pages, or googled for an answer.
mark
Agreed. I don't even label as idiots the idiots who post here, asking us to tell them how to do the job they were hired for, without any indication that they've read man pages, or googled for an answer.
Last time I checked you *were* in this list therefore you are calling yourself an idiot.
Jokes apart... calm down. You offend people with your tone and insults so I ask you to stop doing so.
Regards
On Thursday 29 December 2011 14:59:14 Reindl Harald wrote:
the hughe difference is: while having the same password (for the key) it can not be used directly for brute-force und you need the password and at least one time access to the key file
Explain me how having a key protected by a password avoids brute forcing if you loose the usb stick holding that key?
Technology is developing at a scary pace, have a look at this: http://mytechencounters.wordpress.com/2011/04/03/gpu-password-cracking-crack...
And this is with a simple card, imagine what you can do with a system with multiple paralel cards...
Just to be clear: I'm not arguing which system is better/more secure. I'm just pointing out one downside of having the key in a usb memory.
And bruteforcing against ssh servers are really difficult as some others have commented (and even more difficult if you limit failed connections...)
Regards
On 12/30/2011 12:41 AM, Marc Deop wrote:
On Thursday 29 December 2011 14:59:14 Reindl Harald wrote:
the hughe difference is: while having the same password (for the key) it can not be used directly for brute-force und you need the password and at least one time access to the key file
Explain me how having a key protected by a password avoids brute forcing if you loose the usb stick holding that key?
Technology is developing at a scary pace, have a look at this: http://mytechencounters.wordpress.com/2011/04/03/gpu-password-cracking-crack...
And this is with a simple card, imagine what you can do with a system with multiple paralel cards...
Just to be clear: I'm not arguing which system is better/more secure. I'm just pointing out one downside of having the key in a usb memory.
And bruteforcing against ssh servers are really difficult as some others have commented (and even more difficult if you limit failed connections...)
My IC card fries itself after 10 unsucessful attempts.
That is one way.
The military CACs fry themselves after 3.
They are not just disks, they are tiny 8-bit systems embedded in the chip. The key never actually leaves the card. The benefit is that your key is never exposed, even in an encrypted state. The downside is that signing really huge things can take a few seconds (like ~5 secs for, say, signing a decent sized RPM or email attachment, 15 secs or so for signing the a kernel RPM) because the card processor, not the host system, is doing the signing.
I don't know about the security of USB dongles. I've never used them before, but I'm sure that secured versions of them are much more than simple USB drives with a directory full of keys, but rather discrete USB devices which probably operate in the same way. I'm speculating, but I can't imagine this isn't the case with good USB systems.
On Thursday 29 December 2011 14:59:14 Reindl Harald wrote:
Am 29.12.2011 14:21, schrieb Marko Vojinovic:
so explain me why discuss to use or not to use the best currently availbale method in context of security?
Using the ssh key can be problematic because it is too long and too random to be memorized --- you have to carry it on a usb stick (or whereever). This provides an additional point of failure should your stick get lost or stolen. Human brain is still by far the most secure information-storage device. :-)
this is bullshit most people have their ssh-key on a usb-stick
And how are you going to access your servers if the stick gets broken or lost? I guess you would have to travel back to where the server is hosted, in order to copy/recreate the key.
I did not argue that the key is not more secure than a password. I was just pointing out that sometimes it can be more inconvenient.
Your question was "why discuss to use or not to use the best currently availbale method in context of security?", and my answer was "there can be a tradeoff between security and convenience". I don't see why do you consider this to be bullshit.
Best, :-) Marko
Marko Vojinovic wrote:
On Thursday 29 December 2011 14:59:14 Reindl Harald wrote:
Am 29.12.2011 14:21, schrieb Marko Vojinovic:
so explain me why discuss to use or not to use the best currently availbale method in context of security?
Using the ssh key can be problematic because it is too long and too random to be memorized --- you have to carry it on a usb stick (or whereever). This provides an additional point of failure should your stick get lost or stolen. Human brain is still by far the most secure information-storage device. :-)
this is bullshit most people have their ssh-key on a usb-stick
And how are you going to access your servers if the stick gets broken or lost? I guess you would have to travel back to where the server is hosted, in order to copy/recreate the key.
Um, yep: you're SOL, same as if you spilled coffee on your laptop, or whatever. And if you loose it, you should then create a new one.
I did not argue that the key is not more secure than a password. I was just pointing out that sometimes it can be more inconvenient.
All security is inconvenient. What's implemented is a balance between convenience and security - really secure is a system not connected to any network, and with no USB ports, that runs off a DVD.... <snip> mark
On 12/30/2011 01:33 AM, m.roth@5-cent.us wrote:
Marko Vojinovic wrote:
On Thursday 29 December 2011 14:59:14 Reindl Harald wrote:
Am 29.12.2011 14:21, schrieb Marko Vojinovic:
so explain me why discuss to use or not to use the best currently availbale method in context of security?
Using the ssh key can be problematic because it is too long and too random to be memorized --- you have to carry it on a usb stick (or whereever). This provides an additional point of failure should your stick get lost or stolen. Human brain is still by far the most secure information-storage device. :-)
this is bullshit most people have their ssh-key on a usb-stick
And how are you going to access your servers if the stick gets broken or lost? I guess you would have to travel back to where the server is hosted, in order to copy/recreate the key.
Um, yep: you're SOL, same as if you spilled coffee on your laptop, or whatever. And if you loose it, you should then create a new one.
I did not argue that the key is not more secure than a password. I was just pointing out that sometimes it can be more inconvenient.
All security is inconvenient. What's implemented is a balance between convenience and security - really secure is a system not connected to any network, and with no USB ports, that runs off a DVD....
...at the bottom of the ocean...
On 12/29/2011 07:21 AM, Marko Vojinovic wrote:
On Thursday 29 December 2011 13:07:56 Reindl Harald wrote:
Am 29.12.2011 12:56, schrieb Leonard den Ottolander:
Hello Reindl,
On Thu, 2011-12-29 at 12:29 +0100, Reindl Harald wrote:
Am 29.12.2011 09:17, schrieb Bennett Haselton:
Even though the ssh key is more random, they're both sufficiently random that it would take at least hundreds of years to get in by trial and error.
if you really think your 12-chars password is as secure as a ssh-key protcected with this password you should consider to take some education in security
Bennett clearly states that he understands the ssh key is more random, but wonders why a 12 char password (of roughly 6 bits entropy per byte assuming upper & lower case characters and numbers) wouldn't be sufficient.
so explain me why discuss to use or not to use the best currently availbale method in context of security?
Using the ssh key can be problematic because it is too long and too random to be memorized --- you have to carry it on a usb stick (or whereever). This provides an additional point of failure should your stick get lost or stolen. Human brain is still by far the most secure information-storage device. :-)
It is very inconvenient for people who need to login to their servers from random remote locations (ie. people who travel a lot or work in hardware- controlled environment).
Besides, it is essentially a question of overkill. If password is not good enough, you could argue that the key is also not good enough --- two keys (or a larger one) would be more secure. Where do you draw the line?
This is absolutely ludicrous. Requiring a physical "key" to be present for access can not be compared to a 12 character password, random or not.
Bottom line ... if you want people to crack your server, use passwords and they way.
For the love of God, do not allow password access your machines people.
Hi Marko,
Using the ssh key can be problematic because it is too long and too random to be memorized --- you have to carry it on a usb stick (or whereever). This provides an additional point of failure should your stick get lost or stolen.
this is only correct when you use SSH keys without a sufficiently secure passphrase. Which you obviously should never do. If you have a passphrase with your key, finding or stealing the USB stick is completely useless, and even if someone gets at your key, your no worse off than with password authentication.
Human brain is still by far the most secure information-storage device. :-)
I strongly disgree. Social engineering is a very efficient way to get at other people's data.
It is very inconvenient for people who need to login to their servers from random remote locations (ie. people who travel a lot or work in hardware- controlled environment).
Agreed.
Besides, it is essentially a question of overkill. If password is not good enough, you could argue that the key is also not good enough --- two keys (or a larger one) would be more secure. Where do you draw the line?
One key is indefinitely better than a password. The additional security you gain when you add another key is, however, disputable.
Best regards,
Peter.
On 12/29/2011 10:21 PM, Marko Vojinovic wrote:
On Thursday 29 December 2011 13:07:56 Reindl Harald wrote:
Am 29.12.2011 12:56, schrieb Leonard den Ottolander:
Hello Reindl,
On Thu, 2011-12-29 at 12:29 +0100, Reindl Harald wrote:
Am 29.12.2011 09:17, schrieb Bennett Haselton:
Even though the ssh key is more random, they're both sufficiently random that it would take at least hundreds of years to get in by trial and error.
if you really think your 12-chars password is as secure as a ssh-key protcected with this password you should consider to take some education in security
Bennett clearly states that he understands the ssh key is more random, but wonders why a 12 char password (of roughly 6 bits entropy per byte assuming upper& lower case characters and numbers) wouldn't be sufficient.
so explain me why discuss to use or not to use the best currently availbale method in context of security?
Using the ssh key can be problematic because it is too long and too random to be memorized --- you have to carry it on a usb stick (or whereever). This provides an additional point of failure should your stick get lost or stolen. Human brain is still by far the most secure information-storage device. :-)
It is very inconvenient for people who need to login to their servers from random remote locations (ie. people who travel a lot or work in hardware- controlled environment).
Besides, it is essentially a question of overkill. If password is not good enough, you could argue that the key is also not good enough --- two keys (or a larger one) would be more secure. Where do you draw the line?
Best, :-) Marko
Hi Marko! What about IC cards? I use that a lot, and its reduced my need for a password to something tiny (6 numbers) and requires a physical key (my card). I have the root certificates, private keys, etc. stored offline just in case my card goes nuts, which has happened before, but I've never had a problem with this.
When traveling I log in to my home server and work servers with my laptop. Its really a *lot* easier than using a bunch of pasword schemes. I was initially worried that I'd run into a situation where I'd either lose my card traveling, or it would get crushed, or whatever -- but that hasn't happened in 5 years. What has happened in 5 years of doing this is intermittent network outages, work server crashing, web applications failing, database corruption, etc.
So from experience (mine and coworkers, at least), it is a lot more likely that problems will arise from totally different vectors than having ssh keys and ic cards making life complicated -- because from this user's perspective its made things a LOT simpler.
But it requires a bit of study. Which most people don't do. More to the point most people don't even read popups on the screens, even the big red scary ones, so...
å¤ç¥ãå²©ç· wrote:
On 12/29/2011 10:21 PM, Marko Vojinovic wrote:
On Thursday 29 December 2011 13:07:56 Reindl Harald wrote:
Am 29.12.2011 12:56, schrieb Leonard den Ottolander:
On Thu, 2011-12-29 at 12:29 +0100, Reindl Harald wrote:
Am 29.12.2011 09:17, schrieb Bennett Haselton:
Even though the ssh key is more random, they're both sufficiently random that it would take at least hundreds of years to get in by trial and error.
if you really think your 12-chars password is as secure as a ssh-key protcected with this password you should consider to take some education in security
<snip>
It is very inconvenient for people who need to login to their servers from random remote locations (ie. people who travel a lot or work in hardware-controlled environment).
Besides, it is essentially a question of overkill. If password is not good enough, you could argue that the key is also not good enough --- two keys (or a larger one) would be more secure. Where do you draw the line?
<snip>
When traveling I log in to my home server and work servers with my laptop. Its really a *lot* easier than using a bunch of pasword schemes.
<snip> Ah, that brings to mind another issue with only passwords: synchronization. I worked as a subcontractor for a *huge* US co a few years ago. I've *never* had to write passwords down... but for there, I had a page of them! Our group's, the corporate test systems, the corporate *production* systems, and *each* had their own, along with their own password aging (there was *no* single sign-on), the contracting co's....
mark
On 12/30/2011 12:00 AM, m.roth@5-cent.us wrote:
夜神　岩男 wrote:
On 12/29/2011 10:21 PM, Marko Vojinovic wrote:
On Thursday 29 December 2011 13:07:56 Reindl Harald wrote:
Am 29.12.2011 12:56, schrieb Leonard den Ottolander:
On Thu, 2011-12-29 at 12:29 +0100, Reindl Harald wrote:
Am 29.12.2011 09:17, schrieb Bennett Haselton: > Even though the ssh key is more > random, they're both sufficiently random that it would take at least > hundreds of years to get in by trial and error.
if you really think your 12-chars password is as secure as a ssh-key protcected with this password you should consider to take some education in security
<snip> >> It is very inconvenient for people who need to login to their servers >> from random remote locations (ie. people who travel a lot or work in >> hardware-controlled environment). >> >> Besides, it is essentially a question of overkill. If password is not >> good enough, you could argue that the key is also not good enough --- >> two keys (or a larger one) would be more secure. Where do you draw the >> line? <snip> > When traveling I log in to my home server and work servers with my > laptop. Its really a *lot* easier than using a bunch of pasword schemes. <snip> Ah, that brings to mind another issue with only passwords: synchronization. I worked as a subcontractor for a *huge* US co a few years ago. I've *never* had to write passwords down... but for there, I had a page of them! Our group's, the corporate test systems, the corporate *production* systems, and *each* had their own, along with their own password aging (there was *no* single sign-on), the contracting co's....
mark
Ah, forgot about that because its no longer a problem for me anymore. Using the same password on two systems is a religiously-to-be-observed rule that *most* users violate.
I can put my public keys on any system and not worry about it. Hitting the number pad for my digits is a lot faster than typing in a password, a lot more convenient than remembering a bunch of them (and a big motivator to buy laptops with full-blown 10-keys, which is common now anyway, as are internal card readers...).
å¤ç¥ãå²©ç· wrote:
On 12/30/2011 12:00 AM, m.roth@5-cent.us wrote:
å¤Å神ãâ¬â¬Ã¥Â²Â©Ã§â· wrote:
On 12/29/2011 10:21 PM, Marko Vojinovic wrote:
On Thursday 29 December 2011 13:07:56 Reindl Harald wrote:
Am 29.12.2011 12:56, schrieb Leonard den Ottolander:
On Thu, 2011-12-29 at 12:29 +0100, Reindl Harald wrote: > Am 29.12.2011 09:17, schrieb Bennett Haselton:
<snip>
When traveling I log in to my home server and work servers with my laptop. Its really a *lot* easier than using a bunch of pasword schemes.
<snip> Ah, that brings to mind another issue with only passwords: synchronization. I worked as a subcontractor for a *huge* US co a few years ago. I've *never* had to write passwords down... but for there, I had a page of them! Our group's, the corporate test systems, the corporate *production* systems, and *each* had their own, along with their own password aging (there was *no* single sign-on), the contracting co's....
Ah, forgot about that because its no longer a problem for me anymore. Using the same password on two systems is a religiously-to-be-observed rule that *most* users violate.
<snip> Yeah, but this was *corporate*: systems I had no access to other than as a user, with very limited sudo. I was *appalled* that they didn't have single sign-on.
mark
On Fri, Dec 30, 2011 at 4:00 AM, m.roth@5-cent.us wrote:
夜神　岩男 wrote:
On 12/29/2011 10:21 PM, Marko Vojinovic wrote:
On Thursday 29 December 2011 13:07:56 Reindl Harald wrote:
Am 29.12.2011 12:56, schrieb Leonard den Ottolander:
On Thu, 2011-12-29 at 12:29 +0100, Reindl Harald wrote:
Am 29.12.2011 09:17, schrieb Bennett Haselton: > Even though the ssh key is more > random, they're both sufficiently random that it would take at least > hundreds of years to get in by trial and error.
if you really think your 12-chars password is as secure as a ssh-key protcected with this password you should consider to take some education in security
<snip> >> It is very inconvenient for people who need to login to their servers >> from random remote locations (ie. people who travel a lot or work in >> hardware-controlled environment). >> >> Besides, it is essentially a question of overkill. If password is not >> good enough, you could argue that the key is also not good enough --- >> two keys (or a larger one) would be more secure. Where do you draw the >> line? <snip> > When traveling I log in to my home server and work servers with my > laptop. Its really a *lot* easier than using a bunch of pasword schemes. <snip> Ah, that brings to mind another issue with only passwords: synchronization. I worked as a subcontractor for a *huge* US co a few years ago. I've *never* had to write passwords down... but for there, I had a page of them! Our group's, the corporate test systems, the corporate *production* systems, and *each* had their own, along with their own password aging (there was *no* single sign-on), the contracting co's....
We use PasswordSafe to solve that one. There are other similar products.
Cheers,
Cliff
On 12/29/2011 03:53 PM, 夜神 岩男 wrote:
On 12/29/2011 10:21 PM, Marko Vojinovic wrote:
On Thursday 29 December 2011 13:07:56 Reindl Harald wrote:
Am 29.12.2011 12:56, schrieb Leonard den Ottolander:
Hello Reindl,
On Thu, 2011-12-29 at 12:29 +0100, Reindl Harald wrote:
Am 29.12.2011 09:17, schrieb Bennett Haselton:
Even though the ssh key is more random, they're both sufficiently random that it would take at least hundreds of years to get in by trial and error.
if you really think your 12-chars password is as secure as a ssh-key protcected with this password you should consider to take some education in security
Bennett clearly states that he understands the ssh key is more random, but wonders why a 12 char password (of roughly 6 bits entropy per byte assuming upper& lower case characters and numbers) wouldn't be sufficient.
so explain me why discuss to use or not to use the best currently availbale method in context of security?
Using the ssh key can be problematic because it is too long and too random to be memorized --- you have to carry it on a usb stick (or whereever). This provides an additional point of failure should your stick get lost or stolen. Human brain is still by far the most secure information-storage device. :-)
It is very inconvenient for people who need to login to their servers from random remote locations (ie. people who travel a lot or work in hardware- controlled environment).
Besides, it is essentially a question of overkill. If password is not good enough, you could argue that the key is also not good enough --- two keys (or a larger one) would be more secure. Where do you draw the line?
Best, :-) Marko
Hi Marko! What about IC cards? I use that a lot, and its reduced my need for a password to something tiny (6 numbers) and requires a physical key (my card). I have the root certificates, private keys, etc. stored offline just in case my card goes nuts, which has happened before, but I've never had a problem with this.
When traveling I log in to my home server and work servers with my laptop. Its really a *lot* easier than using a bunch of pasword schemes. I was initially worried that I'd run into a situation where I'd either lose my card traveling, or it would get crushed, or whatever -- but that hasn't happened in 5 years. What has happened in 5 years of doing this is intermittent network outages, work server crashing, web applications failing, database corruption, etc.
So from experience (mine and coworkers, at least), it is a lot more likely that problems will arise from totally different vectors than having ssh keys and ic cards making life complicated -- because from this user's perspective its made things a LOT simpler.
But it requires a bit of study. Which most people don't do. More to the point most people don't even read popups on the screens, even the big red scary ones, so... _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
I like to use serial numbers from MB, HDD, etc., as passwords. I never use normal words for my passwords, and few other users (with ssh/cli access) are carefully checked for their passwords.
If this formula is true "(1/2 . 2 ^ 54 . 1s / 10)" for 9 *random* character password, then 0.5 * 18014398509481984 /10 gives 900719925474099 seconds to crack it, or 10424999137 days per attacker.
If you use denyhosts or fail2ban, attacker needs 10,000 attack PC's that never attacked any denyhosts or fail2ban server in recent time.
So for army of 10,000 attacker PC's, bruteforce ssh needs 1042499 days, or 2856 years to crack it. Is this correct figure?
Ljubomir Ljubojevic wrote: <snip>
I like to use serial numbers from MB, HDD, etc., as passwords. I never
The one problem with this is that *if* the attacker has the slightest idea of the hardware, their task is vastly smaller. I trust, for example, that you don't use Dell's s/n/"express code"; Penguin, not having sold 5 gazillion servers, has the first few digits all the same, for years (they're being optimistic with s/n's that long). <snip> mark
On 12/29/2011 06:45 PM, m.roth@5-cent.us wrote:
Ljubomir Ljubojevic wrote:
<snip> > I like to use serial numbers from MB, HDD, etc., as passwords. I never
The one problem with this is that *if* the attacker has the slightest idea of the hardware, their task is vastly smaller. I trust, for example, that you don't use Dell's s/n/"express code"; Penguin, not having sold 5 gazillion servers, has the first few digits all the same, for years (they're being optimistic with s/n's that long).
<snip> mark
No. I got the idea from my first second-hand MB for NOC router/firewall, while I was on the grain silo needing to reinstall ClarkConnect on it (don't ask :-D ). You can use s/n from some old PC you have at your home, or discarded MB (or whatever).
Of course, using s/n's would be same as using some good random-generator script.
On 12/30/2011 02:33 AM, Ljubomir Ljubojevic wrote:
I like to use serial numbers from MB, HDD, etc., as passwords. I never use normal words for my passwords, and few other users (with ssh/cli access) are carefully checked for their passwords.
If this formula is true "(1/2 . 2 ^ 54 . 1s / 10)" for 9 *random* character password, then 0.5 * 18014398509481984 /10 gives 900719925474099 seconds to crack it, or 10424999137 days per attacker.
If you use denyhosts or fail2ban, attacker needs 10,000 attack PC's that never attacked any denyhosts or fail2ban server in recent time.
So for army of 10,000 attacker PC's, bruteforce ssh needs 1042499 days, or 2856 years to crack it. Is this correct figure?
Unfortunately, no, it is not a correct number.
There are a few situational variables that have to be considered to really assess the security of a password, and theoretical best-case entropy is only a small part of that.
If, for example, you login remotely using a password that has to cross an untrusted network you should expect that it is being sniffed. Now this is less a problem because it should be encrypted. The situation is the same for local Windows or Linux logins -- all systems I know of encrypt passowords for storage by default, which isn't much different than how simple password encryption works across the network.
There is a problem with this, however. The password, however long, is reduced to a fixed-length hash in most password encryption schemes. Because of the wonders of modulo mathematics the total set of possible hashes is a lot less than the total set of possible passwords. What this means is we can start attacking the algorithm itself, in preparation for trying to decrypt intercepted data (of any type that falls under a signature/hash type scheme, not just passwords).
We can start a 10,000 computer botnet (or, more realistically, a 10m computer botnet these days, and this is a technique used right now) working on the problem of assembling a new index table that orders and assigns every possible valid hash said algorithm can produce, and start assigning values.
Essentially, we can move the computing cost up-front by assuming that we indeed *do* have to try *every* possible password, which means computing done 5 years ago applies to your brand new password today.
Something weird about the way encryption algorithms tend to work is that as you move through the list of possible hashes you find large spans of values that are impossible to actually arrive at given the set of data a user can enter. You can move those to the side, and this massively redudces the work load (but its something you can't discover until you're well into building the hash index, which might be a year or so).
You can also start with targeted hash indexing, meaning you first run through every possible dictionary word, then every variant of, then every possible combination of, then every possible combination with l33t substitutions, then any data set that you can scan from external sources (meaning things people might see and decide to use as a password that isn't in the dictionary, which is the category your S/N scheme falls into...), all of the above with numeric insertions (4, 2 and scattered single digits are most common, so focus on those), names of companies, etc. Going this route you can can about 99% of average user passwords in about a month. This is how John the Ripper works, in a nutshell -- it has a hash index of pre-checked phrases in a myriad of different hashing schemes and just checks the hashed password against the index to locate the list of possible correct ones, which is a pretty short list.
Anyway, to keep from getting into too much math, just consider that password cracking is not only based on entropy of the password, and the concept of passwords encrypted for transit or storage has been around long enough that has tables exist for a vast number of common algorithms.
If you are only logging on locally *and* you are nearly certain that nobody has access to your password storage, then you're just fine. Most users who don't spend time using IE to surf unsavory websites and click on everything those websites has to offer are safe from this. People who log in remotely, however, face a different challenge. People who login to a web interface using a password have a SERIOUS problem, in my opinion, because HTTP cannot be secured, and some websites (even banks!) sometimes don't have a public HTTPS, but force the user to use a HTTP->HTTPS redirect, which makes securing it literally impossible.
Blah blah. I'm glossing over some details here and there are as many different cracking scenarios which involve their own weaknesses as there are systems.
In short, keys, man, keys. Its not perfect, but it is much stronger than passwords and in my experience FAR much less hassle.
-Iwao
On Friday 30 December 2011 19:40:55 夜神 岩男 wrote: [snip]
We can start a 10,000 computer botnet (or, more realistically, a 10m computer botnet these days, and this is a technique used right now) working on the problem of assembling a new index table that orders and assigns every possible valid hash said algorithm can produce, and start assigning values.
Essentially, we can move the computing cost up-front by assuming that we indeed *do* have to try *every* possible password, which means computing done 5 years ago applies to your brand new password today.
[snip]
In short, keys, man, keys. Its not perfect, but it is much stronger than passwords and in my experience FAR much less hassle.
You are basically saying that, given enough resources, you can precalculate all hashes for all possible passwords in advance.
Can the same be said for keys? Given enough resources, you could precalculate all possible public/private key combinations, right?
Please don't get me wrong --- I'm not saying that the resources needed are equal (or even comparable) for the two cases.
But theoretically, both keys and passwords rely on the assumption that the "inverse operation" (be it calculating a password from a hash or factoring a large integer into primes) is too expensive to be feasible. But "given enough time and resources", you could in principle have prebuilt tables for both, right?
Just asking... :-) ...while waiting for the first successful build of a quantum computer, which will fundamentally redefine all current concepts of security... ;-)
Best, :-) Marko
On Friday, December 30, 2011 11:19:46 AM Marko Vojinovic wrote:
You are basically saying that, given enough resources, you can precalculate all hashes for all possible passwords in advance.
Can the same be said for keys? Given enough resources, you could precalculate all possible public/private key combinations, right?
Public key crypto's security is based on the cost of factoring and finding large prime numbers; hashing is somewhat different and relies on 'one-way' functions that are very difficult to reverse. There are similarities and some sharing between the algorithms, but the difficulty of reversal is based on different mathematical properties.
However, at least for some hashes on some OS's, precalculation of partial hashes is no theory; lookup 'Rainbow Tables' some day. (see https://en.wikipedia.org/wiki/Rainbow_tables )
On 12/31/2011 01:19 AM, Marko Vojinovic wrote:
On Friday 30 December 2011 19:40:55 夜神 岩男 wrote: [snip]
We can start a 10,000 computer botnet (or, more realistically, a 10m computer botnet these days, and this is a technique used right now) working on the problem of assembling a new index table that orders and assigns every possible valid hash said algorithm can produce, and start assigning values.
Essentially, we can move the computing cost up-front by assuming that we indeed *do* have to try *every* possible password, which means computing done 5 years ago applies to your brand new password today.
[snip]
In short, keys, man, keys. Its not perfect, but it is much stronger than passwords and in my experience FAR much less hassle.
You are basically saying that, given enough resources, you can precalculate all hashes for all possible passwords in advance.
Can the same be said for keys? Given enough resources, you could precalculate all possible public/private key combinations, right?
Please don't get me wrong --- I'm not saying that the resources needed are equal (or even comparable) for the two cases.
But theoretically, both keys and passwords rely on the assumption that the "inverse operation" (be it calculating a password from a hash or factoring a large integer into primes) is too expensive to be feasible. But "given enough time and resources", you could in principle have prebuilt tables for both, right?
Just asking... :-) ...while waiting for the first successful build of a quantum computer, which will fundamentally redefine all current concepts of security... ;-)
Yes, theoretically it is possible to precalculate the hashes of everything against everything. Seriously. Of course, the only groups with the current resources to actually build hash indexes against serious keys are governments, and there are limits there even.
The cost is what prevents this, which is why cryptographic security can never, ever sit still.
And you're right about quantum computing changing the game. In fact, it can change the game so much that physical and information security will once again become one and the same, period [1].
Considering this and how close we are to quantum computing, I find the "rush to the cloud" for business and personal data storage laugably shortsighted.
-Iwao
1.Ok, there is actually a way around this which relies on quantum hashing, but I don't know the terms for this in English. It depends on the idea that you can only observe some articles of data a single time before the act of observation forces an alteration of state: In other words it does nothing to encrypt the data, but rather you can know 100% if the data has been intercepted at all. But its ridiculously finnicky right now because its so new, so don't expect this for a long time.
I think the best password policy is the one you've never told anyone and never posted on a public mailing list.
How many of you out there know of cases where administrators' passwords were compromised by brute force? Can we take a count of that?
I believe in passwords. I don't believe in PKI. It's a lot more likely that I will forget my laptop somewhere, or that someone will steal my usb key than that someone will guess my password and have opportunities to try it. PKI is convenience and if your password is 20-30 characters it will take long time to break it.
Password crack estimator http://www.mandylionlabs.com/documents/BFTCalc.xls
Spreadsheet is safe (take my word for it) ha,ha
Scenario of botnet with 1000 PCs making attempts to crack are password ain't gonna happen.
-Alex
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of ?? ?? Sent: Friday, December 30, 2011 9:07 AM To: centos@centos.org Subject: Re: [CentOS] what percent of time are there unpatched exploits against default config?
On 12/31/2011 01:19 AM, Marko Vojinovic wrote:
On Friday 30 December 2011 19:40:55 夜神 岩男 wrote: [snip]
We can start a 10,000 computer botnet (or, more realistically, a 10m computer botnet these days, and this is a technique used right now) working on the problem of assembling a new index table that orders and assigns every possible valid hash said algorithm can produce, and start assigning values.
Essentially, we can move the computing cost up-front by assuming that we indeed *do* have to try *every* possible password, which means computing done 5 years ago applies to your brand new password today.
[snip]
In short, keys, man, keys. Its not perfect, but it is much stronger than passwords and in my experience FAR much less hassle.
You are basically saying that, given enough resources, you can precalculate all hashes for all possible passwords in advance.
Can the same be said for keys? Given enough resources, you could precalculate all possible public/private key combinations, right?
Please don't get me wrong --- I'm not saying that the resources needed are equal (or even comparable) for the two cases.
But theoretically, both keys and passwords rely on the assumption that the "inverse operation" (be it calculating a password from a hash or factoring a large integer into primes) is too expensive to be feasible. But "given enough time and resources", you could in principle have prebuilt tables for both, right?
Just asking... :-) ...while waiting for the first successful build of a quantum computer, which will fundamentally redefine all current concepts of security... ;-)
Yes, theoretically it is possible to precalculate the hashes of everything against everything. Seriously. Of course, the only groups with the current resources to actually build hash indexes against serious keys are governments, and there are limits there even.
The cost is what prevents this, which is why cryptographic security can never, ever sit still.
And you're right about quantum computing changing the game. In fact, it can change the game so much that physical and information security will once again become one and the same, period [1].
Considering this and how close we are to quantum computing, I find the "rush to the cloud" for business and personal data storage laugably shortsighted.
-Iwao
1.Ok, there is actually a way around this which relies on quantum hashing, but I don't know the terms for this in English. It depends on the idea that you can only observe some articles of data a single time before the act of observation forces an alteration of state: In other words it does nothing to encrypt the data, but rather you can know 100% if the data has been intercepted at all. But its ridiculously finnicky right now because its so new, so don't expect this for a long time. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 12/30/11 9:02 PM, Alex Milojkovic wrote:
I believe in passwords. I don't believe in PKI. It's a lot more likely that I will forget my laptop somewhere, or that someone will steal my usb key than that someone will guess my password and have opportunities to try it.
you're supposed to password protect your PKI keystore.
It's been an interesting if somewhat heated discussion. Figures the fun ones come up when I'm away. ;)
The discussion of using Certs(PKI) vs Passwords to secure SSH seem to be missing an important piece of the puzzle, and that to my mind is attack vectors & target value.
The argument I saw against PKI is that's it's no more secure then regular passwords because your certificates are password protected anyways and stored on external media so they can be stolen and used to access the system.
Like the OP I run a web server (two in my case) and I have external SSH access for certain reasons. I've got things like fail2ban installed, various logwatch type software running to alert me to any abnormal entries. I also have cert based access to my machine.
In my case, the primary attack vector for hackers getting at my servers is via the web. Because I host primarily personal websites on my servers, the hackers motivation for breaking into my server (aside from 'it's there') is to turn the machine into a bot-net or host some viagra phishing sites on it.
The concern, for me, is more about remote compromise then about physical theft of my usb token. A russian hacker who want's another compromised machine for his bot-net or phishing ring is probably not going to go to the effort of physically flying over here from Europe and spend the time needed to track me down, break into my office, and steal my usb token. He's more likely to move onto another target one of his script-kiddies found for him.
Drew wrote:
In my case, the primary attack vector for hackers getting at my servers is via the web. Because I host primarily personal websites on my servers, the hackers motivation for breaking into my server (aside from 'it's there') is to turn the machine into a bot-net or host some viagra phishing sites on it.
I'm in much the same situation, and would like to protect myself to a minimal extent. But I don't understand how a usb token (below) would help.
I'm probably showing my ignorance. (The only protection I take is to run fail2ban.)
The concern, for me, is more about remote compromise then about physical theft of my usb token. A russian hacker who want's another compromised machine for his bot-net or phishing ring is probably not going to go to the effort of physically flying over here from Europe and spend the time needed to track me down, break into my office, and steal my usb token. He's more likely to move onto another target one of his script-kiddies found for him.
I'm in much the same situation, and would like to protect myself to a minimal extent. But I don't understand how a usb token (below) would help.
The 'token' in this case (a standard usb thumbdrive) is merely a portable container for my ssh certificates and a copy of putty (when I'm on a windows box). You don't need it if you never move around. What matters is the use of the certificate.
Token may have been the incorrect word as RSA's keyfobs are sometime called tokens.
On Sat, Dec 31, 2011 at 05:43:54AM -0800, Drew wrote:
The argument I saw against PKI is that's it's no more secure then regular passwords because your certificates are password protected anyways and stored on external media so they can be stolen and used to access the system.
Typical security is based around three things: 1. Something you know (eg password) 2. Something you have (eg physical token, USB key, ssh private key) 3. Something you are (eg fingerprint)
Passwords are "1 factor"; it's just a password. RSA SecurID tokens are "2 factor"; you need the number on the token and the PIN. The more factors you have, typically the stronger the protection. (Assuming proper implementation, of course!)
In the same way, public key authentication is 2 factor (in the SSH implementation, anyway) because you need the private key and the passphrase to the key. (historically, passphrases were longer than 8 character passwords but that's not so true on many systems, today)
Why is this more secure? Because a gazillion people can brute force attack a box protected by passwords, however only people who have physical access to the token (#2) can attack my box. By stealing the token they've reduced my protection to single factor. BUT, and this is an important but, they _have to steal it first_.
SSH keys are weaker than RSA tokens because an SSH key can be duplicated without the owners knowledge; if you steal my RSA key then I'll know! But you still need to duplicate it, and that makes it stronger than password auth.
The good thing about PKI is that it takes longer to break. The bad thing about PKI is many admins keep many private keys in the same spot. So you figure out one password, many doors are open.
--Alex
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Stephen Harris Sent: Saturday, December 31, 2011 6:41 AM To: CentOS mailing list Subject: Re: [CentOS] what percent of time are there unpatched exploits against default config?
On Sat, Dec 31, 2011 at 05:43:54AM -0800, Drew wrote:
The argument I saw against PKI is that's it's no more secure then regular passwords because your certificates are password protected anyways and stored on external media so they can be stolen and used to access the system.
Typical security is based around three things: 1. Something you know (eg password) 2. Something you have (eg physical token, USB key, ssh private key) 3. Something you are (eg fingerprint)
Passwords are "1 factor"; it's just a password. RSA SecurID tokens are "2 factor"; you need the number on the token and the PIN. The more factors you have, typically the stronger the protection. (Assuming proper implementation, of course!)
In the same way, public key authentication is 2 factor (in the SSH implementation, anyway) because you need the private key and the passphrase to the key. (historically, passphrases were longer than 8 character passwords but that's not so true on many systems, today)
Why is this more secure? Because a gazillion people can brute force attack a box protected by passwords, however only people who have physical access to the token (#2) can attack my box. By stealing the token they've reduced my protection to single factor. BUT, and this is an important but, they _have to steal it first_.
SSH keys are weaker than RSA tokens because an SSH key can be duplicated without the owners knowledge; if you steal my RSA key then I'll know! But you still need to duplicate it, and that makes it stronger than password auth.
On 12/30/2011 11:02 PM, Alex Milojkovic wrote:
I think the best password policy is the one you've never told anyone and never posted on a public mailing list.
How many of you out there know of cases where administrators' passwords were compromised by brute force? Can we take a count of that?
I know of plenty ... people contact security@centos.org all the time after having their machines compromised by brute force.
Here are a couple of articles for you to read:
http://www.gtri.gatech.edu/casestudy/Teraflop-Troubles-Power-Graphics-Proces...
http://www.pcpro.co.uk/blogs/2011/06/01/how-a-cheap-graphics-card-could-crac...
I believe in passwords. I don't believe in PKI. It's a lot more likely that I will forget my laptop somewhere, or that someone will steal my usb key than that someone will guess my password and have opportunities to try it. PKI is convenience and if your password is 20-30 characters it will take long time to break it.
Password crack estimator http://www.mandylionlabs.com/documents/BFTCalc.xls
Spreadsheet is safe (take my word for it) ha,ha
Scenario of botnet with 1000 PCs making attempts to crack are password ain't gonna happen.
You don't need a botnet of 1000 PCs ... you only need a couple of graphics cards.
-Alex
Hello Johnny,
On Sat, 2011-12-31 at 08:13 -0600, Johnny Hughes wrote:
Here are a couple of articles for you to read:
http://www.gtri.gatech.edu/casestudy/Teraflop-Troubles-Power-Graphics-Proces...
http://www.pcpro.co.uk/blogs/2011/06/01/how-a-cheap-graphics-card-could-crac...
You don't need a botnet of 1000 PCs ... you only need a couple of graphics cards.
Please enlighten me how this has any bearing on remotely brute forcing an SSH login? The number of passwords tried is limited by the daemon, not the amount of processing power the attacker has available.
The examples you provide require the attacker to have access to the hash table, f.e. /etc/shadow, which supposedly is not the case if they haven't been able to login to your system yet.
Regards, Leonard.
On 12/31/2011 03:13 PM, Johnny Hughes wrote:
On 12/30/2011 11:02 PM, Alex Milojkovic wrote:
I think the best password policy is the one you've never told anyone and never posted on a public mailing list.
How many of you out there know of cases where administrators' passwords were compromised by brute force? Can we take a count of that?
I know of plenty ... people contact security@centos.org all the time after having their machines compromised by brute force.
Here are a couple of articles for you to read:
http://www.gtri.gatech.edu/casestudy/Teraflop-Troubles-Power-Graphics-Proces...
http://www.pcpro.co.uk/blogs/2011/06/01/how-a-cheap-graphics-card-could-crac...
I believe in passwords. I don't believe in PKI. It's a lot more likely that I will forget my laptop somewhere, or that someone will steal my usb key than that someone will guess my password and have opportunities to try it. PKI is convenience and if your password is 20-30 characters it will take long time to break it.
Password crack estimator http://www.mandylionlabs.com/documents/BFTCalc.xls
Spreadsheet is safe (take my word for it) ha,ha
Scenario of botnet with 1000 PCs making attempts to crack are password ain't gonna happen.
You don't need a botnet of 1000 PCs ... you only need a couple of graphics cards.
Can you please explain how this is possible by attacking linux via ssh brute force. I fail to see it. If attacks are throttled via ssh config and fail2ban/danyhosts, how does their GPU power comes into equation?
Hello Johnny,
On Sat, 2011-12-31 at 08:13 -0600, Johnny Hughes wrote:
http://www.gtri.gatech.edu/casestudy/Teraflop-Troubles-Power-Graphics-Proces...
http://www.pcpro.co.uk/blogs/2011/06/01/how-a-cheap-graphics-card-could-crac...
These articles fail to clarify even the most basic of assumptions they make. I can only guess the numbers relate to the cracking of MD5 hashes (salted or unsalted?) and access to the /etc/shadow file.
On CentOS-6 password hashes are no longer stored as MD5, but as SHA-512 hashes. Apparently the SHA hashing algorithms as used by Red Hat have a configurable iterator count much like bcrypt ( http://en.wikipedia.org/wiki/Crypt_%28Unix%29 "SHA2-based scheme").
Also, the only way for an attacker to have access to /etc/shadow is to already have root access to your system in which case you are already faqed.
Imo the weakness of MD5 hashes is more of a concern for web applications where an attacker might gain access to (part of) your database via f.e. SQL injection. This is why a proper web application will use a bcrypt hash to store passwords. As the amount of iterations bcrypt uses is configurable the algorithm can scale with increasing processing power.
Regards, Leonard.
On Sat, Dec 31, 2011 at 8:13 AM, Johnny Hughes johnny@centos.org wrote:
Scenario of botnet with 1000 PCs making attempts to crack are password ain't gonna happen.
You don't need a botnet of 1000 PCs ... you only need a couple of graphics cards.
If you have a stolen passphrase-protected ssh private key, is it possible to brute-force the passphrase directly, or can success only be determined by checking against a copy of the public key?
Thanks Johnny, Yes if you have console access to the server and can plug in the GPU and/or have access to the password file.
Ok let me rephrase myself. How many people have had their passwords cracked on Internet servers by means available to them? In other words gained root access by way of a TCP service.
These articles are based on theoretical math and scenarios that are not common. They are saying one billion passwords per second How many servers can handle a million requests per second without DOS, I'd like to have one :)
But the reality is that most passwords are taken through flaws in the software run as root or by weak password and obvious user names.
Everything else is more or less social engineering in my opinion and shouldn't focus on passwords. In that case no authentication mechanism will be enough, we are just fooling ourselves. If someone can gain physical access to your server you've got other problems, not password problems. It's not the fault of the developer /password mechanism. One weakness in Unix is that root account. Everyone knows it's there and everyone's trying it. When will it be possible to set your own admin username, that'd be nice. In Windows you can rename Administrator which helps.
Internet is still an infant. Hopefully sometime soon, perimeter routers will be like border checkpoints. I like you, you get in. I don't like you, you stay out. IP address allocation needs to be done smarter so that geographical regions can be isolated easier. And at some point it probably will be. Internet has facilitated the biggest financial/intellectual losses during such a short time of its existence. I believe that needs to change.
Good discussion
--Alex
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Johnny Hughes Sent: Saturday, December 31, 2011 6:14 AM To: centos@centos.org Subject: Re: [CentOS] what percent of time are there unpatched exploits against default config?
On 12/30/2011 11:02 PM, Alex Milojkovic wrote:
I think the best password policy is the one you've never told anyone and never posted on a public mailing list.
How many of you out there know of cases where administrators' passwords were compromised by brute force? Can we take a count of that?
I know of plenty ... people contact security@centos.org all the time after having their machines compromised by brute force.
Here are a couple of articles for you to read:
http://www.gtri.gatech.edu/casestudy/Teraflop-Troubles-Power-Graphics-Proces...
http://www.pcpro.co.uk/blogs/2011/06/01/how-a-cheap-graphics-card-could-crac...
I believe in passwords. I don't believe in PKI. It's a lot more likely that I will forget my laptop somewhere, or that someone will steal my usb key than that someone will guess my password and have opportunities to try it. PKI is convenience and if your password is 20-30 characters it will take long time to break it.
Password crack estimator http://www.mandylionlabs.com/documents/BFTCalc.xls
Spreadsheet is safe (take my word for it) ha,ha
Scenario of botnet with 1000 PCs making attempts to crack are password ain't gonna happen.
You don't need a botnet of 1000 PCs ... you only need a couple of graphics cards.
-Alex
On Sat, Dec 31, 2011 at 1:50 PM, Alex Milojkovic centos@businessforce.ca wrote:
Ok let me rephrase myself. How many people have had their passwords cracked on Internet servers by means available to them? In other words gained root access by way of a TCP service.
Someone cracked my gmail password and sent what seemed like an oddly small amount of spam from it.
These articles are based on theoretical math and scenarios that are not common. They are saying one billion passwords per second How many servers can handle a million requests per second without DOS, I'd like to have one :)
If you have a server with port 22 open to the internet you can get an idea of what is going on by looking at your logs. Unless you are a high-profile site you probably won't see millions of attempts, but you will see dozens or hundreds a day, coming from many different sources. They seem to be at least loosely coordinated and are probably spreading the attempts widely. If your machine happens to be the one where they get a match from the random probabilities, it likely gets added into the set doing more attempts.
Everything else is more or less social engineering in my opinion and shouldn't focus on passwords. In that case no authentication mechanism will be enough, we are just fooling ourselves.
Targeted cracking may involve social engineering, but I'd bet that much, much more of the random hacking involves software vulnerabilities, both before and after they are published. Again, if you look at the logs of what hits port 80 you'll see the probes for things that might permit arbitrary code execution. Unless one of those succeeds, you won't see the followup - but if it does, the attacker will then attempt to execute local 'root escalation' vulnerabilities like the one fixed not too long ago in glibc that let anyone who could create a symlink become root.
Hopefully sometime soon, perimeter routers will be like border checkpoints. I like you, you get in. I don't like you, you stay out.
That doesn't work for web services open to the public. You need firewalls that can work at wire speed filtering the inbound URLs for known attack patterns, plus of course, updating the software as quickly as possible to fix the vulnerabilities.
Les Mikesell wrote:
Someone cracked my gmail password and sent what seemed like an oddly small amount of spam from it.
gmail and hotmail must be very easy to crack, or is there some check apart from the password?
That doesn't work for web services open to the public. You need firewalls that can work at wire speed filtering the inbound URLs for known attack patterns, plus of course, updating the software as quickly as possible to fix the vulnerabilities.
Yes, I'm more worried about attacks through port 80. Can anyone point me to documentation on protecting a web-server?
On Sun, Jan 1, 2012 at 11:45 AM, Timothy Murphy gayleard@alice.it wrote:
Les Mikesell wrote:
Someone cracked my gmail password and sent what seemed like an oddly small amount of spam from it.
gmail and hotmail must be very easy to crack, or is there some check apart from the password?
That doesn't work for web services open to the public. You need firewalls that can work at wire speed filtering the inbound URLs for known attack patterns, plus of course, updating the software as quickly as possible to fix the vulnerabilities.
Yes, I'm more worried about attacks through port 80. Can anyone point me to documentation on protecting a web-server?
A server serving just static pages on port 80 would be pretty much safe. A server that provides dynamic pages (eg script-generated with a database backend) can never be completely safe. A book like this is probably what you are looking for:
Cheers,
Cliff
On 12/31/2011 11:45 PM, Timothy Murphy wrote:
Les Mikesell wrote:
Yes, I'm more worried about attacks through port 80. Can anyone point me to documentation on protecting a web-server?
You should check http://www.snort.org, IDS system. ClearOS has them integrated.
I can not remember if can detect crafted http attacks, but it does MySQL, MSSQL protection etc.
On 01/01/2012 09:14 PM, Ljubomir Ljubojevic wrote:
On 12/31/2011 11:45 PM, Timothy Murphy wrote:
Les Mikesell wrote:
Yes, I'm more worried about attacks through port 80. Can anyone point me to documentation on protecting a web-server?
You should check http://www.snort.org, IDS system. ClearOS has them integrated.
I can not remember if can detect crafted http attacks, but it does MySQL, MSSQL protection etc.
It looks like it can detect (at least certain) http attacks.
Also look at: http://www.bleedingsnort.com/about/ http://www.openinfosecfoundation.org/ http://www.emergingthreats.net/
IP address allocation needs to be done smarter so that geographical regions can be isolated easier. And at some point it probably will be.
There already is that capability to some extent. Between geoip and the RIR's, one can get a pretty good handle on which /8 or /16 blocks need to be blocked at your firewall. In fact the linux based router's we use have a specific "Country Blocking" feature which I use to block large swathes of the Net from our systems.
IP address allocation needs to be done smarter so that geographical regions can be isolated easier. And at some point it probably will be.
There already is that capability to some extent. Between geoip and the RIR's, one can get a pretty good handle on which /8 or /16 blocks need to be blocked at your firewall. In fact the linux based router's we use have a specific "Country Blocking" feature which I use to block large swathes of the Net from our systems.
We've been thinking of using the MaxMind GeoIP Country database with Apache mod_geoip API to limit certain countries visiting our websites.
Has anyone used this or have any input on it's usefulness?
On Sat, 2011-12-31 at 15:17 -0700, Ken godee wrote:
IP address allocation needs to be done smarter so that geographical regions can be isolated easier. And at some point it probably will be.
There already is that capability to some extent. Between geoip and the RIR's, one can get a pretty good handle on which /8 or /16 blocks need to be blocked at your firewall. In fact the linux based router's we use have a specific "Country Blocking" feature which I use to block large swathes of the Net from our systems.
We've been thinking of using the MaxMind GeoIP Country database with Apache mod_geoip API to limit certain countries visiting our websites.
Has anyone used this or have any input on it's usefulness?
---- totally works (maxmind/geoip - at least it did for me with a rubyonrails app)
I wouldn't know how to use it for http blocking but it's probably possible but it would seem to be far more effective at a firewall level.
Craig
On 12/31/11 2:17 PM, Ken godee wrote:
We've been thinking of using the MaxMind GeoIP Country database with Apache mod_geoip API to limit certain countries visiting our websites.
Has anyone used this or have any input on it's usefulness?
the virus/worm folks will just move to open relays that are not blocked. I have something like 1/2 the total IP space blocked on this one forum I host that seems to attract a very large number of bogus signups, and it hasn't abated the 50-100/day of fake registrations yet. there's now 1700 subnets and another 1000 specific IPs blocked. I can tell they are robotic assisted fake registrations because the 'Bio' field ('about you, why you want to join this forum') is always filled with one of 4 specific entries ("LO qUe eS bRaKbEaT", "Me gusta la guasa", "Loading...", or less often, "Robot"). initially, the vast majority of these fake registrations came from china, russia. now they are coming from everywhere since I have almost all of china and russia blocked.
On 12/31/11 2:17 PM, Ken godee wrote:
We've been thinking of using the MaxMind GeoIP Country database with Apache mod_geoip API to limit certain countries visiting our websites.
Has anyone used this or have any input on it's usefulness?
the virus/worm folks will just move to open relays that are not blocked. I have something like 1/2 the total IP space blocked on this one forum I host that seems to attract a very large number of bogus signups, and it hasn't abated the 50-100/day of fake registrations yet. there's now 1700 subnets and another 1000 specific IPs blocked. I can tell they are robotic assisted fake registrations because the 'Bio' field ('about you, why you want to join this forum') is always filled with one of 4 specific entries ("LO qUe eS bRaKbEaT", "Me gusta la guasa", "Loading...", or less often, "Robot"). initially, the vast majority of these fake registrations came from china, russia. now they are coming from everywhere since I have almost all of china and russia blocked.
Grrr... didn't think of that. A quick google shows plenty of free or low cost US proxy servers. That would be the first thing I would do.
Yes, but this is left to every server admin to do. Then if some don't do it and get hacked it pretty much defeats the rest if their "home" based servers are used as bots. What I'm talking about is a national policy using perimeter routers and better netblock allocation. The reason netblocks should be better organized is that if you have many rules in your router it takes time to process the rules. If you have 10,000 lines of rules in out firewall it takes some time to go through them. It's easy enough to copy a bunch of CIDR addresses and add them, but I just see it as unnecessary overhead for your router. If you choke the whole thing at the source, there is no way anyone sitting in "that" place to access anything on under your watch. It's like international relations. You like me, I like you, you have an embassy in my town, I have an embassy in your town. You peeve me off, I close my embassy and close my Internet pipe too. They should add Internet pipe to the table. I'm oversimplifying, but that's the idea. Internet was such a great thing and everyone was enamored with it so quickly because it opened so many possibilities that no one thought about the doors we didn't want to open. I think some of these changes are coming.
--Alex Happy New Year Y'all !
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Drew Sent: Saturday, December 31, 2011 2:07 PM To: CentOS mailing list Subject: Re: [CentOS] what percent of time are there unpatched exploits against default config?
IP address allocation needs to be done smarter so that geographical
regions can be isolated easier. And at some point it probably will be.
There already is that capability to some extent. Between geoip and the RIR's, one can get a pretty good handle on which /8 or /16 blocks need to be blocked at your firewall. In fact the linux based router's we use have a specific "Country Blocking" feature which I use to block large swathes of the Net from our systems.
-- Drew
"Nothing in life is to be feared. It is only to be understood." --Marie Curie _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 12/31/11 5:06 PM, Alex Milojkovic wrote:
I think some of these changes are coming.
careful what you wish for, it may come true...
...those changes ARE coming, but they are coming at the request of the movie and music industries who are trying to legislate the ability to demand domain names be blocked based on accusations. IANAL, but as I read the proposed legislation, running your own DNS server that attempts to circumvent these blocks is being elevated to a felony.
may I add... this thread has drifted *WAY* off scope for this list, and belongs elsewhere. NOTHING here is specific to CentOS.
On 12/30/2011 09:02 PM, Alex Milojkovic wrote:
Scenario of botnet with 1000 PCs making attempts to crack are password ain't gonna happen.
On one system that I run, for a fairly popular domain, I see botnet attacks trying to break in to the pop and ftp ports as well as botnet spam and SASL auth attacks on the smtp port. My ssh port is not open to the outside world.
The attacks come and go in waves, but If I don't use various limiting tools, they will try sometimes to make as many as 50 simultaneous connections to my server. I saw this the worst with spam on the smtp port.
fail2ban is not so effective on botnet attacks. Newer version of postfix include postscreen, a front end which blocks botnet attacks (but only for smtp connections). I plan to install it.
I have found that most of the attacks are coming from china, south korea, japan, russia, various south american countries. I would like to start blocking access to certain services from some countries. I've been considering using ipdeny.com data.
Does ipset work with the existing kernel under CentOS 5 and if so is there an RPM available? I've goggled around a bit, but haven't found anything. From http://ipset.netfilter.org/ I'm led to believe that the current kernel should support it.
Nataraj
Does ipset work with the existing kernel under CentOS 5 and if so is there an RPM available? I've goggled around a bit, but haven't found anything. From http://ipset.netfilter.org/ I'm led to believe that the current kernel should support it.
Well, you have modules on your system, and if you Google you'll see a couple repos have the userland tools. Check out CentALT for example...
I actually found a link on Apnic's web site to their IPv4 netblocks which helped me eliminate their traffic.
http://www.apnic.net/publications/research-and-insights/ip-address-trends/ap nic-resource-range
This solved most of my problems. There are not as many lines as one would expect. Just go to other NICs and look for this info
-Alex
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Nataraj Sent: Sunday, January 01, 2012 3:26 PM To: centos@centos.org Subject: Re: [CentOS] what percent of time are there unpatched exploits against default config?
On 12/30/2011 09:02 PM, Alex Milojkovic wrote:
Scenario of botnet with 1000 PCs making attempts to crack are password
ain't gonna happen.
On one system that I run, for a fairly popular domain, I see botnet attacks trying to break in to the pop and ftp ports as well as botnet spam and SASL auth attacks on the smtp port. My ssh port is not open to the outside world.
The attacks come and go in waves, but If I don't use various limiting tools, they will try sometimes to make as many as 50 simultaneous connections to my server. I saw this the worst with spam on the smtp port.
fail2ban is not so effective on botnet attacks. Newer version of postfix include postscreen, a front end which blocks botnet attacks (but only for smtp connections). I plan to install it.
I have found that most of the attacks are coming from china, south korea, japan, russia, various south american countries. I would like to start blocking access to certain services from some countries. I've been considering using ipdeny.com data.
Does ipset work with the existing kernel under CentOS 5 and if so is there an RPM available? I've goggled around a bit, but haven't found anything.
From http://ipset.netfilter.org/ I'm led to believe that the current kernel
should support it.
Nataraj
_______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Thursday, December 29, 2011 12:33:41 PM Ljubomir Ljubojevic wrote:
If you use denyhosts or fail2ban, attacker needs 10,000 attack PC's that never attacked any denyhosts or fail2ban server in recent time.
That would be a very small botnet.
And with gamers out there with CUDA-capable GPU's getting botted......
The scale of the botnets doing brute-forcing (among other nefariousness) should never be underestimated. In addition to fail2ban, simple user-based login timeouts and lockouts can be used that survive botnet brute-forcing, but are DoS sitting ducks because of it.
Security is a hard problem. There is no magic bullet.
Recent news should show that....
Lamar Owen wrote:
On Thursday, December 29, 2011 12:33:41 PM Ljubomir Ljubojevic wrote:
If you use denyhosts or fail2ban, attacker needs 10,000 attack PC's that never attacked any denyhosts or fail2ban server in recent time.
That would be a very small botnet.
And with gamers out there with CUDA-capable GPU's getting botted......
And, as a co-worker says, let's not forget renting time on Amazon's cloud.... <snip>
mark
There is a concept called dynamic firewall i am working on that should eliminate any brute force attempts. If you think about it, if you know someone is trying to break in there is no need to give them access to the server any more. So after a hundred wrong passwords you cut them off.
Reindl Harald h.reindl@thelounge.net wrote:
Am 29.12.2011 12:56, schrieb Leonard den Ottolander:
Hello Reindl,
On Thu, 2011-12-29 at 12:29 +0100, Reindl Harald wrote:
Am 29.12.2011 09:17, schrieb Bennett Haselton:
Even though the ssh key is more random, they're both sufficiently random that it would take at
least
hundreds of years to get in by trial and error.
if you really think your 12-chars password is as secure as a ssh-key protcected with this password you should consider to take some education in security
Bennett clearly states that he understands the ssh key is more
random,
but wonders why a 12 char password (of roughly 6 bits entropy per
byte
assuming upper & lower case characters and numbers) wouldn't be sufficient.
so explain me why discuss to use or not to use the best currently availbale method in context of security?
this is a secure configuration with no costs so why not use it?
PasswordAuthentication no ChallengeResponseAuthentication no GSSAPIAuthentication no GSSAPICleanupCredentials no RSAAuthentication yes PubkeyAuthentication yes PermitEmptyPasswords no PermitRootLogin without-password AllowGroups root verwaltung AllowUsers root harry IgnoreRhosts yes HostbasedAuthentication no StrictModes yes UseDNS no UsePrivilegeSeparation yes UsePAM yes LoginGraceTime 25 MaxAuthTries 10 MaxStartups 25
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 12/30/2011 03:55 AM, Alex Milojkovic wrote:
There is a concept called dynamic firewall i am working on that should eliminate any brute force attempts. If you think about it, if you know someone is trying to break in there is no need to give them access to the server any more. So after a hundred wrong passwords you cut them off.
On 12/29/2011 05:17 PM, Bennett Haselton wrote:
On Wed, Dec 28, 2011 at 6:10 AM, Johnny Hughesjohnny@centos.org wrote:
On 12/27/2011 10:42 PM, Bennett Haselton wrote:
- Why have password logins at all? Using a secure ssh key only for
logins makes the most sense.
Well that's something that I'm curious about the reasoning behind -- if you're already using a completely random 12-character password, why would it be any more secure to use an ssh key? Even though the ssh key is more random, they're both sufficiently random that it would take at least hundreds of years to get in by trial and error.
I'm almost afraid to see the responses to this comment...
If you believe that passwords are as secure as SSH2 keys, then you've got some homework to do before second guessing anyone's security policy. I don't say that as a jab, I'm being totally serious.
The good side of this conversation is that you may become motivated to learn about security as a hobby after this. Its a lot more interesting than watching TV after work (but a lot less interesting than playing with real people (friends, kids, wife, whatever)).
- Please do not top post.
My bad. Gmail default. :)
It is the devil.
On 12/28/2011 01:29 PM, Bennett Haselton wrote:
On Tue, Dec 27, 2011 at 8:33 PM, Gilbert Sebenste< sebenste@weather.admin.niu.edu> wrote:
On Tue, 27 Dec 2011, Bennett Haselton wrote:
Suppose I have a CentOS 5.7 machine running the default Apache with no extra modules enabled, and with the "yum-updatesd" service running to
pull
down and install updates as soon as they become available from the repository.
So the machine can still be broken into, if there is an unpatched exploit released in the wild, in the window of time before a patch is released
for
that update.
Roughly what percent of the time is there such an unpatched exploit in
the
wild, so that the machine can be hacked by someone keeping up with the exploits? 5%? 50%? 95%?
There's no way to give you an exact number, but let me put it this way:
If you've disable as much as you can (which by default, most stuff is disabled, so that's good), and you restart Apache after each update, your chances of being broken into are better by things like SSH brute force attacks. There's always a chance someone will get in, but when you look at the security hole history of Apache, particularly over the past few years, there have been numerous CVE's, but workarounds and they aren't usually earth-shattering. Very few of them have. The latest version that ships with 5.7 is as secure as they come. If it wasn't, most web sites on the Internet would be hacked by now, as most run Apache
I was asking because I had a server that did get broken into, despite having yum-updatesd running and a strong password. He said that even if you apply all latest updates automatically, there were still windows of time where an exploit in the wild could be used to break into a machine; in particular he said:
"For example, there was a while back ( ~march ) a kernel exploit that affected CentOS / RHEL. The patch came after 1-2 weeks of the security announcement. The initial announcement provided a simple work around until the new version is released."
Was this a sufficiently high-profile incident that you know what he's referring to? If this kind of thing happens once a year or more, than surely this is a much greater threat than "brute forcing the SSH password"? That's what I'm talking about -- how often does this sort of thing happen, where you need to be subscribed to be a security mailing list in order to know what workaround to make to stay safe, as opposed to simply running yum-updatesd to install latest patches automatically.
Nearly every time servers get broken into they are web servers, and web servers serving applications the greatest percentage of those. The "web" never having been intended as an applications platform provides a huge number of attack vectors which are entirely separate from the OS layer.
For example, a perfectly secure operating system running a perfectly secure Apache configuration on a perfectly secure MySQL deployment could be running an application that permits injection of arbitrary SQL commands into the database. The server itself may not be compromised (or it may, depending on what else that SQL command can touch/be referenced by) in the sense that someone can open a shell, but in most cases there is nothing of interest on a web server anyway. What is interesting is what is in the database or lives within the application being served, and that is an application/database layer problem, not an OS, web-server or kernel problem.
With the vast majority of web applications being developed on frameworks like Drupal, Django and Plone, the overwhelming majority of "server hacks" with regard to the web have to do with attacking these structures (at least initially), not the actual OS layer directly at the outset.
Compare this with email server software, which, if the OS layer were the inherent problem, would be heard about every day -- much more often than web-related cracks. But email server software is mature and just as secure as Apache is. However, web-based email is a common target, and for a good reason. http is inherently insecure, and bouncing someone from http to https is just as insecure because the initial http link and DNS can be attacked, both being deliberately insecure, public protocols.
Blah blah. My point is, the OS is rarely attacked directly in web-related cracks. A good cracker tries to discover flaws in young, fast changing web frameworks which require priviledged access to things like MySQL instead of trying to attack Apache or an SE-enabled OS layer directly.
Yeah I know that most break-ins do happen using third-party web apps; fortunately the servers I'm running don't have or need any of those.
But then what about what my friend said: "For example, there was a while back ( ~march ) a kernel exploit that affected CentOS / RHEL. The patch came after 1-2 weeks of the security announcement. The initial announcement provided a simple work around until the new version is released." Is that an extremely rare freak occurrence? Or are you just saying it's rare *compared* to breakins using web apps? Or am I misunderstanding what my friend was referring to in the above paragraph?
Bennett
2011/12/27 夜神 岩男 supergiantpotato@yahoo.co.jp
On 12/28/2011 01:29 PM, Bennett Haselton wrote:
On Tue, Dec 27, 2011 at 8:33 PM, Gilbert Sebenste< sebenste@weather.admin.niu.edu> wrote:
On Tue, 27 Dec 2011, Bennett Haselton wrote:
Suppose I have a CentOS 5.7 machine running the default Apache with no extra modules enabled, and with the "yum-updatesd" service running to
pull
down and install updates as soon as they become available from the repository.
So the machine can still be broken into, if there is an unpatched
exploit
released in the wild, in the window of time before a patch is released
for
that update.
Roughly what percent of the time is there such an unpatched exploit in
the
wild, so that the machine can be hacked by someone keeping up with the exploits? 5%? 50%? 95%?
There's no way to give you an exact number, but let me put it this way:
If you've disable as much as you can (which by default, most stuff is disabled, so that's good), and you restart Apache after each update, your chances of being broken into are better by things like SSH brute force attacks. There's always a chance someone will get in, but when you look at the security hole history of Apache, particularly over the past few years, there have been numerous CVE's, but workarounds and they
aren't
usually earth-shattering. Very few of them have. The latest version that ships with 5.7 is as secure as they come. If it wasn't, most web sites on the Internet would be hacked by now, as most run Apache
I was asking because I had a server that did get broken into, despite having yum-updatesd running and a strong password. He said that even if you apply all latest updates automatically, there were still windows of time where an exploit in the wild could be used to break into a machine;
in
particular he said:
"For example, there was a while back ( ~march ) a kernel exploit that affected CentOS / RHEL. The patch came after 1-2 weeks of the security announcement. The initial announcement provided a simple work around
until
the new version is released."
Was this a sufficiently high-profile incident that you know what he's referring to? If this kind of thing happens once a year or more, than surely this is a much greater threat than "brute forcing the SSH password"? That's what I'm talking about -- how often does this sort of thing happen, where you need to be subscribed to be a security mailing
list
in order to know what workaround to make to stay safe, as opposed to
simply
running yum-updatesd to install latest patches automatically.
Nearly every time servers get broken into they are web servers, and web servers serving applications the greatest percentage of those. The "web" never having been intended as an applications platform provides a huge number of attack vectors which are entirely separate from the OS layer.
For example, a perfectly secure operating system running a perfectly secure Apache configuration on a perfectly secure MySQL deployment could be running an application that permits injection of arbitrary SQL commands into the database. The server itself may not be compromised (or it may, depending on what else that SQL command can touch/be referenced by) in the sense that someone can open a shell, but in most cases there is nothing of interest on a web server anyway. What is interesting is what is in the database or lives within the application being served, and that is an application/database layer problem, not an OS, web-server or kernel problem.
With the vast majority of web applications being developed on frameworks like Drupal, Django and Plone, the overwhelming majority of "server hacks" with regard to the web have to do with attacking these structures (at least initially), not the actual OS layer directly at the outset.
Compare this with email server software, which, if the OS layer were the inherent problem, would be heard about every day -- much more often than web-related cracks. But email server software is mature and just as secure as Apache is. However, web-based email is a common target, and for a good reason. http is inherently insecure, and bouncing someone from http to https is just as insecure because the initial http link and DNS can be attacked, both being deliberately insecure, public protocols.
Blah blah. My point is, the OS is rarely attacked directly in web-related cracks. A good cracker tries to discover flaws in young, fast changing web frameworks which require priviledged access to things like MySQL instead of trying to attack Apache or an SE-enabled OS layer directly. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 12/28/2011 02:01 PM, Bennett Haselton wrote:
Yeah I know that most break-ins do happen using third-party web apps; fortunately the servers I'm running don't have or need any of those.
But then what about what my friend said: "For example, there was a while back ( ~march ) a kernel exploit that affected CentOS / RHEL. The patch came after 1-2 weeks of the security announcement. The initial announcement provided a simple work around until the new version is released." Is that an extremely rare freak occurrence? Or are you just saying it's rare *compared* to breakins using web apps? Or am I misunderstanding what my friend was referring to in the above paragraph?
Yes, that is rare. There *are* holes in nearly everything, though, and there are workarounds and patches for nearly all of those holes.
But not all holes are equal. Not nearly so. For example, the vast majority of the security announcements for RHEL are rated as very minor, despite the enormous scrutiny Linux is subjected to. That we can find SO MANY tiny holes is a testament to the thoroughness of the community approach to common component development (which is a bit different from the dynamic found in niche applications development, despite what the RHSs of the world have to say).
It is important to ask your friend two things:
1- Was the vendor involved in the announcement, and if so was the workaround explained thoroughly in the announcement and permit reconfiguration of a functional system?
Sometimes people want to make a name for themselves by "finding a hole in the Linux kernel" and try to announce things without notifying the vendor, in which case the bad guys and good guys have a race to see who will develop first, the patchers or the exploiters.
Even IBM can get caught off-guard by things like this with Big Adult systems like z/OS. Being caught off-guard is the problem Google tries to solve by providing both paying and stroking the ego of people who find security problems with their infrastructure. Preventing the malicious use of such information is what the whole "Full Disclosure" concept is about (though the mailing list of the same name is often just nothing more than trollville)
2- Did the security hole, when exploited, grant root access? Without the ability to root the machine, the picture is a lot less grim. Understanding iptables, SELinux, what apps are installed, what Apache modules aren't necessary (quite a few), etc. can go a long way to providing intermediate barriers against a big scary hole in the kernel. Consider that the kernel has one huge hole by design called root. Getting access to it is the key, and the vast majority of security announcements permit marginal, not root, system access.
To answer your original question, the "announcement in March" is not anything I heard of. Or more correctly it isn't something I remember in particular, and I tend to keep up with things. I hear about *lots* of security holes in lots of different software daily. Most of it is patched before the announcement, or patched along with the announcement. The overwhelming majority of the announcements I see are XSS and SQL injections against web frameworks -- or various ways of re-verbing existing problems with new buzzwords.
As far as "what exact % of the time" that is impossible to determine until you at the very least put a threshold on the severity of a security issue. And when it comes to some issues, frankly what some people consider a needed feature another may consider a security hole. Take FTP and Telnet, for example. "Holy crap, wotmud.org:2222 is WIDE OPEN to incoming telnet requests!" would be a ridiculous thing to proclaim, but I've seen it done. I've also seen people say "Ubuntu is WIDE OPEN because they have a new guest account by default with a consistent name!" -- as if names were equivalent to passwords.
On 12/27/2011 11:01 PM, Bennett Haselton wrote:
Yeah I know that most break-ins do happen using third-party web apps; fortunately the servers I'm running don't have or need any of those.
But then what about what my friend said: "For example, there was a while back ( ~march ) a kernel exploit that affected CentOS / RHEL. The patch came after 1-2 weeks of the security announcement. The initial announcement provided a simple work around until the new version is released." Is that an extremely rare freak occurrence? Or are you just saying it's rare *compared* to breakins using web apps? Or am I misunderstanding what my friend was referring to in the above paragraph?
There have been NO critical kernel updates. A critical update is one where someone can remotely execute items at the root users.
Almost all critical updates are Firefox, Thunderbird, telnetd (does anyone still allow telnet?), or samba (never expose that directly to the internet either :D). There was one critical issue on CentOS-5.x for exim:
http://rhn.redhat.com/errata/RHSA-2010-0970.html
All the other issues (non-critical) will require the user to get a "user shell" and then elevate their privileges some way ================================================
If you want to know what the different classifications mean:
https://access.redhat.com/security/updates/classification/
================================================ If you want objective numbers for security exploits, here is some info for RHEL:
http://www.redhat.com/security/data/metrics/
and
http://www.awe.com/mark/blog/tags/metrics
=============================================== If you want to search for a specific CVE:
https://www.redhat.com/security/data/cve/
===============================================
CentOS is currently completely updated with all released updates for CentOS-4.9, CentOS-5.7, and CentOS-6.2.
We also provide a CR repository for "Point Release" transitions (though, we will not always use the CR repo if we can get the point release out within 2-3 weeks). Here is info on the CR repository:
http://wiki.centos.org/AdditionalResources/Repositories/CR
=============================================
Long winded discussions on the list about people's opinions concerning security might help you make decisions on the best practices for setting up your server (do not allow ssh logins by password, limit logins by IP addresses (or at least block problem subnets), disable root logins directly, try to use SELinux for your web apps, etc.) ... but really, each install is unique.
A google search will provide many suggestions for best security practices, here is what upstream recommends:
http://www.centos.org/docs/5/html/Deployment_Guide-en-US/pt-security.html
The bottom line is, a default installation requires hardening. The amount of hardening needed depends on each individual install and its requirements.
On Wed, 2011-12-28 at 07:43 -0600, Johnny Hughes wrote:
There have been NO critical kernel updates. A critical update is one where someone can remotely execute items at the root users.
Almost all critical updates are Firefox, Thunderbird, telnetd (does anyone still allow telnet?), or samba (never expose that directly to the internet either :D). There was one critical issue on CentOS-5.x for exim:
http://rhn.redhat.com/errata/RHSA-2010-0970.html
All the other issues (non-critical) will require the user to get a "user shell" and then elevate their privileges some way
---- perhaps he is referring to RHSA 2011:1245 http://lists.centos.org/pipermail/centos/2011-September/118075.html
which CentOS was very slow in getting the update out the door but as you said, it was labeled 'important' and not 'critical' and of course concerned apache and not kernel.
Craig
On 12/28/2011 08:57 PM, Craig White wrote:
On Wed, 2011-12-28 at 07:43 -0600, Johnny Hughes wrote:
There have been NO critical kernel updates. A critical update is one where someone can remotely execute items at the root users.
Almost all critical updates are Firefox, Thunderbird, telnetd (does anyone still allow telnet?), or samba (never expose that directly to the internet either :D). There was one critical issue on CentOS-5.x for exim:
http://rhn.redhat.com/errata/RHSA-2010-0970.html
All the other issues (non-critical) will require the user to get a "user shell" and then elevate their privileges some way
perhaps he is referring to RHSA 2011:1245 http://lists.centos.org/pipermail/centos/2011-September/118075.html
which CentOS was very slow in getting the update out the door but as you said, it was labeled 'important' and not 'critical' and of course concerned apache and not kernel.
That flaw as absolutely no "access" component. It allows a DDOS attack, not provide remote access to a machine.
From the bug:
A flaw was found in the way the Apache HTTP Server handled Range HTTP headers. A remote attacker could use this flaw to cause httpd to use an excessive amount of memory and CPU time via HTTP requests with a specially-crafted Range header. (CVE-2011-3192)
How is that relevant to allowing access to someone's server.
Am 29.12.2011 14:59, schrieb Johnny Hughes:
That flaw as absolutely no "access" component. It allows a DDOS attack, not provide remote access to a machine.
From the bug:
A flaw was found in the way the Apache HTTP Server handled Range HTTP headers. A remote attacker could use this flaw to cause httpd to use an excessive amount of memory and CPU time via HTTP requests with a specially-crafted Range header. (CVE-2011-3192)
How is that relevant to allowing access to someone's server.
and if you have a webserver and the webserver can be easily killed with a DOS the bug is CRITICAL, if you can kill any PUBLIC SERVICE remote a bug is CRITICAL
what exactly do you not understand while these are simple facts - your definition of critical is broken if you think anything where you can not get into the machine is not
and yes i tried the demo-exploits which killed a quad-core with 16 GB memory within some seconds
On 12/29/2011 08:06 AM, Reindl Harald wrote:
Am 29.12.2011 14:59, schrieb Johnny Hughes:
That flaw as absolutely no "access" component. It allows a DDOS attack, not provide remote access to a machine.
From the bug:
A flaw was found in the way the Apache HTTP Server handled Range HTTP headers. A remote attacker could use this flaw to cause httpd to use an excessive amount of memory and CPU time via HTTP requests with a specially-crafted Range header. (CVE-2011-3192)
How is that relevant to allowing access to someone's server.
and if you have a webserver and the webserver can be easily killed with a DOS the bug is CRITICAL, if you can kill any PUBLIC SERVICE remote a bug is CRITICAL
I did not define it bozo, so stop your bullshit on this list. I have already pointed to how the classifications are done.
what exactly do you not understand while these are simple facts - your definition of critical is broken if you think anything where you can not get into the machine is not
Who the hell do you think yo0u are? You will be banned from posting on this list of you can not act appropriately.
and yes i tried the demo-exploits which killed a quad-core with 16 GB memory within some seconds
For those of you who did not see how the categories are defined, here it is:
On Wed, 2011-12-28 at 13:47 +0900, 夜神 岩男 wrote:
With the vast majority of web applications being developed on frameworks like Drupal, Django and Plone, the overwhelming majority of "server hacks" with regard to the web have to do with attacking these structures (at least initially), not the actual OS layer directly at the outset.
---- just a mention that ruby on rails just changed the methodology with version 3.x in that all displayed code is automatically escaped and you have to designate beforehand anything that you want to be evaluated as html/script which is a significant bump in security.
Craig
password"? That's what I'm talking about -- how often does this sort of thing happen, where you need to be subscribed to be a security mailing list in order to know what workaround to make to stay safe, as opposed to simply running yum-updatesd to install latest patches automatically.
Happens all the time! Count on it! If running any server available to the public there is no "set and forget" if you're responsible for that server you best stay informed/subscribed and ready to take action be it a work around, update or whatever.
On Tue, Dec 27, 2011 at 10:08 PM, Ken godee ken@perfect-image.com wrote:
password"? That's what I'm talking about -- how often does this sort of thing happen, where you need to be subscribed to be a security mailing
list
in order to know what workaround to make to stay safe, as opposed to
simply
running yum-updatesd to install latest patches automatically.
Happens all the time!
Really? An exploit is released in the wild, and there's a lag of several days before a patch is available through updates -- "all the time"? How often? Every week?
Since Gilbert and "supergiantpotato" seemed to be saying the opposite (that unpatched OS- and web-server-level exploits were pretty rare), what data were you relying on when you said that it "happens all the time"?
Count on it! If running any server available to the public there is no "set and forget" if you're responsible for that server you best stay informed/subscribed and ready to take action be it a work around, update or whatever.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 12/28/2011 01:44 AM, Bennett Haselton wrote:
On Tue, Dec 27, 2011 at 10:08 PM, Ken godee ken@perfect-image.com wrote:
password"? That's what I'm talking about -- how often does this sort of thing happen, where you need to be subscribed to be a security mailing
list
in order to know what workaround to make to stay safe, as opposed to
simply
running yum-updatesd to install latest patches automatically.
Happens all the time!
Really? An exploit is released in the wild, and there's a lag of several days before a patch is available through updates -- "all the time"? How often? Every week?
Since Gilbert and "supergiantpotato" seemed to be saying the opposite (that unpatched OS- and web-server-level exploits were pretty rare), what data were you relying on when you said that it "happens all the time"?
Count on it! If running any server available to the public there is no "set and forget" if you're responsible for that server you best stay informed/subscribed and ready to take action be it a work around, update or whatever.
This website deals specifically with RHEL and security metrics:
http://www.awe.com/mark/blog/tags/metrics
CentOS will usually release security updates within 24 hours of upstream during normal security updates and within 2 weeks on a "Point Release" (a point release is a move from 5.6 to 5.7 or 6.1 to 6.2, etc.).
If you need faster updates than CentOS can provide, then RHEL is the logical alternative.
On Dec 27, 2011, at 11:29 PM, Bennett Haselton bennett@peacefire.org wrote:
On Tue, Dec 27, 2011 at 8:33 PM, Gilbert Sebenste < sebenste@weather.admin.niu.edu> wrote:
On Tue, 27 Dec 2011, Bennett Haselton wrote:
Suppose I have a CentOS 5.7 machine running the default Apache with no extra modules enabled, and with the "yum-updatesd" service running to
pull
down and install updates as soon as they become available from the repository.
So the machine can still be broken into, if there is an unpatched exploit released in the wild, in the window of time before a patch is released
for
that update.
Roughly what percent of the time is there such an unpatched exploit in
the
wild, so that the machine can be hacked by someone keeping up with the exploits? 5%? 50%? 95%?
There's no way to give you an exact number, but let me put it this way:
If you've disable as much as you can (which by default, most stuff is disabled, so that's good), and you restart Apache after each update, your chances of being broken into are better by things like SSH brute force attacks. There's always a chance someone will get in, but when you look at the security hole history of Apache, particularly over the past few years, there have been numerous CVE's, but workarounds and they aren't usually earth-shattering. Very few of them have. The latest version that ships with 5.7 is as secure as they come. If it wasn't, most web sites on the Internet would be hacked by now, as most run Apache
I was asking because I had a server that did get broken into, despite having yum-updatesd running and a strong password. He said that even if you apply all latest updates automatically, there were still windows of time where an exploit in the wild could be used to break into a machine; in particular he said:
"For example, there was a while back ( ~march ) a kernel exploit that affected CentOS / RHEL. The patch came after 1-2 weeks of the security announcement. The initial announcement provided a simple work around until the new version is released."
What was the nature of the break-in, if I may ask? Security is more than just updates and a strong password.
- Rilindo Foster http://monzell.com http://www.linkedin.com/pub/rilindo-foster/2/b32/43b
On Tue, Dec 27, 2011 at 10:17 PM, Rilindo Foster rilindo@me.com wrote:
On Dec 27, 2011, at 11:29 PM, Bennett Haselton bennett@peacefire.org wrote:
On Tue, Dec 27, 2011 at 8:33 PM, Gilbert Sebenste < sebenste@weather.admin.niu.edu> wrote:
On Tue, 27 Dec 2011, Bennett Haselton wrote:
Suppose I have a CentOS 5.7 machine running the default Apache with no extra modules enabled, and with the "yum-updatesd" service running to
pull
down and install updates as soon as they become available from the repository.
So the machine can still be broken into, if there is an unpatched
exploit
released in the wild, in the window of time before a patch is released
for
that update.
Roughly what percent of the time is there such an unpatched exploit in
the
wild, so that the machine can be hacked by someone keeping up with the exploits? 5%? 50%? 95%?
There's no way to give you an exact number, but let me put it this way:
If you've disable as much as you can (which by default, most stuff is disabled, so that's good), and you restart Apache after each update, your chances of being broken into are better by things like SSH brute force attacks. There's always a chance someone will get in, but when you look at the security hole history of Apache, particularly over the past few years, there have been numerous CVE's, but workarounds and they
aren't
usually earth-shattering. Very few of them have. The latest version that ships with 5.7 is as secure as they come. If it wasn't, most web sites on the Internet would be hacked by now, as most run Apache
I was asking because I had a server that did get broken into, despite having yum-updatesd running and a strong password. He said that even if you apply all latest updates automatically, there were still windows of time where an exploit in the wild could be used to break into a machine;
in
particular he said:
"For example, there was a while back ( ~march ) a kernel exploit that affected CentOS / RHEL. The patch came after 1-2 weeks of the security announcement. The initial announcement provided a simple work around
until
the new version is released."
What was the nature of the break-in, if I may ask?
I don't know how they did it, only that the hosting company had to take the server offline because they said it was sending a DOS attack to a remote host and using huge amounts of bandwidth in the process. The top priority was to get the machine back online so they reformatted it and re-connected it, so there are no longer any logs showing what might have happened. (Although of course once the server is compromised, presumably the logs can be rewritten to say anything anyway.)
Security is more than just updates and a strong password.
- Rilindo Foster
Well that's what I'm trying to determine. Is there any set of default settings that will make a server secure without requiring the admin to spend more than, say, 30 minutes per week on maintenance tasks like reading security newsletters, and applying patches? And if there isn't, are there design changes that could make it so that it was?
Because if an OS/webserver/web app combination requires more than, say, half an hour per week of "maintenance", then for the vast majority of servers and VPSs on the Internet, the "maintenance" is not going to get done. It doesn't matter what our opinion is about whose fault it is or whether admins "should" be more diligent. The maintenance won't get done and the machines will continue to get hacked. (And half an hour per week is probably a generous estimate of how much work most VPS admins would be willing to do.)
On the other hand, if the most common causes of breakins can be identified, maybe there's a way to stop those with good default settings and automated processes. For example, if exploitable web apps are a common source of breakins, maybe the standard should be to have them auto-update themselves like the operating system. (Last I checked, WordPress and similar programs could *check* if updates were available, and alert you next time you signed in, but they didn't actually patch themselves. So if you never signed in to a web app on a site that you'd forgotten about, you might never realize it needed patching.)
Bennett
On 12/28/2011 04:40 PM, Bennett Haselton wrote:
On Tue, Dec 27, 2011 at 10:17 PM, Rilindo Fosterrilindo@me.com wrote:
On Dec 27, 2011, at 11:29 PM, Bennett Haseltonbennett@peacefire.org
What was the nature of the break-in, if I may ask?
I don't know how they did it, only that the hosting company had to take the server offline because they said it was sending a DOS attack to a remote host and using huge amounts of bandwidth in the process. The top priority was to get the machine back online so they reformatted it and re-connected it, so there are no longer any logs showing what might have happened. (Although of course once the server is compromised, presumably the logs can be rewritten to say anything anyway.)
Stopping right there, it sounds like the hosting company doesn't know their stuff.
Logs should always be replicated remotely in a serious production environment, and I would say that any actual hosting company -- being a group whose profession it is to host things -- would define that category.
Yes, logs can get messed with. But everything up to the moment of exploit should be replicated remotely for later investigation, whether or not the specific, physical machine itself is wiped. The only way to get around that completely is to compromise the remote logger, and if someone is going to that much trouble, especially across custom setups and tiny spins (I don't know many people who use standard full-blown installs for remote logging machines...?) then they are good enough to have had your goose anyway.
My point is, I think server management is at least as much to blame as any specific piece of software involved here.
If that were not the case, why didn't my servers start doing the same thing?
Well that's what I'm trying to determine. Is there any set of default settings that will make a server secure without requiring the admin to spend more than, say, 30 minutes per week on maintenance tasks like reading security newsletters, and applying patches? And if there isn't, are there design changes that could make it so that it was?
Because if an OS/webserver/web app combination requires more than, say, half an hour per week of "maintenance", then for the vast majority of servers and VPSs on the Internet, the "maintenance" is not going to get done. It doesn't matter what our opinion is about whose fault it is or whether admins "should" be more diligent. The maintenance won't get done and the machines will continue to get hacked. (And half an hour per week is probably a generous estimate of how much work most VPS admins would be willing to do.)
On the other hand, if the most common causes of breakins can be identified, maybe there's a way to stop those with good default settings and automated processes. For example, if exploitable web apps are a common source of breakins, maybe the standard should be to have them auto-update themselves like the operating system. (Last I checked, WordPress and similar programs could *check* if updates were available, and alert you next time you signed in, but they didn't actually patch themselves. So if you never signed in to a web app on a site that you'd forgotten about, you might never realize it needed patching.)
You just paraphrased the entire market position of professional hosting providers, the security community, China's (correct) assumptions for funding a cracking army, the reason browser security is impossible, etc.
On 12/28/2011 01:40 AM, Bennett Haselton wrote:
On Tue, Dec 27, 2011 at 10:17 PM, Rilindo Foster rilindo@me.com wrote:
On Dec 27, 2011, at 11:29 PM, Bennett Haselton bennett@peacefire.org wrote:
On Tue, Dec 27, 2011 at 8:33 PM, Gilbert Sebenste < sebenste@weather.admin.niu.edu> wrote:
On Tue, 27 Dec 2011, Bennett Haselton wrote:
Suppose I have a CentOS 5.7 machine running the default Apache with no extra modules enabled, and with the "yum-updatesd" service running to
pull
down and install updates as soon as they become available from the repository.
So the machine can still be broken into, if there is an unpatched
exploit
released in the wild, in the window of time before a patch is released
for
that update.
Roughly what percent of the time is there such an unpatched exploit in
the
wild, so that the machine can be hacked by someone keeping up with the exploits? 5%? 50%? 95%?
There's no way to give you an exact number, but let me put it this way:
If you've disable as much as you can (which by default, most stuff is disabled, so that's good), and you restart Apache after each update, your chances of being broken into are better by things like SSH brute force attacks. There's always a chance someone will get in, but when you look at the security hole history of Apache, particularly over the past few years, there have been numerous CVE's, but workarounds and they
aren't
usually earth-shattering. Very few of them have. The latest version that ships with 5.7 is as secure as they come. If it wasn't, most web sites on the Internet would be hacked by now, as most run Apache
I was asking because I had a server that did get broken into, despite having yum-updatesd running and a strong password. He said that even if you apply all latest updates automatically, there were still windows of time where an exploit in the wild could be used to break into a machine;
in
particular he said:
"For example, there was a while back ( ~march ) a kernel exploit that affected CentOS / RHEL. The patch came after 1-2 weeks of the security announcement. The initial announcement provided a simple work around
until
the new version is released."
What was the nature of the break-in, if I may ask?
I don't know how they did it, only that the hosting company had to take the server offline because they said it was sending a DOS attack to a remote host and using huge amounts of bandwidth in the process. The top priority was to get the machine back online so they reformatted it and re-connected it, so there are no longer any logs showing what might have happened. (Although of course once the server is compromised, presumably the logs can be rewritten to say anything anyway.)
Security is more than just updates and a strong password.
- Rilindo Foster
Well that's what I'm trying to determine. Is there any set of default settings that will make a server secure without requiring the admin to spend more than, say, 30 minutes per week on maintenance tasks like reading security newsletters, and applying patches? And if there isn't, are there design changes that could make it so that it was?
Because if an OS/webserver/web app combination requires more than, say, half an hour per week of "maintenance", then for the vast majority of servers and VPSs on the Internet, the "maintenance" is not going to get done. It doesn't matter what our opinion is about whose fault it is or whether admins "should" be more diligent. The maintenance won't get done and the machines will continue to get hacked. (And half an hour per week is probably a generous estimate of how much work most VPS admins would be willing to do.)
On the other hand, if the most common causes of breakins can be identified, maybe there's a way to stop those with good default settings and automated processes. For example, if exploitable web apps are a common source of breakins, maybe the standard should be to have them auto-update themselves like the operating system. (Last I checked, WordPress and similar programs could *check* if updates were available, and alert you next time you signed in, but they didn't actually patch themselves. So if you never signed in to a web app on a site that you'd forgotten about, you might never realize it needed patching.)
System Administration is a time consuming and complicated thing. That is why there are System Administrators. That is why there are certifications like RHCT, RHCE, CISSP. There are a whole slew of things that people who want to run secure server need to know, and dozens of security related certifications:
http://issa.org/page/?p=Certifications_13
Running your own server is not like using a toaster. It requires someone with a detailed level of knowledge to install and maintain it.
On 12/28/2011 07:55 AM, Johnny Hughes wrote:
On 12/28/2011 01:40 AM, Bennett Haselton wrote:
On Tue, Dec 27, 2011 at 10:17 PM, Rilindo Foster rilindo@me.com wrote:
On Dec 27, 2011, at 11:29 PM, Bennett Haselton bennett@peacefire.org wrote:
On Tue, Dec 27, 2011 at 8:33 PM, Gilbert Sebenste < sebenste@weather.admin.niu.edu> wrote:
On Tue, 27 Dec 2011, Bennett Haselton wrote:
Suppose I have a CentOS 5.7 machine running the default Apache with no extra modules enabled, and with the "yum-updatesd" service running to
pull
down and install updates as soon as they become available from the repository.
So the machine can still be broken into, if there is an unpatched
exploit
released in the wild, in the window of time before a patch is released
for
that update.
Roughly what percent of the time is there such an unpatched exploit in
the
wild, so that the machine can be hacked by someone keeping up with the exploits? 5%? 50%? 95%?
There's no way to give you an exact number, but let me put it this way:
If you've disable as much as you can (which by default, most stuff is disabled, so that's good), and you restart Apache after each update, your chances of being broken into are better by things like SSH brute force attacks. There's always a chance someone will get in, but when you look at the security hole history of Apache, particularly over the past few years, there have been numerous CVE's, but workarounds and they
aren't
usually earth-shattering. Very few of them have. The latest version that ships with 5.7 is as secure as they come. If it wasn't, most web sites on the Internet would be hacked by now, as most run Apache
I was asking because I had a server that did get broken into, despite having yum-updatesd running and a strong password. He said that even if you apply all latest updates automatically, there were still windows of time where an exploit in the wild could be used to break into a machine;
in
particular he said:
"For example, there was a while back ( ~march ) a kernel exploit that affected CentOS / RHEL. The patch came after 1-2 weeks of the security announcement. The initial announcement provided a simple work around
until
the new version is released."
What was the nature of the break-in, if I may ask?
I don't know how they did it, only that the hosting company had to take the server offline because they said it was sending a DOS attack to a remote host and using huge amounts of bandwidth in the process. The top priority was to get the machine back online so they reformatted it and re-connected it, so there are no longer any logs showing what might have happened. (Although of course once the server is compromised, presumably the logs can be rewritten to say anything anyway.)
Security is more than just updates and a strong password.
- Rilindo Foster
Well that's what I'm trying to determine. Is there any set of default settings that will make a server secure without requiring the admin to spend more than, say, 30 minutes per week on maintenance tasks like reading security newsletters, and applying patches? And if there isn't, are there design changes that could make it so that it was?
Because if an OS/webserver/web app combination requires more than, say, half an hour per week of "maintenance", then for the vast majority of servers and VPSs on the Internet, the "maintenance" is not going to get done. It doesn't matter what our opinion is about whose fault it is or whether admins "should" be more diligent. The maintenance won't get done and the machines will continue to get hacked. (And half an hour per week is probably a generous estimate of how much work most VPS admins would be willing to do.)
On the other hand, if the most common causes of breakins can be identified, maybe there's a way to stop those with good default settings and automated processes. For example, if exploitable web apps are a common source of breakins, maybe the standard should be to have them auto-update themselves like the operating system. (Last I checked, WordPress and similar programs could *check* if updates were available, and alert you next time you signed in, but they didn't actually patch themselves. So if you never signed in to a web app on a site that you'd forgotten about, you might never realize it needed patching.)
System Administration is a time consuming and complicated thing. That is why there are System Administrators. That is why there are certifications like RHCT, RHCE, CISSP. There are a whole slew of things that people who want to run secure server need to know, and dozens of security related certifications:
http://issa.org/page/?p=Certifications_13
Running your own server is not like using a toaster. It requires someone with a detailed level of knowledge to install and maintain it.
If you are interested in research, here is the checklist that the US DOD uses to secure their Unix/Linux servers:
http://iase.disa.mil/stigs/os/unix/unix.html
Inside the STIG section, you will find a generic UNIX checklist ... there is also a RHEL 5 specific checklist here:
http://iase.disa.mil/stigs/os/unix/red_hat.html
One needs to read through that checklist and decide which of the items in the checklist are applicable to the individual situation, but that is a starting point.
Also a good source of info is this page:
Johnny Hughes wrote:
System Administration is a time consuming and complicated thing. That is why there are System Administrators. That is why there are certifications like RHCT, RHCE, CISSP. There are a whole slew of things that people who want to run secure server need to know, and dozens of security related certifications:
http://issa.org/page/?p=Certifications_13
Running your own server is not like using a toaster. It requires someone with a detailed level of knowledge to install and maintain it.
What about home servers?
It seems to me that these are bound to become more popular as more devices with IP addresses (Smart TV's and phones, etc) get linked into home systems.
I guess the person in the home running one of these is a System Administrator. Or maybe there should be a new title, Home System Administrator.
I run CentOS on a couple of small home servers (one remotely), and wouldn't claim to have any deep knowledge of the subject. I usually find the gurus on this newsgroup solve any problems I have!
On Wed, Dec 28, 2011 at 5:01 PM, Timothy Murphy gayleard@alice.it wrote:
Running your own server is not like using a toaster. It requires someone with a detailed level of knowledge to install and maintain it.
What about home servers?
Are they exposed to inbound internet traffic? If so, expect people who are smarter and more experienced than yourself to attempt to hack in, even if only with fully automated schemes.
It seems to me that these are bound to become more popular as more devices with IP addresses (Smart TV's and phones, etc) get linked into home systems.
They don't need to be directly accessible from the internet. Most would be behind a NAT router that only allows outbound access.
I guess the person in the home running one of these is a System Administrator. Or maybe there should be a new title, Home System Administrator.
I run CentOS on a couple of small home servers (one remotely), and wouldn't claim to have any deep knowledge of the subject. I usually find the gurus on this newsgroup solve any problems I have!
There are distributions targeted to the SOHO or even home environment. Look at SME server or ClearOS - that basically have the same components as CentOS but come up working with most needed services running and configurable with a simple web interface.
On Wed, 2011-12-28 at 00:40 -0700, Bennett Haselton wrote:
On Tue, Dec 27, 2011 at 10:17 PM, Rilindo Foster rilindo@me.com wrote:
What was the nature of the break-in, if I may ask?
I don't know how they did it, only that the hosting company had to take the server offline because they said it was sending a DOS attack to a remote host and using huge amounts of bandwidth in the process. The top priority was to get the machine back online so they reformatted it and re-connected it, so there are no longer any logs showing what might have happened. (Although of course once the server is compromised, presumably the logs can be rewritten to say anything anyway.)
---- the top priority was to get the machine back online?
Seems to me that you threw away the only opportunity to find out what you did wrong and to correct that so it doesn't happen again. You are left to endlessly suffer the endless possibilities and the extreme likelihood that it will happen again.
It shouldn't have taken more than 2 hours to figure out how they got in.
Next time - have them buy or ship them an external drive and have them do a dd copy of your hard drive to the external drive so you have an exact copy of the drive before you reformat/re-deploy. ----
Security is more than just updates and a strong password.
Well that's what I'm trying to determine. Is there any set of default settings that will make a server secure without requiring the admin to spend more than, say, 30 minutes per week on maintenance tasks like reading security newsletters, and applying patches? And if there isn't, are there design changes that could make it so that it was?
Because if an OS/webserver/web app combination requires more than, say, half an hour per week of "maintenance", then for the vast majority of servers and VPSs on the Internet, the "maintenance" is not going to get done. It doesn't matter what our opinion is about whose fault it is or whether admins "should" be more diligent. The maintenance won't get done and the machines will continue to get hacked. (And half an hour per week is probably a generous estimate of how much work most VPS admins would be willing to do.)
On the other hand, if the most common causes of breakins can be identified, maybe there's a way to stop those with good default settings and automated processes. For example, if exploitable web apps are a common source of breakins, maybe the standard should be to have them auto-update themselves like the operating system. (Last I checked, WordPress and similar programs could *check* if updates were available, and alert you next time you signed in, but they didn't actually patch themselves. So if you never signed in to a web app on a site that you'd forgotten about, you might never realize it needed patching.)
---- please excuse my impertinence but it seems as though you want everyone on the list to indulge in your speculation of the myriad of possibilities for your servers lack of security when you deliberately chose not to conclusively determine the problem.
As for the time needed to maintain a VPS, It sounds like you are reselling shares of co-located servers to others... good luck with that.
Craig
On 29/12/11 03:38, Craig White wrote:
On Wed, 2011-12-28 at 00:40 -0700, Bennett Haselton wrote:
On Tue, Dec 27, 2011 at 10:17 PM, Rilindo Fosterrilindo@me.com wrote:
What was the nature of the break-in, if I may ask?
I don't know how they did it, only that the hosting company had to take the server offline because they said it was sending a DOS attack to a remote host and using huge amounts of bandwidth in the process. The top priority was to get the machine back online so they reformatted it and re-connected it, so there are no longer any logs showing what might have happened. (Although of course once the server is compromised, presumably the logs can be rewritten to say anything anyway.)
the top priority was to get the machine back online?
Seems to me that you threw away the only opportunity to find out what you did wrong and to correct that so it doesn't happen again. You are left to endlessly suffer the endless possibilities and the extreme likelihood that it will happen again.
I'm with Craig on this, you need to re-evaluate your priorities.
Top priority is to ensure it doesn't happen again. In order to achieve the top priority it is important to understand what happened and how it happened. If you don't understand that how do you expect to possibly prevent it happening again.
The "problem" is that your security was flawed - that is what you need to fix. A symptom of the problem was the DoS attack. That will only ever be fixed by addressing the problem that caused it. You have confused the symptom with the problem.
A symptom of the DoS attack was excessively high bandwidth usage and that is probably why your host intervened - they probably don't care your server was hacked and they probably don't care you are DoSing someone else - all they care about is you're using too much of their bandwidth. That all sounds to me like you need to choose another more responsible hosting provider.
Last priority is getting the server back online after you have fixed the problem.
Case in point - earlier this year kernel.org had a break in. Did they a) make it top priority to get kernel.org back online as quickly as possible, or b) take the time necessary to fully investigate the incident and put in place procedures so as to prevent it happening again. I'll give you a clue - the website was off line for well over a month.
Lets consider an analogy, the regular highway vs the information superhighway. Are you allowed to run a vehicle on the highway that isn't fit for purpose? No, because it endangers others. But you expect to be able to put a server on the information superhighway that isn't fit for purpose and expect no repercussions.
If I were a large (rich) corporation and I experienced a DoS attack of the nature your server participated in I would sue you for damages, and my job would be made significantly easier if I could demonstrate wilful neglect on your part to take even the most rudimentary steps to ensure your server was fit for purpose and not a danger to others. Sooner or later someone big will sue someone little for this kind of neglect and the whole game will change. Do you have the funds to defend such an action? Until then security will continue to remain as an afterthought and/or inconvenience.
Your wilful neglect makes you complicit and puts me at risk as we both share the same Internet. Ignorance is no defence in law. Act responsibly or get off the net. You may find this harsh but next time it might be my servers on the other end of your DoS attack.
Disclaimer: my rant is aimed as much towards the thousands of others out there that would no doubt have done exactly as you did, as it is directly at you, so please don't take it as a personal attack of your actions as it is not intended as such.
On Wednesday, December 28, 2011 10:38:30 PM Craig White wrote:
the top priority was to get the machine back online?
Seems to me that you threw away the only opportunity to find out what you did wrong and to correct that so it doesn't happen again. You are left to endlessly suffer the endless possibilities and the extreme likelihood that it will happen again.
Agreed 100%. There is an old saying that applies here 'penny wise but pound foolish.'
While getting back up quickly is a definite goal, fixing the underlying issue (which can only be done when the underlying issue is known!) is a far more important issue. If downtime cannot be tolerated for a thorough investigation, then the high-availability plan needs to be adjusted to provide failover to another box/VM while the compromised box/VM is investigated.
As to the OP's original question about statistics, it seems to me that such statistics are useless for predictive analysis, and no matter how much history you have of past exploit timing this will not and cannot accurately predict the next exploit's timing or the exploitability of the next issue.
Now for risk assessment it might be useful to have some sort of metric, with the knowledge that no risk assessment is an accurate predictor of future exploitability.
On 12/30/2011 09:15 AM, Lamar Owen wrote:
On Wednesday, December 28, 2011 10:38:30 PM Craig White wrote:
the top priority was to get the machine back online?
Seems to me that you threw away the only opportunity to find out what you did wrong and to correct that so it doesn't happen again. You are left to endlessly suffer the endless possibilities and the extreme likelihood that it will happen again.
Agreed 100%. There is an old saying that applies here 'penny wise but pound foolish.'
While getting back up quickly is a definite goal, fixing the underlying issue (which can only be done when the underlying issue is known!) is a far more important issue. If downtime cannot be tolerated for a thorough investigation, then the high-availability plan needs to be adjusted to provide failover to another box/VM while the compromised box/VM is investigated.
Agree with this. At the very least, some kind of image (dd) of the original disk for further study even if you have to get the machine back on line and you don't have a failover machine.
Not knowing how or at least who (so you can block that location) got in means that if/when they want in again, they do it the same way they did last time ... unless you got lucky and happened to correct the issue in the meantime.
As to the OP's original question about statistics, it seems to me that such statistics are useless for predictive analysis, and no matter how much history you have of past exploit timing this will not and cannot accurately predict the next exploit's timing or the exploitability of the next issue.
Now for risk assessment it might be useful to have some sort of metric, with the knowledge that no risk assessment is an accurate predictor of future exploitability.
On Friday, December 30, 2011 10:24:15 AM Johnny Hughes wrote:
Agree with this. At the very least, some kind of image (dd) of the original disk for further study even if you have to get the machine back on line and you don't have a failover machine.
Speaking of dd, ddrescue in my experience is faster, but even then you will have downtime during the imaging. For a large drive this can easily take hours; I did a 500GB drive yesterday on my laptop using CentOS 6.2+the EPEL ddrescue package (LiveCD on a USB stick, by the way, with a 1GB overlay) and using a USB 3.0 Western Digital 2.5 inch external; took roughly the same time as eSATA; about 4.5 hours, even over USB 3.0 (the CentOS 6.2 Live media's kernel fully supports my USB 3.0 ExpressCard controller, by the way).
I did this because the laptop's internal hard drive is doing sector reallocations; there are 97 reallocated sectors at this point, which can be a predictor of drive failure, so it was time to image it.... (Les is likely to mention clonezilla at this point.....but my partitioning and use of unallocated space for things precludes clonezille; tried it, didn't work). CAINE or similar tool would work jsut as well; but I'd rather set up a CentOS USB stick to do it rather than yet another distribution, even though CAINE has uses beyond just imaging and should be seriously considered for forensics even for die-hard CentOS users; the Fedora-based NST is a close second in my book. Something like CAINE or NST based on CentOS would be fun..... :-)
Now, SAN snapshotting or VM snappshotting can help reduce downtime (take the snap, start imaging the snap, re-image/re-install to the underlying LUN/volume while the snap is imaging, then blow away the snap once it's imaged; requires lots of space for the snap delta files but the downtime is only the time required to take the snap (extremely quick on SAN, slightly less quick on something like vSphere) plus the time to reimage/reinstall to the underlying LUN/volume). Even here a large VM can take hours to re-image/re-install.
Better to plan ahead for failover while forensic imaging takes place.
On Tuesday, December 27, 2011 10:13:12 PM Bennett Haselton wrote:
Roughly what percent of the time is there such an unpatched exploit in the wild, so that the machine can be hacked by someone keeping up with the exploits?
While I did reply elsewhere in the thread, I want to address this specifically.
I can give you a percentage number very easily. The answer is 100%. There is always an unpatched exploit in the wild; just because it's not been found by the upstream vendor (and by extension the CentOS project) doesn't mean it's not being used in the wild. I would hazard to say the risk from an unknown, but used, exploit is far greater than the 'window of opportunity' exploits you seem to be targeting.
I would also hazard to say that it would be similar in risk to 'window of opportunity' exploit timing in the Windows world; not because the OS's are similar in terms of security but because 'window of opportunity' exploit timing is the same regardless of the general security of the OS. And I think studies of 'window of opportunity' exploits have been done and are publicly available.
I say this after having performing a risk assessment of our infrastructure myself, incidentally. It's not a matter of 'if' you will be hacked, but 'when,' and this is being acknowledged in high-level security circles.
So you plan your high-availability solution accordingly, and plan for outages due to security issues just like you'd plan for network or power outages. This is becoming standard operating procedure in many places.
On Dec 30, 2011, at 8:24 AM, Lamar Owen wrote:
On Tuesday, December 27, 2011 10:13:12 PM Bennett Haselton wrote:
Roughly what percent of the time is there such an unpatched exploit in the wild, so that the machine can be hacked by someone keeping up with the exploits?
While I did reply elsewhere in the thread, I want to address this specifically.
I can give you a percentage number very easily. The answer is 100%. There is always an unpatched exploit in the wild; just because it's not been found by the upstream vendor (and by extension the CentOS project) doesn't mean it's not being used in the wild. I would hazard to say the risk from an unknown, but used, exploit is far greater than the 'window of opportunity' exploits you seem to be targeting.
I would also hazard to say that it would be similar in risk to 'window of opportunity' exploit timing in the Windows world; not because the OS's are similar in terms of security but because 'window of opportunity' exploit timing is the same regardless of the general security of the OS. And I think studies of 'window of opportunity' exploits have been done and are publicly available.
I say this after having performing a risk assessment of our infrastructure myself, incidentally. It's not a matter of 'if' you will be hacked, but 'when,' and this is being acknowledged in high-level security circles.
So you plan your high-availability solution accordingly, and plan for outages due to security issues just like you'd plan for network or power outages. This is becoming standard operating procedure in many places.
---- to reiterate my thoughts... I still don't understand the logic of the list indulging the OP's rampant speculation of various causes when his first action was to eliminate all possibility to find out what actually happened.
An apt analogy is to find out that your horses have been stolen so you burn down the barn where they were kept, drag the ground to remove all evidence of footprints & tire tracks and then decide that you want to figure out how the thieves got in and made away with your horses.
Craig
On 12/30/2011 05:47 PM, Craig White wrote:
to reiterate my thoughts... I still don't understand the logic of the list indulging the OP's rampant speculation of various causes when his first action was to eliminate all possibility to find out what actually happened.
An apt analogy is to find out that your horses have been stolen so you burn down the barn where they were kept, drag the ground to remove all evidence of footprints& tire tracks and then decide that you want to figure out how the thieves got in and made away with your horses.
Craig
Because it is not only OP that is interested in this type of info. There are many small-time admins (like me) that can greatly benefit from the knowledge of the people doing this as part of their regular job. OP was just the aperitif, already mostly forgotten :D
-
Alex Milojkovic -
Bennett Haselton -
Cliff Pratt -
Craig White -
Craig White -
Drew -
Eero Volotinen -
Gilbert Sebenste -
John R Pierce -
Johnny Hughes -
Joseph L. Casale -
Karanbir Singh -
Ken godee -
Lamar Owen -
Leonard den Ottolander -
Les Mikesell -
Ljubomir Ljubojevic -
m.roth＠5-cent.us -
Marc Deop -
Marko Vojinovic -
Nataraj -
Ned Slider -
Peter Eckel -
Reindl Harald -
Rilindo Foster -
Stephen Harris -
Timothy Murphy -
夜神 岩男