Rogue remote root logins

On Friday 04 August 2006 07:42, composlinuxmisc stood up and spoke the following words to the mbuttes incomp.os.linux.misc...:

From what you're describing below, I'd say that this is indeed what has happened... :-

First rule of thumb, do not allow remote root logins - and if workable for you, not even local root logins. I personally also make sure the root pbuttword is longer than 8 characters.

As I'm not using SuSE and am therefore not monitoring their security-related package status reports, I cannot answer that question, but technically, itwouldbe possible, yes.

There are however others ways crackers can try to log in. First of all,rootis a login account that exists on most UNIX systems, and this is what crackers are all too aware of.

The attacks we ourselves have experienced in the past involved a so-calledbrute-forcepbuttword cracker. It spits out randomly generated pbuttwords and login attempts at a rate of several attempts per second, and they can let the damn thing go on for hours, if not days in a row.

The best way to arm yourself against that is to (1) deny root access overssh,-ftpor whatever other service you've got running on the machine, and (2) set up PAM orsshdto disallow logins for a specified amount of time - usually, that's just a few seconds - after a specified amount of incorrect login attempts.

This is possible, yes.

It is possible that your machine may already have a rootkit installed by now, or that the cracker has set you - i.e. the root user - up in a chroot'ed jail, which he himself can circumvent via a secret command or key sequence. That's what rootkits could theoretically do. They exist so as to hide the fact that your box is already 0wn3d by someone else.

Not normally, no. Besides, if you actuallykillthesshdrather than simply shutting it down, it should respawn automatically in most set-ups. This is taken care of by the same tool - calledsshd-restarter- that automatically stops and restartssshdafter a certain amount of time, so as to prevent open connections from lasting.

Possibly, yes. This is where the rootkits come in.

This is possible, but statistically less probable, I would say.

I'm afraid that this applies to most companies and their IT departments or system administrators.

I'm not exactly an expert, but I'm sure that would be a good idea. Also monitor thebashcommand history for the root user.

Many people recommend key authentication over pbuttword authentication, but I have some serious considerations with that. First of all, the machine holding the authentication key would have to be a trusted machine, which means that you can't log in from whatever machine connected to the Internet you have at your disposal at that given time.

Secondly, if such a machine is a multi-user machine, this technique buttumes that you can trust all users of that machine.

Just a little modest advice with regard to security:

(1) Make sure the system runs up-to-date versions of all packages, especially the security-related ones. This doesn't necessarily mean you have to update everything. Some security hazards only apply for local users or for users with physical access to the machine, et al. Use common sense in this regard.

(2) Disallow root logins overssh. Usesftpinstead offtp,and if you must use regularftp,have it run in achrootjail and don't have it running 24-7.

(3) Install a rootkit checker and and intrusion monitoring system. Various such programs exist. Monitor your logs.

(4) Set up process accounting, so that you know who did what and when.

(5) Use hard-to-guess pbuttwords, preferably lengthy ones.

(6) Distribute your filesystem hierarchy across different parbreastions, several of which you keep mounted read-only during normal system operation. It won't stop a cracker, but it'll slow him down, and a filesystem remount in read-write mode will show up in the logs, which gives you an extra clue.

(7) Use quota and pbuttword expiration if the machine is located anywhere other than at your home.

(8) Make use of Access Control Lists (ACL) to finetune the permissions on filesystems that are in any way shared - which basically includes all the filesystems in the machine since normal operation requires read access to most of the files, but which focuses more on home directories and shared files under *-var* or *-srv.* Keeping an eye on *-tmp* in the same manner can be useful as well, as *-tmp* is often used to circumvent quota on home directories.

(9) If you're running a 32-bit distribution on a Pentium Pro or later - includingx86-64- then make sure you're using a kernel which supports up to 64 GB of physical memory, as those are configured to run in the CPU'sPAEmode - i.e. Physical Address Extention.

The above seems totally irrelevant at first sight, but if the CPU runs inPAEmode, the Linux kernel can implement a softwareNXbit onx86-32,which is the only modern microprocessor that doesn't have anNXbit in hardware yet.

Also please note in this respect thatx86-64CPU's do have a hardwareNXimplementation, but that they can only use that if they are actually running in native 64-bit mode. Running a 32-bit OS on such a CPU would require a software implementation ofNX,and thus the 32-bit kernel should run the CPU inPAEmode.

Like I said, I'm not the expert, but I hope all of the above was useful to you somehow... ;-)

-- With kind regards,

*Aragorn* (Registered GNU-Linux user #223157)