Exactly right. My personal paranoia is directed toward the grey hats
surrounding me. So I optimize my habits to thwart them. Joe Mafia
trying to get to me from botnets-r-us worries me much less and is,
imo, much easier to deal with.
_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug
With botnets the pam_unix 2 second delay is meaningless. That's two seconds per IP and depending on the size of the botnet it could be longer than 2 seconds before the same IP attacks due to not wanting to DOS your system. Even banning IPs after wrong passwords is useless, as I was never seeing the same IP attempt to attack within 5 minutes or more.
They have near limitless IPs. They have near limitless computing power. They also get bored very, very quickly. The key is to appear uninteresting. Public key auth does that.
Cheers,
Steven Black
Quick, someone hand me a screwdriver! ;-)
> Ultimately we're talking risk mitigation. There is no way to remove all
> risks and have a usable system.
Amen.
> Cheers,
> Steven Black
Cheers,
Simón
_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug
Hey! I said "short password" not a bad password. ;)
For me, "short" is 12 to 24 characters, no embedded words, no 1337 substitutions, upper and lower case, includes at least one number and punctuation. Yeah, it can be brute-forced, but it isn't low-hanging fruit. More than that a casual aquantance can't learn I like "yams" and know the key to my password. ("Hey, he turned 34, let's try 'yams77'... Bingo!")
Now "long" is 240 characters or more. I have had one of those before, but they just feel so slow to type I am loathe to go that big.
I usually aim for 70 to 90 characters. Comfortably fast to type, and still long enough to thwart all but the most determined.
Yeah, there's the whole sneak-in-and-copy-key thing. It is suitably low risk for the reasons Mark mentioned.
If you really want to protect a PC you need a boot-time password and to power it off whenever it will leave your sight. This is what I do with my laptop when at conventions.
Ultimately we're talking risk mitigation. There is no way to remove all risks and have a usable system.
Cheers,
Steven Black
> Here is a summary to give you an idea of how large of numbers we are
> talking about:
>
> simple 5 character password combinations (a-z)
> 26^5 = 11881376 (0.01 seconds)
>
> full alphanumeric 5 character password (a-zA-Z0-9):
> 62^5 = 916132832 (0.9 seconds)
>
> complex alphanumeric 5 character password (above + all symbols)
> 94^5 = 7339040224 (7.3 seconds)
>
> 3 word passphrase drawing from 2000 word vocabulary
> 2000^3 = 8000000000 (8 seconds)
>
> simple 8 character password combinations (a-z)
> 26^8 = 208827064576 (208 seconds)
>
> 4 word passphrase drawing from 2000 word vocabulary
> 2000^4 = 16000000000000 (4.4 hours)
>
> full alphanumeric 8 character password (a-zA-Z0-9):
> 62^8 = 218340105584896 (2.5 days)
>
> complex alphanumeric 8 character password (above + all symbols)
> 94^8 = 6095689385410816 (70 days)
>
> 5 word passphrase drawing from 2000 word vocabulary
> 2000^5 = 32000000000000000 (1 year, 5 days)
>
> 5 word passphrase drawing from 5000 word vocabulary
> 5000^5 = 3125000000000000000 (99 years)
>
> The time shown in parens is the maximum time that it would take for a
> system capable of encrypting 1 billion passwords per second would take.
> Apparently, home desktop systems with high end GPUs have been built that
> can do this.
>
> Lesson learned from all this? Sentence based passphrases are much much
> stronger. The downside is that they are easier to accidently say in your
> sleep.
>
The time needed to generate the encrypted keys is only important if you
already have the encrypted key and you want to reverse the password.
For scanning SSH hosts that isn't important. What is important is the
number of combinations for the password character set and the amount of
time that each wrong answer takes. If the SSH server (and basically
anything that uses pam_unix.so) waits 2 seconds after each wrong
attempt, the amount of time needed to guess the correct password becomes
huge.
For the worst case example above [a-z]{5} it would take 275 days to try
every combination. The [A-Za-z0-9]{5} one takes 58.1 years. The
shortest reasonable set/size (all symbols, 6 characters) would take 1801
years
How many threads would an attacker have to use to make it worth it?
The biggest problem is social engineering, not password complexity. Too
many people share or write down their passwords. Or they use really
obviously bad passwords (the account name, 1234, "password", etc). The
bots hitting the ssh servers, at least from what I've seen, aren't doing
a brute force attack: they're trying to pick up low hanging fruit where
passwords of well known accounts were chosen stupidly.
Brian
_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug
And to remember if overheard. :-)
--
Mark Warner
_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug
It depends on what type of passphrase you are using. You might think
that a passphrase could be cracked easier, but it turns out that a
sentence is a lot harder to crack than an 8 character password.
I give an example like this on my SSH tutorial here:
http://support.suso.com/supki/SSH_Tutorial_for_Linux#Generating_a_key
An 8 character password that uses a set of characters made from upper
and lowercase, numbers and symbols has 94^8 or 6,095,689,385,410,816
combinations.
Now if you use a 5 word sentence for a passphrase, you are probably
pulling from a vocabulary of 5000 or so words. "For instance this
measly sentence" could be such a passphrase. The number of combinations
rises to 5000^5 or 3,125,000,000,000,000,000, which is 512 times more
combinations than an 8 character password. And you're probably more
likely to remember the passphrase.
If an attacker had to try to crack the passphrase they could either do
it based on combinations of letters, which on a 33 letter sentence would
be about 28^33 combinations. If the attacker had to try combinations of
words in a dictionary, they are probably going ot have to use a
dictionary larger than your vocabulary, so maybe 50,000 words. This
would be 50000^5 to try. Of course, they don't know how many words, so
they may start with 3 words, then 4, then 5, etc.
Here is a summary to give you an idea of how large of numbers we are
talking about:
simple 5 character password combinations (a-z)
26^5 = 11881376 (0.01 seconds)
full alphanumeric 5 character password (a-zA-Z0-9):
62^5 = 916132832 (0.9 seconds)
complex alphanumeric 5 character password (above + all symbols)
94^5 = 7339040224 (7.3 seconds)
3 word passphrase drawing from 2000 word vocabulary
2000^3 = 8000000000 (8 seconds)
simple 8 character password combinations (a-z)
26^8 = 208827064576 (208 seconds)
4 word passphrase drawing from 2000 word vocabulary
2000^4 = 16000000000000 (4.4 hours)
full alphanumeric 8 character password (a-zA-Z0-9):
62^8 = 218340105584896 (2.5 days)
complex alphanumeric 8 character password (above + all symbols)
94^8 = 6095689385410816 (70 days)
5 word passphrase drawing from 2000 word vocabulary
2000^5 = 32000000000000000 (1 year, 5 days)
5 word passphrase drawing from 5000 word vocabulary
5000^5 = 3125000000000000000 (99 years)
The time shown in parens is the maximum time that it would take for a
system capable of encrypting 1 billion passwords per second would take.
Apparently, home desktop systems with high end GPUs have been built that
can do this.
Lesson learned from all this? Sentence based passphrases are much much
stronger. The downside is that they are easier to accidently say in your
sleep.
> I agree that the script kiddie login attempts are annoying. But they
> are not likely to succeed if you use password best practices. And if
> you are really worried about them, and cannot lock down the ssh port
> to known remote hosts, using a port knocker of some sort is an easy
> way to only open the port when needed.
>
> As someone else said, 2 factor auth (something you have plus something
> you know) is still the best thing to do, but if you don't do that, and
> need to open ssh to the public, local password is my preference over
> keys.
>
> -Tom
>
>
> [1] Using the stroll to the kitchen example again, if you forget to
> lock your screen, and someone gets to the machine before the 2 minute
> auto kick in of auto screen locker, they can easily open a terminal
> and run a curl command to upload the public key[2] from your machine.
>
> [2] If you are using security by obscurity, while in the daemon rc
> file to change the port number, you should also change the default
> location of the public key file.
> _______________________________________________
> BLUG mailing list
> BLUG@linuxfan.com
> http://mailman.cs.indiana.edu/mailman/listinfo/blug
>
--
Mark Krenz
Bloomington Linux Users Group
http://www.bloomingtonlinux.org/
Sent from Mutt using Linux
_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug
Heh. This touches on the other part of my paranoia with PKI; the
short passphrase. Imagine that your passphrase encrypted key gets
loose in the wild.[1] At that point, you can brute force the file
without anyone knowing you are doing it. No matter how many thousands
of bits the key itself is, if the passphrase is simple or small
enough, there is a possibility of it being decrypted. Whereas, if you
are doing the password checking during the login process, if a failure
happens, it is logged and you have a chance of seeing the attack
before to many guesses of the password can be made.
I agree that the script kiddie login attempts are annoying. But they
are not likely to succeed if you use password best practices. And if
you are really worried about them, and cannot lock down the ssh port
to known remote hosts, using a port knocker of some sort is an easy
way to only open the port when needed.
As someone else said, 2 factor auth (something you have plus something
you know) is still the best thing to do, but if you don't do that, and
need to open ssh to the public, local password is my preference over
keys.
-Tom
[1] Using the stroll to the kitchen example again, if you forget to
lock your screen, and someone gets to the machine before the 2 minute
auto kick in of auto screen locker, they can easily open a terminal
and run a curl command to upload the public key[2] from your machine.
[2] If you are using security by obscurity, while in the daemon rc
file to change the port number, you should also change the default
location of the public key file.
_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug
Anyways, hashlimit has worked quite well. The problem that I was
running into was that the worm that was running around trying every
first name as a username was hitting my servers so hard that it opened
up enough connections to prevent normal users from logging in. So I
turned on hashlimit in the firewall and that stopped the problem. I
also decided at that point that I would move my servers that don't need
ssh access by customers to a custom port. I found one suitable by
searching a years worth of firewall logs and found one that hadn't ever
been hit by port scanners. There are actually several ports like this
so don't ask me which one I use. This is an exercise left to the reader.
;-)
So you can see, there are other issues besides just "if they get the
right username and password", they can practically DOS your system.
Back in 2005 I think I was getting somewhere around 60,000 login
attempts per day.
On Wed, Jul 20, 2011 at 08:51:55PM GMT, Williams, Jeffery Allen [jefjewil@indiana.edu] said the following:
> A while back (3 or more years) there was a discussion about ssh brute force attacks. (I think Mark sent something related to SUSO getting hammered.) Since then, I have limited the number of connection attempts per source IP to 4 / minute using hashlimit in iptables. I have other lines that limit service connections to a few per second from any source (ntp for instance). I also have a few things where I reject the first few connection attempts and after that all attempts are dropped until things quiet down.
>
> I also have notes in my firewall script about portsentry. But I don't know if that's still a thing.
>
> Finally, my router is a piece of crap. If too many connection attempts happen at once it just locks up until it's power cycled. This further prevents brute force attacks (but is more than a little annoying).
>
> Jeffery Williams
> Software Engineer
> ISAT Hall
> 867-5309
> _______________________________________________
> BLUG mailing list
> BLUG@linuxfan.com
> http://mailman.cs.indiana.edu/mailman/listinfo/blug
>
--
Mark Krenz
Bloomington Linux Users Group
http://www.bloomingtonlinux.org/
Sent from Mutt using Linux
_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug
Not knowing what you do and putting the kids issue aside. Let me
easy your worries a bit here with some logic. Yes, your coworkers
probably could gain access to your systems faster, but in most places
this would be crossing the line and grounds for immediate termination.
At least if I was in your shoes and someone did this, I would make sure
that they got fired, damn anyone who tries to say "You shouldn't have
left your screen unlocked".
This is not to say that you shouldn't lock your screen as you should
do that even at home, but what I'm trying to show here is that your
likelyhood of threats is more based on fear than ease of access.
A malicious hacker in Romania basically has nothing to fear because
they know that we won't be able to do anything about it (historically)
if they hack your system. But people that you know have a lot to fear,
losing their job, being arrested, etc. You have to remember that people
are still people with basic motivations to have their life be ok.
Also, if there was someone on my team that I couldn't trust, it would
be better to know about it sooner and have them just hack into my home
server before they do something worse or before you trust them with more
information and access.
I think the biggest time that you have to worry about coworkers is
when they are fired, but hopefully they are out of the building before
they can do anything and likely would try to remote in somehow and
probably wouldn't care about your home computer.
--
Mark Krenz
Bloomington Linux Users Group
http://www.bloomingtonlinux.org/
Sent from Mutt using Linux
_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug
