Daley Ponderings

Im right there with you...getting creamed today...changing my ssh port

The attackers seem to have gotten tired - or maybe just slowed down their attempts to try to work around detection. I know see attempts every 10-15 minutes, instead of every 30 seconds.

From the denyhost graphs (hourly), I see that last night was a bigger night than usual, though not as much as a week ago. I also see that qatar.cmu.edu is listed by 16 different hosts, so someone over there must have gotten hacked.

If you are willing to use iptables (netfilter), you could have a rule such as:

iptables -A INPUT -p tcp --dport 22 -m recent --set --name ssh --rsource

iptables -A INPUT -p tcp --dport 22 -m recent ! --rcheck --seconds 60 --hitcount 4 --name ssh --rsource -j ACCEPT

For every 4 bad attempts, it locks out that IP for 60 seconds...

Yeah, I haven't ever gotten around to figuring the iptables stuff out - it allows sounds so scary. I am running pam-shield, which effectively does the same thing, but I am still in testing mode on that, so it only runs on the pop/imap server port for now. The biggest problem with that is that it has a database that it uses for keeping track of how many attempts there have been, and the timestamps, etc. and it appears to have problems writing to the database if there are too many requests - can't get the lock to write it or something. I filed a bug report, so waiting to see what the authors say.

But thanks for the rules - I'll probably take a look at that method at some point. I do like denyhosts (better than the basic iptables or pam-shield) that knows more about the protocol, and knows whether the usernames were valid, unknown, restricted or root, and can make different lockout rules for each - that helps prevent my customers from getting locked out too quickly, but I can lockout the hackers really quickly when they are guessing usernames.

It is interesting to me that there was a spike like that - maybe for 8 hours, and then today we are back to normal - just a couple attempts per hour or so.

I consider myself as having an above average education with netfilter, but I, like you said, get freaked out each time I make a rule. I actually close my eyes, cross my toes and fingers, hoping my 1,000 mile away dedicated servers are still alive.

I should mention that netfilter can log to syslog, so depending on the log server you are using, you could direct them into a MySQL DB. This is my method, and I use syslog-ng for this, and all other server systems I have running.

To be extra cautious, you could make yourself an SSH private key and pass phrase. That way, the only way to login is if you physically have the key on your HD, keydrive, etc and know the key's password / phrase. Doing this and putting it on a non standard port, along with an IP that is NOT FQDN I have found cuts back on the attacks considerably.

Hope this helps...

Yeah, I can't do that since I have customers that need access. I have wondered about protecting my own account (and encouraging customers) to not use passwords. I'd have to still use passwords for email and usermin, etc. I only turn on FTP and SSH access on a customer by customer basis - and try to never turn on both for any given customer.

How about enabling customers to generate a list of one-time passwords? For example, if I'm going on a trip I'd like to be able to log in using a password from the list, and then cross it out because it will not work again; next login use the next password. If necessary you can generate more while logged in. That protects against keyloggers on insecure terminals, but not man-in-the-middle attacks.

Also, it is possible to use a key (no password) for IMAP connections? I'd rather not have to store my password in plaintext on every machine on which I use an e-mail client. (I know I could just ssh and use pine, but that's inconvenient.)

I did read about one solution for one-time passwords for PAM, it might not be that hard to setup. Though I don't think it supported a list of multiple one-time passwords - I think you'd have to generate one each time you logged in.

Does your email client store the password in plain text? That sounds like a bad idea.

There is a PAM solution that allows you to have a different password for each service. You have a text file in your home directory that lists the passwords. Also, most of my customers already have that, because their procmail filtering isn't as fancy as yours, and so the email is completely unrelated to their ssh account (if they have one). ie. most users don't have an entry in the /etc/passwd file.

Although, I did add procmail entries for the virtual users recently, so I might re-look at switching your account again. I don't currently have a way for virtual folks to be able to edit their filtering yet.

Outlook may not store the password in plain text, but it's clearly recoverable, which is equivalent. If I lost control of my work machine I'd need to change my password rather than just canceling a key. I guess that's not a big deal, though.

Having only a single one-time password is too risky, because you might lose your connection before generating another. Also, assume the connection is being watched at the client end, so the snoop would get the next password. That's why you need a list.

Carrying a key on a USB stick might be a good alternative. I suppose a bugged machine could steal that too, though it seems much less likely.

How does someone snoop your creating the password for the next login? It is created over an ssh connection, right? I agree about failing to create the next password, though presumably that would be a small chance of not being able to run the generator program right away after connecting.

I wouldn't think changing my ssh password is that difficult - I don't think I have it stored anywhere. I actually don't use it most of the time, but just use the key, so sometimes I forget what the password actually is, particularly on the lesser used machines.

How about long complex; upper / lower case characters, numbers, and any other special characters?

I don't want to give out too much info, but my users have to live with over 160 bit passwords - well over 20 key sequences of /dev/urandom data. This, I am hoping somewhat forces them to keep their passwords in -one- central location, making it harder to go to cafe to cafe and casually logging in.

I believe their is a SASL mechanism for IMAP, using no passwords. Check into Cyrus-SASL.

Ick. And your customers live with that? The ssh passwords are enforced only by "John the ripper" to be "complex". I have been meaning to get pam to help out with the enforcing, but haven't gotten around to that yet.

I am using sasl for smtp and imap authentication, but using a postgresql library to do the actual authentication - I'll check to see if there is anything easy that I can do for keys.

In my experience, if the passwords are too hard to remember, they get written down on paper, or stuck onto their monitors with post-it notes, so I don't want to go too far with it.

I do use a password generator to generate reasonably complex initial passwords, and lots of people don't change them, so they have decent passwords to start with, at least.

I do one on one consultation with my clients, all the way up to setting up their e-mail client. My clients are screened, as I offer non standard internet services (or alternative forms of standard services).

I do not recall the last time I had to e-mail or spell out the password to a client - as to the close relationship with their services and administration needs.

Good old John... I compile that every so often for fun, make some hashes - wowsers, remembering the first time I used it, and now with current technology, this application is now amazing and a blast!

How do you get them their passwords or keys? Are you onsite for everything?

I go on-site for most of their needs. I try to actively maintain the client's preference in software for any such service, and keep an active working configuration, with in-person updates to them.

Their are many choices out their: 1000 user shared hosting for seven bucks a month, or a 100 users who are willing to pay more than the share of 1000X7 for someone to actively train, develop, and communicate for complicated services, and then for one simple service, such as SMTP, in person and in their comfortable environment.

If for example someone from out of my location would want a service, simple passwords are not a problem - with quotas, and other provisions to ensure their is not interaction with other end users or other remote servers.

I should point out, I will never grant shell access. Virtual private servers, virtual machines, I would consider, though I have never had a request for this.