Slashdot Mirror

From what I can tell, John runs a dictionary-based attack against your master.passwd file, then runs the dictionary with various shifts in capitalization, then runs the dictionary again with an assortment of numeric digits inserted into its guesses.

Finally John just runs a brute-force attack, generating passwords with successively longer and longer lengths until it lucks out.

In my case John finally did luck out, finding one of my passwords after 18 days of crunching numbers. This particular account had a relatively weak password -- though no dictionary attack would have found it, it was still only five bytes long. That's a wakeup call for me. I've been using shorter passwords for years, thinking that by avoiding common words I was safe. But I can see that they're breakable now.

It's one thing for someone to preach that you should really have longer passwords; it's quite another to see it for yourself. If your passwords are easy to guess, or are variants of dictionary words, or can be generated easily by brute force -- there are widely available tools that can give the keys to the city to any lowlife that wants into your machine.

Run one of the password crackers on your own system today, and become enlightened! And don't be comforted by the 18 days it took to crack my easy five-character password on a 300MHz Celeron notebook: there's also a distributed version of John the Ripper that divides up the work of cracking your password file among many computers.

The more I learn about security, and the tighter I make my systems, the more afraid I am. If you aren't afraid, you are either very very good at what you do -- and I humbly bow before you -- or you haven't much of a clue.

...in those attacks, like they have in the numerous Microsoft leaks. Imagine the strife we'd be in if they stole the source to Debian!

But seriously, how shall I put this? ChkRootKit, TripWire, AIDE, FICC, ProSum, Toby, msec, Nessus, LSAT, Saint, LIDS and of course if you want totally proactive, try SELinux, Medusa DS9 or OpenWall. That's hardly an exhaustive list, but it does hit many of the highlights. Boy, youse bin livin in a monoculture too damn long!

Would it not be easier to deny the ability to use a non-alpha+numperic password?

I think pam_cracklib can do that, plus it automatically runs a quick dictionary attack before storing the chosen password. There's also pam_passwdqc, but I've never used it.

You mean like John the Ripper?

Keep in mind that patching all linux installs is a "very good idea", but you can get away with only patching the kernel on machines that customers may have access to, such as web servers. You should patch any server that allows someone to upload and execute code RIGHT NOW. Also apply the openwall.com patch RIGHT NOW. It helps by potentially nullifying new vulnerabilities. And it also has a long list of other security features that are important on a machine where code is locally executable (again, web servers with CGI, PHP, etc. come to mind instantly).

I hope this helps.

-reid

I highly doubt that Linux authors would think twice about breaking buggy apps to force the issue.

Actually, Solar Designer's non-executable stack patches have been consistently refused for inclusion in the official Linux kernel, for at least six years now, even though every sysadmin I know uses them on any Linux machine put out on the Internet. (Making the stack non-executable eliminates the threat from many buffer overrun problems, for example.) Most all of his other patches have made their way to the kernel quickly (his security hardening patch is now a fraction of the size it used to be, because most of it has been moved into the official kernel over the years).

One reason given repeatedly for not including a non-executable stack in the stock kernel was because things like GCC's trampolines, used in nested functions (something hardly any programs use, as it's not standard C), don't necessarily work when the stack is non-executable without special considerations. And those special considerations can't catch 100% of the cases, and those programs crash unless they are redesigned. Which is, of course, exactly the opposite of what you suggested.

(There is also the "false-sense-of-security" argument: the patch has not been included because it gives admins a false sense of security. I find this weak. In a nonperfect system, every additional bit of security helps. Having passwords on systems also give us a false sense of security, when there are other ways for hackers to break in. But we still put passwords on our machines.)

Actually, only the Itanium and AMD K8 are affected by this immediately; Microsoft isn't yet marking memory nonexcutable by default on the good old x86 processors that we all use.

Regardless, it is trivial for developers to update their code for things like JIT compilers, with a simple function like this:

void MakeMemoryExecutable ( void* buffer, int lengthInBytes )
{
DWORD op;
VirtualProtect(buffer, lengthInBytes, PAGE_EXECUTE_READWRITE, &op);
}

I added that piece of code to my company's JIT compiler some years ago, just to ensure that the proper flags were set. I figured Microsoft would eventually switch to nonexecutable data and stack segments, much like the OpenWall project has done with their Linux patches. Glad to see Microsoft is finally taking the first steps.

