No offense, but I hope your passwords on the Red Hat weren't as easy as the one on the Mac. Personally, I am seriously thinking of retiring my current ones. I have used them far too long.

re: changing passwords
I agree. I recently moved my main user files (which was an admin) to a new user account without admin privelages and put a massive password (well, 11 characters) on my admin account. The admin password is never used to log in remotely (I have my router's firewall blocking ssh from outside anyway) so anyone finding my user name/pwd will only be able to muck with my files, not the system (and not with other users on the machine).

also, I have root disabled (and will never enable it) so an attacker would have to guess my only admin user name....

oh and one more thing - the default admin user is the first account set up on OSX, and the short user name is built from their full name (Joe Bloggs = jbloggs). The 'Computer Name' as set in the sharing pref pane is by default "Joe Blogg's Computer". I reccomend changing that, cos otherwise people will be able to work out the short user name of your admin account on any OSX box just by browsing through the network.

My Red Hat password was actually a lot more substantial like:

a%foreu&she

Although what hoops posted shows 'no record' of failed password attempts, I would tentatively agree with you. An attacker can use 'traffic-analysis' techniques to interactive ssh connections to gather enough information about someone's terminal sessions to locate typed passwords in the session data stream and reduce by half the time needed to guess the password (the techniques involved are not specific to ssh but apply to most interactive remote-terminal protocols) and these sorts of 'information leaks' are very difficult to prevent.

.

There is something going on here guys. I find it really strange that two unix boxes with presumably good passwords were cracked. SSH may not have been the vector in, but it was used once the password was known. The first attack on the Mac seems to indicate the sort of blind password-guessing done by an automated process. Once a way in was found, the human at the other end took over a minute to notice and get in, right? Unless this was some sort of decoy to cover the real attack, then this password was just 'guessed'? Pretty damned lucky, huh? Of course, by starting with the Windoze box, which I think we all would agree makes more sense as the first vector in, the cracker would then be in a better position to capture network traffic and attack your passwords in some other-than-brute manner.

Too bad there is no forensic from the Red Hat attack. It makes me wonder how to set up a system for moving logs to a read-only media. I would love to have them on a CD, burning a session a night or something. Anyone else have some good ideas/experience with protecting logs?

Direct them to another source via /etc/syslog.conf. You can then harden that source as much as you like. Disallow all outside connections other then sysloging.


*.debug @foo.domain.org

So let's say I root your box. First thing I am going to do is read all the logs and check cron tasks. I will find this connection to your outside source. What's to stop me from following it and blowing away the files there? Once I am root, I mean. I still like the idea of read-only media...

There's nothing stopping you. Once a box is owned, well, it's owned.

But this isn't controlled by cron and it wouldn't appear in the local logs. Every log entry at level debug or higher automatically is sent and logged on the remote source in "real time" (limited by network latency). The only way it would be found was if you looked at syslog.conf, or checked outbound connections with netstat, or open files with lsof -i. By the time you did all that and put a stop to it, I'd still have all the logs up to that point on a "secure" remote source. Naturally your network speed is a possible limitation here where syslog entries can get munged because they can appear on the remote server incomplete, but it's more data then you would have had locally.

Centralized logging, in addition to local logging, is good UNIX admin practice.

Ultimately, IMO, this is more effective then (assuming it was possible) streaming to a read-only source. Burning would have to be automated and would be caught if someone looked at the crontab. The cache used to create the burn would probably be found as well and removed. Etc, etc. You'd be in the same boat as what you detailed above. The only advantage I can see in streaming to read-only media is that it would be unexpected, so it wouldn't necessarily be caught right away.

streaming to a read-only source.... how about something as simple as an email to a web-based gmail account? no passwords to the email account would be stored on the box itself, so the messages would be irretrievable to the root-ed hacker.

the log files might have to be zipped up and encrypted prior to transmission, of course...

I think the centralized logging idea is a good one, and if I had more than two computers, I would probably head that way. :-)

Do you think breaking into your centralized logger is going to be more difficult for someone capable of what we have seen? I don't pretend to be that good yet, but I know that Buddha himself isn't going to be able to remove the logs I manage to save to a CD.

I am looking at the options that hdiutil gives for automating this idea. Looks promising. The more I think about it, the more I like the idea of incrementally writing to a read-only media in general. I think I could come up with all kinds of uses for this.

As far as an Email, that's a good idea too. I don't know how to include attachments from the command line yet. :-)

It is if there's it's firewalls to disallow any external connections with the exception of syslog traffic from specified machines. At most, a hacker could fill my logs with useless crap from a r00ted box.

Are you a key target? What sort of business are you in? Those are more problems than I'd expect any average small business to run into.

Really, you should consider the VPN idea.

I don't recall seeing any mention in this thread of not allowing passwords at all....

I do not allow ssh logins with passwords, I can only login with a key and a pass phrase.

I also limit my ssh connections from IP addresses I know.

Stetner,

Is this kind of like what you are talking about? I followed the instructions up to the part about the "ssh-agent". I don't mind typing in a password to access my key.

If you have any more good resources, could you post them for us? Thanks!

While stetner is on call...
When you said "I also limit my ssh connections from IP addresses I know." did you mean using the 'only_from' option in '/etc/xinetd.conf' ?

If so, did you have to set up some things before using it? Some difficulty with using the 'only_from' option in /etc/xinetd.conf is mentioned in this thread. According to that thread, there is a bug that prevents this from working correctly without making another change in /etc/xinetd.d/ssh . I'm not sure it is a bug, but perhaps the protocol IPv6 must be set up.

Yes, that is what I was talking about. That seems like a pretty good resource for setting up keys, don't know of any that are better than that one....

Occasionally when I am doing stuff that will require me to connect a number of times, like working on some source that is stored in SVN which I access over ssh, I will fire up ssh-agent and use it, but I tend not to use ssh-agent all the time as I don't mind typing in a pass phrase either.

Yes, I am using only_from in xinetd. I have not had a problem, but I have disabled IPv6 on my system and my xinet.d/ssh file looks like this:so in my case I am allowing access from ranges of IPs due to the way proxies work, I am not guaranteed to get a specific IP, but I know it will be in a certain range. Less secure than a single IP, but more secure than open slather.