Slashdot Mirror

One word: Bastille.

November 2000 Interview of the project leaders on /.

Bastille-Linux homepage. I believe it now installs on non-virgin Redhat and Mandrake systems, and 6.2 is definitely included in the list. All of the other links are great for learning to do it yourself, but in the meantime, you can lock down your box quite nicely with Bastille.

I have used it for a year or so, and highly recommend it.

Here

Given the wording at the above mentioned place in their FAQ, it is highly unlikely that they'll ever do their own distro.

See the news from tripwire's new site TripWire.org which has the skinny from Tripwire directly. LinuxPower has an article. As does IGN over here.

T here is also a great article here regarding file system monitoring - and alternatives (additional OpenSource) to TripWire. Not quite as relevant now that TripWire is OpenSource but still a good read.

Here. It is supposed to harden your Linux system. I haven't tried it though. I downloaded it, but before I got around to running it, I installed FreeBSD.

just a couple of points about the files you listed. Keep in mind that this is for my home machines where I am the only user. I remove the suid bits from mount and umount, because I am the only one that should need to mount drives anyway. If I start giving out accounts on my home system, this is something I won't have to worry about then, as it's already been taken care of. I don't use at, so I disable it, if an exploit does happen to come out, I don't have to worry about patching it right away, but it's still a good idea to do so. The same thing goes for gpm, I don't use it when I'm in console mode, so when that exploit came out a couple of weeks ago, it wasn't a major concern.

The Bastille hardening script for RedHat based systems has the option to remove suid bits from ping and traceroute. It doesn't break them, you just have to be root to use them. There are debates about whether or not regular users should have access to tools such as ping and traceroute anyway, and it's likely I won't be the one to end the debate, but I prefer on my own machine to limit it to root. After all, I am root, and if I give out an account to a friend, he can just as easily run ping from his own machine. if you want to give permissions to some people and not others, sudo is extremely easy to install and configure and works great for limiting su access to specific users for specific applications.

Once again, a lot of this was learned from experience, I spent time using the system and learned what I need and what I don't need, and now I know what comes enabled and how to disable it shortly after install, before connecting to the Internet. This doesn't mean every vendor should ship their systems to my specs, after all, I'm a nobody and really have no say over what vendors put in their OS.

One thing I don't agree with is some of the default behaviors of certain parts of the OS. For example, a friend of mine got cracked with one of the latest wu-ftpd exploits. The attacker added a user with uid 0 and removed /etc/securetty. I don't know if you know what this does, but the default behavior is that if securetty doesn't exist, rather than restricting a root login (especially a remote one), it compalins that it can't find the file and then lets the user login anyway. For this, I would prefer the default behavior to be something more along the lines of "if /etc/securetty doesn't exist, don't let someone with uid 0 login anywhere." Even if the administrator accidently removes securetty, if they were security conscious, they would have created a non-root user, and nothing would stop them from logging in as an unpriviledged user and su'ing to root to fix the securetty file. Of course, the whole incident stemmed from him running an insecure ftpd that he didn't even need.

I don't know how many other examples there are of insecurity like this, I mean it's probably something someone just over-looked. I'm not a kernel developer, I'm trying my best not to throw stones, as I realize the kernel hackers and OS people are lightyears ahead of what I can do, but as a user, it's those kinds of things that worry me. disabling services is something I can do, re-writing the kernel or the os, I'm not quite to that level yet...

First and foremost every linux distribution caters, or atleast claims to cater to a specific subsection of the linux population. If you want the most recognized linux distribution, with the one of the bigest installed bases out there you run RedHat. If you want a distribution that is as tight as a drum you apply Bastille Linux. If you want productivity suties cleanly integrated into your install process you run Corel Linux (which BTW is based on Debian.) If you feel like supporting User Friendly you run Suse. If you want a distribution that you know all the parts work well together in you run Debian.

The author of this article seems to lack an understanding of the Debian release cycle. Debian was frozen before several of the release he mentions came out. Once Debian has been frozen getting a new package into it becomes substanially more difficult. Now before everyone screams about how now that potato (Debian 2.2) is stable these fixes can't make it in, keep in mind that security fixes are one of the items on the very short list of packages that can be changed once a release goes stable.

Joe Homeuser most likely isn't going to choose Debian as his distribution. Most people who choose Debian do so because the support Open Source ideals to the extreme and as such have problem been around the Open Source block a time or two and atleast have some idea what they are doing.

Are these valid secutiry holes in potato? Yes! Should someone have written an article bringing them to light? Yes! Is this a big enough deal to warrant a Slashdot Story? No! It should be a quickie at best.

I dont know what version of RedHat you used but 6.2. has the option to just install, Kde OR Gnome or try a server install, you are not forced to install both.

If you want just the basics get one of the "Linux on a floppy" distributions, and add stuff form there. compiling your own kernel as shown on "Linux from scratch" would be overkill for what you seem to want.

"Seek and thou shalt find", if you had made an effort to search then you might have seen this:
Trustix
http://www.icewalk.com/softlib/app/app_01091.html
or Bastille linux

kha0s
www.kha0s.org

Distributors are listening, but they should not underestimate the importance of marketing and gaining mindshare (case in point is the success of micro$oft).

--
"Rumours of my death have been greatly exaggerated"
http://www.mozilla.org

The Bastille Hardening System attempts to "harden" or "tighten" the Linux operating system. It currently supports Red Hat and Mandrake systems. We attempt to provide the most secure, yet usable, system possible

As for security, I'm a big fan of portsentry and logsentry. And although I have never used Bastille Linux I've heard many good things about it.

But it is a whole lot easier to lock down and secure a firewall, than worry about what software on your desktop might expose you. You'll be glad you did.

It's just a matter of time. Meanwhile, you damn well better hope that your OS is secure.

If you're using Linux, you should check out Bastille Linux. If you're a BSD fan, I recommend you look at OpenBSD, although hopefully FreeBSD will catch up soon thanks to the FreeBSD Audit Project.
--
Brad Knowles

We're working on just this at Boston University. Our original plan, as reflected on the BU Linux web site was to base our distro on Bastille Linux -- that was back when Bastille was in super-early development and was planned as an actual distribution. They've gone the route of a hardening script, something we'd like to avoid. (We'd like all of our changes to be to RPMs, rather than pasted on afterward, for better system upgradability and managability.)

So, we're starting work on a distro of our own, integrating ideas from Bastille with Red Hat, and adding things we need like Kerberos IV, AFS (Arla, probably), Amanda, etc. If this sounds like what you're doing, please contact me at mattdm@bu.edu . It seems worthwhile to at least share ideas, even if we don't end up combining our work.

--

see the Linux Weekly News' Security page for information on Linux security projects which are already under way:
Secure Linux Projects Bastille Linux
Khaos Linux Secure Linux
Security List Archives
Bugtraq Archive
Firewall Wizards Archive
ISN Archive

Distribution-specific links
Caldera Advisories
Debian Alerts
Red Hat Errata
SuSE Announcements

Miscellaneous Resources
CERT
CIAC
Comp Sec News Daily
Crypto-GRAM
Linux Security Audit Project
OpenSEC
Security Focus
SecurityPortal

There are two other secure linux projects, Bastille Linux ( www.bastille-linux.org), and an as yet unnamed "Secure Linux" ( http://www.reseau.nl/securelinux, you can vote for a name there). They've both been in progress for quite some time.