Sure, but at least some of these patches work on x86. From the Openwall kernel patch FAQ:

Q: Is the patch x86-specific?
A: Only the non-executable stack feature of the patch is x86-specific

And he's forgotten Openwall Linux too. It is not the prettiest LiveCD, but it allows you to do most things in order to recover from disasters. And to install Owl ofcourse ;)

That sounds a little like what Openwall Linux (OWL) does. Your shadow file turns into a tree of files, and each user owns their own piece of it. Access to the tree happens with sgid shadow if I remember correctly. The point is that things like passwd and chfn are no longer suid root.

I think they managed to get the whole system working without suid root binaries, and that's without things like capabilities. It sounds pretty good to me.

Yes lets look at some of the innovations:

1. WinFS
Hmm, another layer on top of a file system to slow it down. MS's filesystem is already slow as a dog, How useful. We already know that that MS is 2.5 times slower as a file server then Linux with Samba 3ReiserFS 4, which is in final testing NOW beats the pants of any offering from MS in features and speed. ReiserFS 4 is sponsored by DARPA (Defense Advanced Research Projects Agency) and is architected for military grade security, ReiserFS. There is also a Gnome project that I believe is using GnomeVFS to have a similar function of a database on top of the file system for searching, etc. Ulike the offering from MS, you will be able to REMOVE it if you don't want it and it will probably be ready in a year. I don't remember the name or link for the project off the top of my head.

2. SVG.
Gnome has had SVG themes for a while now with an SVG engine in beta that will literally be out YEARS before anything from MS. The SVG engine draws all the widgets in GTK+ as SVG.
Some SVG themes
Even more SVG candy

3. .Net managed code.
Holy slowness batman! All this to have some bounds checking to prevent buffer overflows? This is already out for Linux Non-executable user stack

4. DRM
Yes, just what all the users want. Someone telling them what they can and cannot do with thier OS and what files they can and cannot run. Thanks MS for putting your customers before the big media compnanies.

We had about 15 assorted raq, raq2's, and raq3's that were serving email, web, and some ftp sites. Since sun appeared to have no intention of putting out patches for the various vulnerabilities in both ssh and the httpd services on the boxes, we had to look at other options. Getting one of the newer cobalts wasn't appealling since a company that does this once, is just going to do it again, when they decide they don't want to support the newest.

We ended up converting all our mail off onto an Imail setup (though I think we are going to ditch that since we already have to buffer incoming and outgoing mail with frontend postfix boxes; might as well start going all out open source, but we had to do something quickly and Imail was a quick fix for us). Ie, we pretty much went with custom solutions on a mix of beefier open source boxes and M$ based systems. The hard part was doing it without the customers knowing (which pretty much involved a small cluster of stage 1 built gentoo boxes all john the rippering passwords for us).


Now, all that is minorly interesting (maybe using john to help with a smooth transition), but this gem on getting Redhat installed on a cobalt is just *asking* to be tried out on some of the spares I've got laying about.


But, our take on the whole thing was, 'better to upgrade to our own systems and sell the appliances for 100-200 a pop on ebay'.

Specifically, lwn.net/Distributions/index.php3#secure and possibly also the special purpose distros (mini, floppy, cd, whatever).

Engarde, Immunix, and Openwall are all designed to be secure platforms for server or firewall development.

If you want something small, you might look at LEAF or Coyote or Wolverine. Coyote is free, Wolverine is $30-$120 depending on which license you need.

Personally, I'm using Astaro (free for personal use). It seems to be well designed from a security perspective (everything is chrooted, etc.), but it is not easy to customize the web interface, etc. A 'pluspack' is downloadable which includes gcc, etc, or you can compile on RedHat if you have the right versions of all the libraries.

Great news but will it make any difference? Linux is seen as a "cheap" alternative to Microsoft in the West, but when you can purchase virtually ANY piece of software for 2$ at any corner store, why would people want to switch/learn about Linux? Those who want already do know what Linux is.

By the way, how come no one has ever discussed OwL Linux here -- a security-enhanced operating system made in Russia. It is worth a mention.

Maybe this will help.

Yeah, the password list can be handy sometimes ...

I've just spent the last 21 months as network person at Moor Park High School in Preston, Lancs. I implemented two Linux servers which did internal www which staff could access parts of via their W:\ drive, mail, proxy (with authentication and ability to block kids by a gui), ability to reclone damaged NT/2000 workstations, quota limits for kids, staff and pupil shared areas (accessible via S:\ and T:\ drives), shell access for kids, remote KDE/GNOME desktops in a window for staff (not that they used them!)...

The whole thing cost them £400 in software. Unfortunately two weeks ago they still insisted on me spending 7 hours a week standing in a library doing duties telling kids to take their coats off... and all for less than six pounds fifty an hour (probably 9-10 USD per hour). They're now looking for three people to replace me. I've now gone self employed and am the cheapest IT person I know even at more than twice the rate they paid me.

The biggest difficulty I found with implementing Linux was getting it to understand our existing username/password database. You have several options, some of them being:

- Make everyone set a new password (bad idea - they'll want to know why)
- Use pwdump.c (available from Samba mirrors) to create an smbpasswd file from your existing NT or 2000 server.
- Use John the Ripper or L0phtcrack to crack your existing account database. This isn't such a great solution, as some passwords could take weeks to crack, and some passwords will get changed after you cracked them.
- Use Winbind, which is part of the Samba suite which will talk to your existing NT/2000 setup and make those user accounts appear as ordinary users. This is an absolutely great solution once it works; you can give them access to any service you want (it works through PAM, so it's as good as having them all in /etc/passwd in many ways) - such as ftp, ssh, local or XDMCP access, you can chown and chmod files and directories to them, and it just works. It can be, however, an absolute nightmare to set up, and so I've written a document on the subject and how to get past a number of random error messages here.
- Read the comments in smb.conf

Management are always a problem, and it's the usual scenario: if it's Free, it has to be crap. If this is a problem, then instead of telling them how good it is, just show them. It's not difficult to find a spare unused machine in a school, or to boot Knoppix onto something, and you only need something with 16 or 32MB to install Debian or an old version of RH onto it and make it a useful server - machines of that calibre of write offs in UK schools right now with all the money the UK government are pumping into them. (This quarter alone, we had £27,000 to spend on IT - something like $40,000.)

Set something up, and implement a feature that your network lacks - quotas, web, email, cloning (use Partition Image - a much nicer replacement to Norton Ghost), proxy server (use Squid and Webmin so that your boss can easily add users to a list of banned people). Consider writing a cronjob to automatically copy everyone's home directory once a day, and then suddenly you'll be able to restore someones work from backup from any particular day or week (depending on how much hard disk space you have - a couple of cheap maxtor 80GB disks or something similar will do the job) in the space of ninety seconds *every time*. No more messing with backup tapes. (But still do tape backups, because you don't know when a lightning strike/minor earth tremor is going to destroy every hard disk...)

Write a manual. "This is how our Linux boxes were set up. The IP is this, here are the open ports, these packages were compiled from sourc

What about stackguard? Why isn't it in use everywhere? Or libsafe for that matter? Or Openwall Project kernel patch for Linux? Can anyone please tell me why no one uses it?

why doesn't this happen with Linux ? (or does it happen with Linux?)

Like other posters said, this does happen with Linux, but not as much. There are reasons why.

Many good Open Source projects will usually separate their releases into to branches: stable and experimental. For example, in the Linux kernel, if the second number is even (x.2.x or x.4.x), then it is a "stable" release. If the second number is odd (x.3.x or x.5.x), then it is an experimental release.

Most of the time new features are only put in the experimental release. There are features officially classified as experimental in the stable release, but you can only use them (or even see them) if you check the "prompt for development or incomplete drivers" option. There have been mishaps where a feature was added in the middle of a stable release and caused problems. One such example is the changes to the virtual memory system in about 2.4.4.

Another reason this doesn't happen as often is many of the serious open source programmers do everything they can to prevent/fix bugs and are paranoid about security. Microsoft doesn't seem to care. When I run win98, there are always system crashes, settings being changed when I don't want them to, unstable programs (which are supposedly being made by professional companies) making other programs/the whole system unstable.

In Linux, these problems are virtually nonexistant. I haven't seen many programs which will bring Linux down, and most of those don't crash the kernel. A buggy SVGAlib[1] program will either screw up the video or screw up the keyboard and disable virtual console switching[2]. XFree86 doesn't have this problem. Most buggy programs in X don't seem to affect it at all--there are problems such as X crashing with huge font sizes, but the main system was running fine. I just had to restart X. A misconfigured X may screw up the display, but most of the time I can use Ctrl-Alt-Backspace to kill X, display restores, and I fix the problem. Also, when Ctrl-Alt-Delete still works, it will properly shutdown the system--unlike Windows.

Linux/open source has problems, but Microsoft has many more. In my twenty some years of using computers, I haven't seen anyone produce crappy software as Microsoft--except for script kiddies and the low end of shareware programmers.

I've always wondered why using fixes, new functions, patches, whatever, written by numerous different people hasn't turned Linux or other open source into a non-functioning morass of code

They do have project leaders and others who verify the patches. Open source projects don't accept just any old patch--there is a process of reviewing and testing submitted patches. This also varies from project to project. Some maintainters will just slap in anything, but the maintainers of very good and stable projects will try to understand what the patch is doing before even testing it out. It is a very long and arduous process to get a patch for a new feature into something like the Linux kernel. There are plenty of such patches floating around. For example, Openwall Linux is a kernel patch that adds security features. From what it sounds, it may never get into the official kernel...

Isn't an operating system more complicated (or at least more fundamental) than an application?

An OS is the most fundamental part of the software. Any bug in the OS will often cause major problems everywhere. As to an OS being more complicated, it depends on the system and what you choose to define as the OS. Some people consider only the kernel/core part as the OS, and others include "essential" libraries--the definition of essential can vary greatly. Still some others include basic utility programs part of the OS.

Why doesn't (or how often) does fixing one bug in Linux create two new ones?

Any change in a project can cause a new bug, but as I said, they review and test the patches, so this doesn't happen as much as you seem to think it would. The problem with Microsoft bug fixes is they don't seem to test their changes very well, and they often bundle new (and possibly unwanted) features/modifications with these fixes. These features/ mods may have bugs or cause other problems. The high-end open source projects shy away from this practice. That is why they have a different branch marked experimental (or unstable)-- people who want to test (or use) the bleeding edge features can do so without affecting the stable branch.

Footnotes:

[1] SVGAlib is a library which allows a program to draw graphics on the screen with a virtual console. This library is dangerous because it requires the program to run as root (often suid root, which means any user will have root access with the program until the program drops privileges). The framebuffer is slightly safer because it is a kernel driver and you don't have to run it as root. Both of these can easily leave the video card in a messed up state if the program doesn't use them properly.

[2] The virtual console is a part of the Linux kernel which handles the video display. In Linux there are multiple of these virtual consoles, and one can switch between them freely using the Alt key plus the arrows/function keys. Alt+F1 will switch to virtual console # 1. Alt+2 #2, and so on. A problem arises if a program sets raw keyboard mode (such as many SVGAlib/framebuffer programs do) as this disables the kernel from recognizing an Alt+function key as a request to change consoles.

There is a kernel level patch so that nothing can be executed in the stack, but a lot of people don't seem to want it. Actually, I think there are two competing patches. One of them is called Openwall.

There are also libraries to combat this sort of problem as well. Such as the one another poster listed...

I didn't realize there were so many programs still using stuff like self modifying code and code on the stack. I thought that was old school stuff.

As for trampolines, the kernel patch I found has a work around to emulate them. It also allows you to set a flag in the executable so that if they need exec on the stack, you can configure it.

The patch is a part of the Openwall Project. That patch also has some other apparently useful security features. Too bad it lags the kernel development in a big way...

Owl is something that I admire and would even run if it wasn't based around RPM. They've managed to create a system that could probably be run without any suid programs.

Even chfn and passwd work, since they have split /etc/shadow into a tree, and each user has its own fragment that is only writable by that user. There's a bit of glibc/nsswitch magic to use that tree instead of the usual flat file, and the rest of the system just works as before.

There are other "duh, why didn't I think of that" changes, too. Think about it - why do syslogd and klogd keep root after starting? klogd needs to open a socket from the kernel. After that, does it need root? Nope. syslogd needs to be able to open logs and sometimes bind to a privileged port. Guess what, a user called 'syslogd' can open log files owned by syslogd, and it can drop root after it grabs that port. Owl also chroots klogd into a jail to keep it out of trouble once it starts.

I look forward to seeing this kind of cluefulness in other distributions, since it's obviously correct.

Try the Openwall kernel patches too. They make the stack non-executable, preventing a whole class of buffer overrun attacks. The general page has more info, too.

Try the Openwall kernel patches too. They make the stack non-executable, preventing a whole class of buffer overrun attacks. The general page has more info, too.

I bet you John the Ripper would crack your password in a matter of hours. They've built rules into it to do those letter to number conversions.

Made by the man himself, Solar Designer (whom the article calls SolarWall).

http://www.openwall.com/Owl/

As someone in the Information Security field, I am constantly working to improve the security of Linux machines.

One of the low points of Linux administration is that very few daemons are chroot'd, and the few that are, dont have much protection because of the Linux kernel's very weak chroot protection.

Projects like OpenWall, GRSecurity, and SELinux (from the NSA), all attempt different solutions to this problem.

Of course, they are all incompatible with each other, but the problem remains that the Linux kernel, as shipped by RedHat is insecure when it comes to chroot protection.

Will this ever change, does RedHat care, and if so, which of these projects do you personally feel is most appropriate to lead the way in the future?

I made a wallet-sized PDP-11 (see photo) using these tools.

I put the simh PDP-11 emulator and unix_v7_rl.dsk along with the following script onto a CF card formatted as a DOS FAT partition.

set cpu 18b
set rl0 RL02
att rl0 unix_v7_rl.dsk
boot rl0
#boot
#rl(0,0)rl2unix

You have to type those last two lines manually to the PDP-11's boot prompt.

I'm ready to roll with a PDP-11 in my wallet (or, if you include the $9.95 CF-USB (Linux driver) card, in my Penguin Mints container, which matches the black and yellow 48MB Lexar card I got on sale at Fry's for $19.95).

Total cost for a PDP-11 running Unix: $29.90, mints not included.

BTW, the default V7 "root" password is "root" (I ran John the Ripper and it took 0.00002 seconds).

They've already had their DARPA contracts, and what have they contributed? No-exec patches for Linux. That's about it.

They need to be actively involved in the security community; not just post a message when they get funding. I think we'd see much greater success.

• 114 moderator-approved posts to securityfocus.com mailing lists.
• 48 publications and citations to our work on the USENIX site.
• I served on the USENIX Security 1999 program committee.
• I was the publicity chair for the New Security Paradigms Workshop for three years.
• My first post to the Linux Security Audit Project in 1998.

Crispin
----
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc.
Immunix: Security Hardened Linux Distribution
Available for purchase

mmh... you wont tell the root password? but you give out image where there is the DES-kinda hash of the password in it?

root:WZ1XNLQ0U7XFE:0:0:root:/root:/bin/bash

looks like it's fake, though, since it's all caps, but couldn't know, didn't look at it so much. and uuh, what are those ip addresses there, in 216.27.xx.xx network?

makes me think the name "jailbait" is actually a hint! it's a bait, he's trying to make evil wannabe-hax0rs crack that password with something like jtr, and then logging in his system as "root"!

the password isn't crackable with my 250M theargon wordlist, and doesn't seem to be too short one either (yea, ofcourse i gave it a run). however, if that password is important to you, dude, change it now. it wont take many weeks till someone has it cracked even as it's somewhat strong. the DES derived hash is not good for passwords

According to openwall, the non-exec stack and other security patches so useful in 2.0.x and 2.2.x are finally on the way to 2.4.x, giving you that extra bit of protection. Of course, it looks like it will have its own beta period, but those patches protected my 2.0.x box for quite a while from 0-day exploits, and let it manage a full year of uptime at one point despite dozens of users and a bunch of services (including the ever-dangerous wu-ftpd).

The interkey timing applies ONLY AFTER the initial login. The cracker would have to have to somehow know you were exceuting something that involved entering a password, then capture the packets with your keystrokes.

It should be noted that, despite their simplicity, traffic analysis attacks such as those presented in this advisory haven't been well researched. We expect that similar attacks are possible against most other "secure" (encrypted) remote login protocols. We also expect additional traffic analysis attacks on SSH to be discovered. In particular, there may be recognizable patterns in X11 connections forwarded over SSH, but these are out of the scope of this advisory.

So in other words, the strategies they describe here for attacking SSH could be equally effective for most any asynchronous network protocol where you could try to infer information from the rhythm of the rate of data transfer. Further, there is ultimately no general solution, only incremental defenses against the general strategy:

Solving traffic analysis vulnerabilities not related to password information would increase the protocol overhead significantly, and thus doesn't seem practical for many current uses of SSH.

So, as is often the case, if you want perfect security you can only have it at the expense of tremendous overhead, and ultimately you have to decide how far you want to take your defense against chaos theory before deciding that you just have to accept a certain degree of risk. Ultimately, there is no defense and you always have to accept that risk.

That's not entirely true, as Solar Designer and Duc Song stated with their article about SSH traffic analysis.
They state that a man in the middle attack does work, even for SSH2.

But, alas, that's my $0.02

-- Sighm

There is more to Microsoft Windows than it's ability to have a richly integrated cut -n- paste functionality. Besides that advance came back in '91 with Windows 3.1.

That advance certainly didn't come in 1991, because the Amiga's clipboard.device already could do that earlier (at the latest, 1990 when 2.0 was released, and probably much earlier in the 1.x days of the 1980s but I'm not 100% sure). And this sort of thing wasn't really what the Amiga was famous for, so (I am speculating) that idea may have been stolen from the Mac.

I'd actually like to see someone name one part which is ahead of Microsoft. Just one.

Linux has faster filesystems. But Linux and NT both still suck at that, so I guess I should mention something more substantial:

An area where Linux is way ahead of Windows would be extensibility.

For example, Linux and Windows, when running on x86, both have a severe problem where code can be executed on the stack. If you run a network service and it has a buffer overflow bug, then bad people on the Internet can write their own code and execute it on your machine. So some guys decided it wasn't such a good idea for that to be possible, and they released some kernel patches to make it so that this infiltration technique doesn't work.

This actually reveals two ways that Linux is further ahead than Windows.

1. The first is that this vulnerability is (partially) closed under Linux now, whereas Windows users are still sitting ducks.
2. The second (and much more important) is that it was possible for a third party to make the fix. There is no way (and will never be a way) to install a kernel patch and "make bzImage" under Windows. That means that if Microsoft themselves never bother to fix a problem, then it will never get fixed. Whereas with Linux, if Linus and his pals don't bother to fix something, the Linux user still has options.
   
   That doesn't put Linux just a few years ahead of Windows. It puts Linux a whole generation ahead of Windows, and even my beloved (but no longer maintained) AmigaOS. Freeness itself is a huge feature. (Alas, it's about all that Linux really has. But it's a biggie!)

I think you probably mean John the Ripper

• Operating System: Although OpenBSD is generally regarded as the best Freenix in terms of security, GNU/Linux is under more active development, faster, more user friendly and supports far more software packages and types of hardware than OpenBSD (sorry Theo, much respect...). I, along with most of the other admins and users are more familiar with a GNU environment. The distribution we use is Debian. I chose Debian for several reasons: free (libre and gratis), strong package system and reliability. It hasn't let me down. I do prefer Slackware on my personal box, since the -current tree is more stable than Debian's unstable. However, Debian's package system is nicer and provides many things that Slackware lacks (I may abandon Slackware as soon as Debian supports XF4 and kernel 2.4 by default in stable). Debian also keeps up to date on security issues.
• Kernel: We now run a Linux 2.4 kernel. Although most security tools/patches are 2.2 only, the mature (READ: usable) ones have been ported to kernel 2.4. I'm confident that more will follow. 2.2 is dead. We have disabled modules entirely in our kernel to prevent hax0ring and to avoid using modules (does anyone else hate them?). We only have a few drivers enabled. Besides helping performance, this protects against hostile code injection into the kernel. It is possible for a clever coder to inject code into a non-modular kernel, but most rootkits use kernel modules. Not allowing kernel modules and using 2.4, prevents us from using some really cool security tools like LOMAC. However, I found that LOMAC did not play nicely with OpenWall's Secure Linux patch (or cron, or init or getty ...). When Lomac behaves nicer, it will be added (I'd also like to see it as a patch rather than a module). Currently, we are using the GetRewted.net patch which provides lots of security enhancements. We may be adding more secure kernel additions such as the NSA's Security Enhanced Linux. However, at this time, we feel that the current kernel security model is both secure and usable. If you have any neat kernel goodies we might like, tell us.
• Firewall: Note that we are NOT running any sort of real firewall. We feel that the extra kernel overhead of the firewall hurts performance and adds needless complexity to the server. Since we are NOT trusting local (ie: users with shell access) anyway, we feel that a firewall is basically useless since Linux's TCP/IP stack is already fault-tolerant, mature and robust. We augmented the TCP/IP stack with this shell script to limit our vulnerability to DoS attacks. Firewalling services should not be needed if your services are secure (run with minimal priviliges and SECURE by design and condiguration). Eventually we may drop an OpenBSD or Linux 2.4 firewall in front of the server as a measure for restricting local users ability to portscan, DoS and exploit remote hosts.
• Authentication / Login: Remote interactive sessions are only supported over ssh (and we run OpenSSH). Telnet is not allowed. Rhosts authentication is not allowed. I've looked at forcing people to use S/Keys, but it is a real pain in the ass on both ends. We are currently allowing FTP in. When I'm confident that all the users can get a good graphical scp/sftp client for their platform, I'll kill FTP. Since I'm not relying on trusting local users anyway, this is more a security concern for individual users. I'm considering locking some users who don't use their shells out of real shell access.
• Users: I only make accounts for people I know personally. I also monitor user login s and their activity using whowatch and process accounting. I'm suspicious of logins from weird hosts. I also use PAM to set resource limits.
• Monitoring: We watch out for network nastiness with Snort which is an AWESOME IDS. We monitor its logs and other system activity with Psionic's LogCheck. Occasionally, I'll audit the machines for weird ports using nmap and Nessus, both of which are REALLY nice. I'll also routinely verify system integrity using a combination of Tripwire and chkrootkit, on a system booted from a known CLEAN floppy containing the tools.

• Operating System: Although OpenBSD is generally regarded as the best Freenix in terms of security, GNU/Linux is under more active development, faster, more user friendly and supports far more software packages and types of hardware than OpenBSD (sorry Theo, much respect...). I, along with most of the other admins and users are more familiar with a GNU environment. The distribution we use is Debian. I chose Debian for several reasons: free (libre and gratis), strong package system and reliability. It hasn't let me down. I do prefer Slackware on my personal box, since the -current tree is more stable than Debian's unstable. However, Debian's package system is nicer and provides many things that Slackware lacks (I may abandon Slackware as soon as Debian supports XF4 and kernel 2.4 by default in stable). Debian also keeps up to date on security issues.
• Kernel: We now run a Linux 2.4 kernel. Although most security tools/patches are 2.2 only, the mature (READ: usable) ones have been ported to kernel 2.4. I'm confident that more will follow. 2.2 is dead. We have disabled modules entirely in our kernel to prevent hax0ring and to avoid using modules (does anyone else hate them?). We only have a few drivers enabled. Besides helping performance, this protects against hostile code injection into the kernel. It is possible for a clever coder to inject code into a non-modular kernel, but most rootkits use kernel modules. Not allowing kernel modules and using 2.4, prevents us from using some really cool security tools like LOMAC. However, I found that LOMAC did not play nicely with OpenWall's Secure Linux patch (or cron, or init or getty ...). When Lomac behaves nicer, it will be added (I'd also like to see it as a patch rather than a module). Currently, we are using the GetRewted.net patch which provides lots of security enhancements. We may be adding more secure kernel additions such as the NSA's Security Enhanced Linux. However, at this time, we feel that the current kernel security model is both secure and usable. If you have any neat kernel goodies we might like, tell us.
• Firewall: Note that we are NOT running any sort of real firewall. We feel that the extra kernel overhead of the firewall hurts performance and adds needless complexity to the server. Since we are NOT trusting local (ie: users with shell access) anyway, we feel that a firewall is basically useless since Linux's TCP/IP stack is already fault-tolerant, mature and robust. We augmented the TCP/IP stack with this shell script to limit our vulnerability to DoS attacks. Firewalling services should not be needed if your services are secure (run with minimal priviliges and SECURE by design and condiguration). Eventually we may drop an OpenBSD or Linux 2.4 firewall in front of the server as a measure for restricting local users ability to portscan, DoS and exploit remote hosts.
• Authentication / Login: Remote interactive sessions are only supported over ssh (and we run OpenSSH). Telnet is not allowed. Rhosts authentication is not allowed. I've looked at forcing people to use S/Keys, but it is a real pain in the ass on both ends. We are currently allowing FTP in. When I'm confident that all the users can get a good graphical scp/sftp client for their platform, I'll kill FTP. Since I'm not relying on trusting local users anyway, this is more a security concern for individual users. I'm considering locking some users who don't use their shells out of real shell access.
• Users: I only make accounts for people I know personally. I also monitor user login s and their activity using whowatch and process accounting. I'm suspicious of logins from weird hosts. I also use PAM to set resource limits.
• Monitoring: We watch out for network nastiness with Snort which is an AWESOME IDS. We monitor its logs and other system activity with Psionic's LogCheck. Occasionally, I'll audit the machines for weird ports using nmap and Nessus, both of which are REALLY nice. I'll also routinely verify system integrity using a combination of Tripwire and chkrootkit, on a system booted from a known CLEAN floppy containing the tools.

• Alan Cox's Patches - Nice!
• Real Time Scheduler - Aside from making Linux a RTOS, it improves app performance!
• GetRewted - Similar to the Openwall pacthes for 2.2.X - NonExec stack, improved filesystem security, stealth networking, Trusted Path Execution

I encountered quite bit of instability (say hello to my friend kernel panic!) running this on 2.2.19 with the openwall patches installed. I don't know who is being naughty, but I'd guess LOMAC since Solar Designer has a reputation for being a wonderful coder. OH... and it fucked up my system so getty thought it was still booting and only root could login. Promising though... when these issues are fixed I'll definately run it on my server. Good work. I'd like to see this (and ACLs) ported to OpenBSD also... I'm thinking about making an "ideal" armored server for fun next year and these would be cool features.

I encountered quite bit of instability (say hello to my friend kernel panic!) running this on 2.2.19 with the openwall patches installed. I don't know who is being naughty, but I'd guess LOMAC since Solar Designer has a reputation for being a wonderful coder. OH... and it fucked up my system so getty thought it was still booting and only root could login. Promising though... when these issues are fixed I'll definately run it on my server. Good work. I'd like to see this (and ACLs) ported to OpenBSD also... I'm thinking about making an "ideal" armored server for fun next year and these would be cool features.

• Make the stack non-executable: Yes, this works, and security-conscious people will use Solar Designer's Kernel Patch to do that. It works great.
• Make the data segment non-executable: This works a whole lot less well. Too many UNIX programs depend on being able to execute code in the data segment. This is UNIX's fault, not Intel's fault.
• Use the MMU For Enforcement: Ancient Burroguhs mainframes (the 6500 IIRC) actually stored each array in a separate segment. They also ran like a dog compared to modern RISC(y) architectures. We tried the MMU approach for StackGuard in 1997, and it imposed an 8000% overhead to do it that way. Read about it in this paper.

Crispin
-----
Immunix: Free Hardened Linux
Chief Scientist, WireX

this isn't research, it's a gross hack. solar designer's work is much better.

www.openwall.com

Secure-Linux is a Linux kernel patch that adds nifty security features, which eliminates many, if not most, buffer overflow attacks. I tested this with one of the ProFTPd exploits, and indeed, the exploit failed against a known vulnerable version of ProFTPd. Without the patch, the exploit worked.

Psionic PortSentry detects and responds to port scans in real time. It works with other Unixes as well.

With these tools, the standard ipchains stuff, and a willingness to not run *every* daemon under the sun, you can have a reasonably secure Linux box.

Also, to throw those k1dd13z for an extra loop, put all this on linuxppc. Let 'em chew on that for a while...

New XFMail home page

/bin/tcsh: Try it; you'll like it.

What exactly does ``unstable'' mean? Or, more accurately, what does ``stable'' mean? The 2.2.13 and 2.2.14 kernels (supposedly ``stable'') have rather nasty inode leaks. And 2.2.11 and 2.2.12 had a memory leak (which is why SGI based their SGI Linux 1.1 kernel patch on 2.2.10). Hmm... Looks like stability ``leaves somewhat do be desired''.

Featurefulness perhaps? Well, one patch I find extremely useful is the ext3 filesystem. (Now that seems stable enough, despite the frightening version number: 0.0.2c) But Stephen Tweedie hasn't finished porting that to 2.3.x. Another useful patch is the international crypto patch, and that doesn't come for 2.3.x... Or the Openwall security patch: ditto. Hmm... Looks like I'll stick to 2.2.x for some time. (And, no, it isn't exactly ``warm and cozy''.)

I'd like to try the 2.3.x kernels by using User mode Linux, but so far the only thing I've got from that is a core dump.

Sigh...

1. He is under attack from script kiddies and thinks he might be more secure with OpenBSD, or
2. He is getting tired of all the people asking him why he didn't choose OpenBSD