Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
Linux Software

Answers About Bastille Linux From Jon & Jay 66

Posted by timothy
from the say-"bas-TEE" dept.
You asked, they answer. Jon Lasser and Jay Beale decided to kick their answers back and forth a few times in the style of Crossfire -- at least if Crossfire guests were security-obsessed, literate hackers with a knack for finding gaps in Linux and Unix security. And don't forget the book creds: Jon wrote the excellent Think Unix (want to buy it, huh?), and Jay is plugging away at (and just plain plugging) his upcoming tome from Addison-Wesley,Securing Linux the Bastille Way.


Jay Beale: Before we get to the questions, let me make an announcement. I've just recently been hired by MandrakeSoft (makers of Linux Mandrake) as their Security Team Director. They're sponsoring my work on Bastille and I'm working to better their distribution's general security. SecurityPortal.com interviewed me about this specifically.

Now, the questions:

1) Target audience
by DreamerFi

Bastille is a great project, but ultimately it targets people who sort-of know what they are doing. How do you feel about projects like the NetBSD/i386 Firewall Project who (whilst having all sources available) targets people who have no clue other than "I need security" by giving them a firewall that has an install that's about as simple as one can make it? Is this just a matter of defining the target audience different?

Jay: Really, it's not entirely targetted away from newbies. In fact, I sorta thought it was newbie-friendly. In designing the Bastille Linux hardening script, we originally sought to make a basic script, that would simply go through the sytem making changes. It could shut down unneeded programs/daemons, tighten up permissions and deactive bad protocols like telnet. At some point, we realized that this would leave many people believing we'd broken something... So, we decided we'd make the script interactive, asking the user before turning off telnet. Unfortunately, this meant that many of the target boxes never got hardened much. Since people didn't know why telnet was bad, they'd leave it on. So, I became a writer! Bastille carries a large number of explanations, targeted to the new user/sysadmin. By the way, the reasoning on deactivating telnet goes like this:

  • Telnet is cleartext, allowing third parties to sniff passwords
  • Telnet sessions can be intercepted and taken over by a man in the middle, using a simple tool like hunt.
  • Finally, telnet can be replaced easily by the much safer Secure SHell, ssh.

Jon: Setting up a firewall for people with no clue is an interesting problem. It requires that the person do pretty much nothing nonstandard: once you need to punch a hole in the firewall, all of a sudden you need to know a lot of stuff again. Alternatively, you could leave the firewall pretty much wide-open and just block a couple of things, which is much easier to do but doesn't add all that much security. Setting up a firewall properly is hard work, and requires specialized skills to do it right: I'm not comfortable setting up a firewall for a company to protect secret stuff, and I tend to recommend hiring a (qualified, competent, specialized) consultant for the job.

For Bastille, we try to fulfill both of those possibilities with a single piece of software. We try to both make it simple to use (lots of defaults that won't break stuff) but make it possible to lock the system down tightly. In either case, user education is key.

Of course, most people don't read documentation, so it's all in the script. You can lead a horse to water, etc., so we try to do that. Bastille seems (to me, anyway) friendly to newbies who read carefully and take the time to understand. I'm not sure how to really help the others anyway.

2) Breaking out the cluestick ...
by mosch

Given the world's largest cluestick with which you could assault every single SysAd on the planet, what clues would you distribute, other than the use of bastille, and the knowledge that there's life outside computers?

Jay: I'd have one major clue that I think supersedes most: Educate yourself! In terms of security, there's few solutions that can beat a clueful sysadmin. On the other hand, any solution you choose for security usually turns to mush when a clueless admin makes the wrong mistake with it. For instance, you might have incredible encryption on your passwords and such, but if you choose "bob" for a password, your system can usually be brute forced!

Jon: Yeah, that's pretty much it. The only clue worth having is the one that allows you to find the other ones on your own.

3) Security is a process, not a thing.
by Skapare

How will Bastille allow users to treat their computer and network security as a "process" (as Bruce Schneier is quoted to say). Are there tools to help users deal with security "events"?

Jay: We're working on integrating this. Right now, we've got something very rudimentary that checks to see if a cracker's sniffer has been installed on your system. We're working on more. I'm currently hacking up a series of scripts, like Tiger, that will examine the current state of the system for anomalies.

Jon: Security is a process, there's no question about it. When I've got a process that works pretty much the same every time, I turn it into a checklist. Bastille, when it comes down to it, is essentially a checklist that performs the tasks listed on it. So Bastille lets you automate your existing process.

Jay: Yes. A checklist. Actually, in these days of rapidly upgrading (read replacing) your distribution every three-six months, the only way to use a checklist as long as Bastille's is to automate it!

Jon: Software development is also a process; Bastille is in a constant state of development. As we find new things that need fixing, we go to the software development part of the process, then the release part of the process, and then the users hopefully take it to the upgrading process. :-)

(Hint: for this process to work, you need to participate.)

4) "Missing" features?
by Coz

A two-part question:

What features do you feel are missing from Bastille as it stands today, and aren't in the roadmap you have for the immediate future?

What elements of system security do you feel should be part of the "core" (if not the kernel) of the operating system, and why (in your opinions) aren't they there already?

Jay: Part I is a tough one. I think I'd like to see an amazing intrusion detection system integrated in. I've also got some ideas for new offshoots of Bastille that I'll need some time to develop before I bring them up. Part II is somewhat easier. I think an operating system should implement seperated "compartments" so that one root-level program can't tromp all over another.

Further, we really should move away from this simple Unix distinction of "root" and "non-root." We can get a lot more granular than that. We're already seeing this latter bit, such that my web server runs as user www, my name server runs as user named, and so on... I wish we could take this farther, as it would really curb the potential for remote root compromise. As for why we don't have it all yet, consider the huge effort to move to these models... Now, we're getting this, through add-ons. Medusa DS9 is bringing us compartments and system call ACL's that apply even to root. The Linux capabilities work is getting us further to a point where we can confine root's actions.

5) Question
by JCCyC

What were the top 3 most asinine security holes you ever encountered on a GNU/Linux distro?

Jay: There have been a number of security holes that looked dumb in hindsight! I think the more interesting question is this, "what security holes right now are going to be seen as stupid later?" We're going to think that there shouldn't have been nearly so many world-executable setuid-root programs. We're going to seriously question having network-accessible system daemons (ftp, dns, web...) running with root authority. Luckily, we're just starting to question this now. Let's see where it goes...

Jon: I'm with Jay on this one. I don't think that any of the decisions that distributions make are particularly stupid, they're just aimed at different markets.

For example, I don't really think it's possible to completely secure either SuSE or Debian, due to the sheer number of packages included. That doesn't mean that this is the wrong decision to make, it's just aimed at a different population with different needs. (Of course, you can install either of those distributions perfectly well -- but you can't install everything, and you need some more knowledge to do it right than on some other platforms.)

6) Configuration
by FeeDBaCK

In what way does Bastille differentiate between different types of installs? Does it prompt the users about services? Will it shut off my apache service if I plan on making this machine a web server?

What third party tools do you install/recommend to help with the hardening of the system? Tripwire? tcpserver?

Do you incorporate any form of checking when doing your install to ensure that the box has not already been compromised, such as checking for common trojans/backdoors?

Jay: Oh no, another multiple-part question. OK, first, Bastille doesn't really do this distinguishing for you, when run in the default interactive mode. You make the choices, turning off services that you don't need, tightening the configuration on those you do. Second, I strongly recommend Tripwire. It's really the only way to know if your system has been compromised. I'd also recommend replacing your mail daemon with Postfix, as it's got an incredibly secure design. Third, no, we don't. Damn, that's a good idea. FeeDBaCK, want to help us develop that? E-mail me.

Jon: If the box has already been sufficiently compromised by a sufficiently capable and dedicated individual or group, it's a technical impossibility to detect it. Let's say you've cracked the box and installed some custom kernel modules that will report 'correct' file contents for, say, your PAM library even though it's been changed. Tough to do? Yeah. But possible. How would you defend against this?

That's not to say we shouldn't try, but I don't think we can provide adequate assurance on the issue ...

Jay: Jon's got a good point here. But we can, as FeeDBaCK suggests, do at least the trivial first measure of looking for known trojans.

7) Debian?
by luge

Do you guys have any plans to do something similar for Debian, or have others approached you about it? I'd love to apt-get install bastille, and have it do something similar to what I've heard it does for RH. Anyway, even if you don't, keep up the good work.

Jay: We are planning on it. I'm working on a new architecture, which makes it easy to extend Bastille to other distributions without doing the classical "porting" work. We'll include Debian and even Slackware! Watch freshmeat or our announcements list -- when we're in beta quality, I'll announce.

8) Not such a good name for a distro ...
by AFCArchvile

..especially if you want to convey security. Do you remember your late 18th century European history? Right. The Bastille in France was invaded and destroyed, prisoners were liberated, and the monarchy was overthrown by that terrible harbinger of death, La Guillotine.

I'd hate to see any Bastille Linux-oriented viruses or trojans. Maybe there will be one which triggers on July 14th of every year and echoes on the screen: "Libert=E9! Egalit=E9! Fraternit=E9!"

For more historical stuff on Bastille Day, check out this link to the French Embassy.

Jay: OK, so maybe it was a tough name. To tell you the truth, this year's July 14th LinuxSecurity.com interview hit on my birthday ... For the official answer, I'll let Jon pipe in here ...

Jon: Yup, all that bad stuff happened. But the building wasn't the problem: the building was incredibly secure by any standard. The problem was the administration.

So it is with computers.

Besides, we're not a distribution. :-)

9) Why is Bastille Necessary?
by DG

In a perfect world, the Bastille scripts would be unecessary, because the default installation of the distribution would have been hardened from the get-go.

Why do you feel that various distributions are so insecure by default? What are the most common mistakes they make? What kinds of changes need to happen at Red Hat to make your scripts unneeded?

Jay: Well, some of the insecurity comes from trying to reduce phone support costs. Consider for a second what would happen if Red Hat deactivated telnet on their machines, for the reasons I stated above. How many man-hours would go to the five-minute telephone calls, explaining to newbies that telnet was insecure and that ssh was a valid replacement? On top of this, remember that vendors are constantly being pushed to add more and more features. This often flies right in the face of effective security, which is generally much more minimalist.

The thing is, really, that it's not always as clear-cut as "mistakes." The most secure installation is utterly and completely useless. Much of what Bastille's actions make the system at least "inconvenient" and often require user/sysadmin education. Bastille-type hardening programs will always be necessary, especially for Red Hat, a company which has to keep its distribution featureful, easy to use, and convenient.

Jon: Convenience and security are almost always inversely proportional. Red Hat's target market has a whole bunch of people whose goal is to get a web server on the Internet in sixty minutes or less; higher security would only be a barrier to their customers' goals. They know their target market better than we do, but our market is for people who need something else.

Also, I think it's very unfair to single Red Hat out. We picked them as our first target due to their market penetration in the US and the relative ease of securing it, due to the limited quantity of stuff it installs.

Jay: I have to agree with Jon again here. I'll stop before I get on my rant, but companies develop where their users/customers ask them to. People are not asking Red Hat or MandrakeSoft or any other vendor for greatly enhanced security -- they're asking for more convienence, easy of use and a massive feature set -- and they're asking for it without much regard for the effect on security. This isn't intentional. The users just don't know better yet. This is where education must come in. (End rant)

10) Distribution specific, etc.
by matman

I have two questions actually.

The first: do you plan to make a non-distribution-specific hardening program/system/script? If so, how? It would be neat to have a consensus between distributions on file locations, etc to make this easier; do you plan on working with other distributions to come up with some sort of common interface or environment?

The second: do you plan on including any kernel-based capability, IDS, or ACL addons? A good default use of these features would greatly increase the security of linux in general, but they are prohibitively complex for most users. Thus, these are great things to have taken care of by the system -- do you plan on working on something to control these things (semi)automatically?

Jay: Yes, definitely. In fact, I'm currently working on a new internal architecture that easily supports this. In essence, we simply have to keep track of and store more data about each distribution. On top of this, we have to check the state of the system more thoroughly, looking for general files, instead of packages. We'll be able to support a lot more than just Red Hat Linux and Linux Mandrake.

Unfortunately, I don't think we'll ever get to the point where we can dictate file locations to the distribution makers. They're not even maintaining the same file locations from release to release! I think it's mostly an issue of preference for their individual package maintainers, really.

As for kernel-level capabilities/ACLs, I'm highly interested in this. I think the implementations are still immature, but it'll be exciting. Usability will be tough, but I think it can be achieved. We can make this optional for new users and perhaps only place restrictions on small parts of the system. This stuff shows a lot of promise.

A final meta-question
by Jay

The question everybody asks, in a million different ways (sorry, I'm not going through the thread again to pick out users; you know who you are):
Why do this? Why not just use OpenBSD?

Jon: Because people use Linux. Ultimately, standard is better than better. For most tasks, most of the time, assuming that the stuff meets minimum qualifications, it's better to have a single platform than multiple platforms that fulfill different needs.

Besides, a fair part of OpenBSD's security comes from its feature-limited default installation. They've been subject to the same FTP and DHCP exploits as everyone else, only the features aren't enabled by default. Heck, they're not enabled by default for most classes of Red Hat installs either. But people use them.

I'm not opposed to auditing, and I'm not opposed to more secure defaults. But most boxes sure seem to me to be hacked via holes that are known, that have been out for months, in services that aren't being used, and that haven't been patched. We speak to those systems first, since the low-hanging fruit is so extensive.

Jay: Yup. Further, Linux has room to surpass OpenBSD, in my opinion. Linux developers are doing more kernel-level security work, because of Linux's popularity as a standard. OpenBSD, as Jon points out, misses vulnerabilities, because their auditors are human and non-omniscient. Kernel-level security solutions, like Medusa DS9 or WireX's Immunix technology, are the only way to really stop the vulnerabilities that the audits miss. Linux can really rocket ahead here and I think the whole Bastille project will be eager to help.

In closing, please allow me to give some credit where it's due. You can read about this on the web pages: Bastille's and mine. Pete Watkins deserves serious praise for developing and sharing a great firewall. He's also helped take charge of Bastille 1.x enhancements. Sweth C. and Mike Rash have done great work in helping to build new modules and hack existing code. And Yoann V.'s ramping up the new architecture with me -- Bastille will be his baby too, soon. Bastille has benefited from a number of collaborators and sponsors, many of whom you'll find in future CREDITS files.

This discussion has been archived. No new comments can be posted.

Answers About Bastille Linux From J&J HOLD TILL 15th

Comments Filter:
  • i agree, but would like to point out that from a workstation point of view (specifically as a new user) the joy of debian is installing every toy under the sun, letting dselect tell you what else you need to install to get the sun to work, and what programs will break the sun. so as a new user to debian, your first system is going to probably have all sorts of stuff installed. and even after that, if you are using the box as a workstation and trying to use it to do all sorts of things, you are going to have a lot of packages.

    imho all distros should at least attempt to include something similar to bastille for their system... i had telnet installed for a long time, and i would love to have the debian install tell me that telnet is insecure, use ssh. i would love to have the install lock down the box by default and have a script lead me though opening up the box (and telling me what security risks i'm introducing in running whatever as i make each hole). after reading this answers article i think im going to download bastille just to read through the logic of why and when to secure what.

    ---

  • About the same time Mandrake [of Enlightenment fame]'s come in.
  • by Nailer (69468) on Wednesday November 15, 2000 @01:57PM (#622235)
    Some believe a standard comes from being reasonably popular [if not ubiquitous], fully supported by every platform, with open specifications, and comprehensive analysis and documentation. SSH meets these criteria.

    Others believe standards come from ubiquity. Because Telnet is more popular than SSH, or WinNT more prevalent than Linux, it is standard. I, and perhaps most of Slashdot, would agree with the former view over the latter.

    It would require exactly the same amount of effort for your school to install an SSH client as a Telnet client. However, Win32 based OSs come with a reasonably functional [if not fully featured] client already built in. If your admins have gone to the effort to install a third part Telnet, they could do the same for SSH.

    The only serious issue I've seen with SSH is that many routers don't allow SSH access. This is a serious problem with the router and you should make your purchasing decisions accordingly.

  • I'd just like to thank the guys working on Bastille. I've used it on several PCs and recommended it to many people as a good primer on securing their box.

    I hope they do make good progress on their next version. I've switched a number of our boxes to Debian, and will most likely be deploying some Debian servers soon.

    Good work guys!
  • An intrusion detector could be run from a known-good machine, either remotely or on a disk removed
    from the suspect machine.
  • The smiley meant that I intended it as a joke. I know for a fact that no matter what I do, nothing can make my connection secure. That's why I don't care. Anything that I really need secured, normally web-based transactions with an SSN or something, I do with IE5, 128-bit encryption. Obviously not perfect, but it's secure enough against your amateur hacker with a used 486 or Pentium they got from freeboxen or something. Beyond that, I just assume anything I do is insecure, and I don't care. My box at home has no services open, and no important documents; if someone hacks it, I just reinstall.

    I recognize that sometimes you really need security. The best solution to that: disconnect all important computers from the Internet; use your own private (and proprietary) network.

    I still think that all computers should start coming with CompactFlash drives, and we should use those instead of these online file-storing services. Why can't anyone realize that the most secure place for stuff is under the mattress (essentially)?

    Don't tell me that this is repetitive, I know.
  • by Anonymous Coward
    Why couldn't the linux distros do the reverse theory of Batille? Have everything shutdown or secured by default and then at the end of the install have some huge list of questions that can be bypassed. This list of questions will ask if you want to:
    1. let users access/mount removable drives.
    2. run various services
    3. add suid to some things
    etc..

    Nick
  • First, I haven't yet seen a single incoming port that we block (I'm a student, not faculty).

    Your first meaning is more like the kind of standard that IEEE makes, which are simply documents that tell exactly how a given item works. This use is approximately the opposite of proprietary, in the sense that it's open for multiple uses by multiple vendors (or users).

    The other meaning is what I was referring to, a de facto standard. In this sense, WinNT and Telnet are both standards, just because you know that if you make an application compatible with WinNT (or, more precisely, Win9X), or Telnet, then it will work with the majority of PCs. Yes, you can make apps for Linux, and SSH-compatible servers, but a lot of people won't be able to use them.

    Why are all web pages programmed in HTML, and why do people get so mad when you use extensions or stuff like Flash? Because it's non-standard, by the latter definition. Sometimes you're stuck on a computer without Flash, or without the latest IE. If people just used the STANDARD, then you could see it from anywhere, but instead you have to boot up into Windows just to look at the page. I've heard of cases when people have this problem with web pages they've made themself. Using SSH isn't going to help as per this kind of standard problem, which is why I use Telnet.

    Also, see my reply to the other guy for why I don't care about the security factor.
  • Telnet can, in fact, be replaced with ssh. More than that, I think it should and must be replaced with ssh.

    I can hear it already..."But I can't get at my shell using SSH from my Windows box." You shouldn't have said that. Just go get some window putty [dyndns.org]. Put it in c:\windows\ for best results. It does raw connections and ssh connections, along with telnet connections. And it does it better than that piece of shit telnet client that comes with Windows.

  • I don't subscribe to the notion that these are in opposition to one another. That OpenBSD is not always the answer is very true. But all good things have their purposes. In fact, I use them both in my segmented, handy-man-special, home network:

    OpenBSD for Mac68K [openbsd.org] (all these were bought for a pittance on eBay):
    2 Quadra 700 [lowendmac.com]s: transparent firewall [openlysecure.org] (ipf [anu.edu.au]) and 3-legged NAT (ipnat [anu.edu.au])
    Quadra 610 [lowendmac.com]: mail server (qmail [cr.yp.to])
    Centris 610 [lowendmac.com] (w/68040 [mailto]): dns server (djbdns [cr.yp.to])

    LinuxPPC [linuxppc.com]: (Bastille'd by using the Sparc trick [sourceforge.net] on the FAQ [sourceforge.net])
    2 7300 [lowendmac.com]s: apache and MySQL (soon to be PostgreSQL?)
    9500 [lowendmac.com]/G3 [xlr8.com]: mol [maconlinux.net] / streaming with videod [pacbell.net], icecast [icecast.org] (Better choices are welcome.)
    Pismo PowerBook [apple.com]: dual boot

    I haven't had as many years using Linux (only 2) as you have. And aside from that my computer experience amounts to a few mid-'80s semesters of VAXen and the entire life of the Mac platform -- and around 4 months of NetBSD [netbsd.org] and OpenBSD. But I have to say it (adding BSD to the mix) hasn't been that hard at all. There are many similarities with Linux. Much of your current knowledge will transfer. For anyone who has learned guitar and then tried bass, or ukulele, you've experienced this before.

    But I still hope they [apple.com] get OS X (my future home?) right. Must ... have ... all.

    -B... [mailto]

  • Having DNS or whatever not run as root adds one level to a system crack. So I can't get a remote root through DNS? Fine... I'll get remote nobody. Then I'll use a local hole.
  • by martinflack (107386) on Wednesday November 15, 2000 @08:49AM (#622244)
    Jay: Yes, definitely. In fact, I'm currently working on a new internal architecture that easily supports this. In essence, we simply have to keep track of and store more data about each distribution. On top of this, we have to check the state of the system more thoroughly, looking for general files, instead of packages. We'll be able to support a lot more than just Red Hat Linux and Linux Mandrake.
    Unfortunately, I don't think we'll ever get to the point where we can dictate file locations to the distribution makers. They're not even maintaining the same file locations from release to release! I think it's mostly an issue of preference for their individual package maintainers, really.

    It dawned on me recently that Linux might benefit from a set of "meta-distribution" data stored in a defined location. You could start with defining the basic distribution and then let people/packages add additional data later.

    In more intuitive terms, have an /etc/distro directory which contained certain predefined files.

    Imagine:
    /etc/distro/vendor
    /etc/distro/release
    /etc/distro/homepage.url
    /etc/distro/security-errata.url
    ...

    Obviously this idea is simplistic and would need extending before it would be useful. But is it realistic that eventually a collection of meta-distribution files on the hard drive could help people like Jay working on Bastille by taking some of the guess-work out and saving some programming time?

    For example, if Red Hat (or someone who put together a RH-specific metafile) provided a shortlist of certain important files and their locations, which Bastille could easily query, when a new RH comes out that changes a file location, one need only change the described location in the metafile, and Bastille could continue to function untouched.

    Or maybe we could standardize on a package query script at /etc/distro/package which on RH would be a script that does "rpm -q" but on other distros, e.g. Debian, could do something else to detect if a package was installed.

    These are embryonic thoughts - anyone have more solid ideas for this type of thing?

  • by Anonymous Coward
    Will people please stop saying that telnet can be replaced with SSH.

    1) SSH is a commercial product which is not available for free. OpenSSH may be free, but is not yet as good as SSH.

    2) SSH needs a client which is not the same as the telnet client.

  • IDS is intrusion "detection" software. What if the intrusion has already happened? It is possible that there could already be a nice fat backdoor already installed on your system when you install your IDS package. As was stated above, this is more to catch some of the known trojans/backdoors that we can easily detect and remove during the Bastille script.
  • Or, compile your kernel without loadable modules. We're talking about firewalls here. They're just supposed to sit there with little to no human interaction and just do their one thing and do it well for months (years?) at a time. There's also (arguably) some speed advantages to having everything compiled into the kernel.

    'Course, theres those awkward times when your the nic driver is being a bitch and won't recognize both cards unless it's loaded as a module, but...
  • What does Bastille do for me that I can't get by following the rules of TrinityOS? [csuchico.edu]
  • More and more people every day are using the Internet on cell phones instead of computers. If this continues at the same pace, eventually no one will have anything that could possibly have ports open. Servers will need to be secure, but most servers are running BSD instead...

    Why is everyone forgetting that SSH is nonstandard? At my school we have NCSA Telnet installed on every computer, and not SSH. If I had SSH instead of telnet on my home computer, it would be more secure but I couldn't get in.

    Anyway, I have root access disabled remotely, so now they have to guess two passwords and a username. :)
  • Okay... how do you ssh to something that isn't a shell?

    The telnet protocol is used for much more than login shells. Maybe that's all you've ever used it for.
    --
    Obfuscated e-mail addresses won't stop sadistic 12-year-old ACs.
  • So when can we see Bastille as another control panel applet that comes with a default install? Especially if you work for Mandrake. Perhaps as part of the overall services applet for turning things on and off. Step 1: make your selections, Step 2: run bastille to see which of those you might want to reconsider.

    I'd like to see a nice users manual (ok, it would just be a compilation of the how-tos) for distros telling you how to set things up and lock them down.

  • On the same line, I wonder if it is feasible to install userland software without becoming root ( maybe using an account 'installer' which just owns the right files and directories).

    This should work at least for packages not containing root setuid files, and reduce the harm which can be done by a rogue instrallation script.

    Because I'm not sure that an audit can easily detect few armful lines in a long configure script.

  • by Luke (7869)
    Also remember that sprintf is in userland programs which make open holes themselves if they run root. I wasn't just talking about the kernel - when you use a BSD UNIX you get the whole system integrated together, not just a kernel with programs added in at the distro's whim.

    I may be way off but I think Debian is the only Linux distro to organize their development like this.
  • Apparently, the only Clue worth having is the Clue Granting Clue, because once you have that, you can get all the other Clues...

    ...AUGH! Kerberos is eating my soul!
    ---
    pb Reply or e-mail; don't vaguely moderate [ncsu.edu].
  • Which head of Kerberos? Or are they all collectively gnawing? Or taking turns?
  • RedHat installs no limited quantity of stuff. It's huge, and it installs stupid servers by default.

    Secondly, security can only be viewed as an "event" if you truly believe in event driven-programming. It's a feedback loop, between the outside connect (from a hacker or else) and the response. If you get hacked, you fix the problem and try again. No amount of auditing can fix that feedback loop. The only secure computer is one people can't connect to.

    True security will come when we have adaptive security systems - after all, Internet-connected computers get bombarded by information in the same way that we do, and we deal with it through adpativity. Design can only work so much on us (parents know that), but adaptivity is king.

  • by SquadBoy (167263) on Wednesday November 15, 2000 @07:21AM (#622257) Homepage Journal
    "For example, I don't really think it's possible to completely secure either SuSE or Debian, due to the sheer number of packages included." WTF, Does that mean? Speaking for Debian 2.2 you pop in the CD boot up partition and all that good stuff install the kernel, install the base system. When you get to the install the rest of the system prompt choose simple select *nothing* from the list of tasks click on ok it will not install another package drop you right to a log in prompt. At that point you can install what you want and only what you want. Ever try to do that with RH I have and maybe I was doing something stupid but I could not make it work. Just a base system and nothing else. On RH even if I picked no packages it still installed stuff after that point. Are there a large number of packages out there for Debian? Sure. But if you want to make a really simple, secure, clean bastion host IMHO there is no easier way to do a very basic install and then build on it than Debian. Now having flamed the boys one thing that I think is very cool about their work and the thing I liked most about it when I used RH was the education aspect. If you run in the interactive mode and read all the info you will understand what was changed how to change it and then if later you go to another distro you will have the knowledge to do it by hand. All in all great work guys but please learn a bit about Debian before making statements like this.
  • Bastille seems (to me, anyway) friendly to newbies who read carefully and take the time to understand. I'm not sure how to really help the others anyway.

    We all start as newbies. Goodness knows it is helpful to have stuff out there that explains security in a non-condescending manner. I have recommended Bastille to friends just for the explanatory scripts, whether or not they end up truly hardening their systems.

  • by neorf (223036)
    literate hackers

    i think this might be a typo, it's meant to say leet haxxors.


    ---
  • First: The Bastille analogy is a good one. The Bastille was stormed by a large number of peasants as I recall and the defense of the structure was overwhelmed. So it is with most unguarded systems or guarded systems with under-vigilant administration. It's really pretty clever.

    Second: Does anybody else think that the "Why not just use OpenBSD?" is nonsensical from the start? If you follow that sort of arguements then why do we need GNOME when we already have KDE? Why do we need any two projects that have similar goals? We need them so that they push each other to get better. Competition is good.

    Third: I'm glad somebody is finally examining root permissioned daemons. If this can be fixed right, we might be able to eliminate for the most part things like buffer overflow exploits to gain root access. It's this kind of thinking that's going to increase security.

    Oops, this became a few thoughts..

    Ben
  • Bastille was the Max security prison in Paris. Fell July 14, 1789.

    Maginot Line was what you were thinking of.

  • by deno (814)
    It must have been a LONG time since you last looked at Mandrake...

    While Mandrake-Linux used to be very open one year ago, we decided to turn this completely upside down, and have been working a lot on security for several months. We came a long way, and at the moment, LM isn't any worse than other big distros when it comes to security: IMHO, we already lead the pack in some respects.

    The goal however isn't too be "one of the best", but to become "the securest mainstream Linux distro": with Jay, Vincent and Yoann on board, we are on a right track to succeed in this aim.
  • The right kind of mistake is the one where the root userid is renamed mathilda, but everything is secure. . .
  • if you make the right mistake everything will be fine.

    Jay said: On the other hand, any solution you choose for security usually turns to mush when a clueless admin makes the wrong mistake with it.

  • I'm pretty sure snort can detect backdoors. I haven't had to do much security in the past year but backdoor/trojan detection software exist. Of course for trojans nothing really beats tripwire. As for backdoors, I've played around with some backdoor detection kits downloaded from Packet Storm.
  • by Anonymous Coward
    Among the vast amount of software that comes with SuSE is a hardening script similar to Bastille. Just thought I'd mention it.
  • How about this:

    1. Install distribution

    2. Configure kernel with ipchains

    3. Configure firewall rules in rc scripts

    4. Have last rc script halt userspace

    Yup, that's right, the kernel will keep sending packets around even if it's "halted". This is why you have to manually ifconfig an interface down right before the call to halt if you want it to stop answering pings when halted.

    With userspace halted, tell me exactly how you plan to break into the firewall. OK, you could break into the things _behind_ it if your firewall config sucks, but what else is new?

    Yes, this makes changing the config a bitch, but for the truly paranoid, it's worth the trouble.
  • by rjh (40933) <rjh@sixdemonbag.org> on Wednesday November 15, 2000 @10:32AM (#622268)
    First, most of the legal problems with ssh are nonexistent. The RSA patent has expired (yay!) and that means it's legal to use RSA left and right, up and down, this and that way if you want to.

    Second, OpenSSH is a pretty damn good solution. I'm using OpenSSH-2.1.1p4, and I've yet to have any complaints with it or the way it handles the SSH protocol. (That's not to say I wouldn't have done things differently, but that's to be expected.) If you want me to take your "OpenSSH may be free, but is not yet as good as SSH" comment seriously, first you'll need to explain to me exactly where you see it lacking.

    Third, "SSH needs a client which is not the same as the telnet client." Big deal. Telnet requires a client which is not the same as the ssh client. Both of them require the servers to be running the appropriate daemons in order to support connections. Telnet is a standard service and ssh is quickly becoming one.

    My ISP supports ssh for shell accounts, which is nice, because I make it a point to never telnet into my account. If a Mom-and-Pop ISP in the Left Armpit of Nowhere (also known as North Liberty, Iowa) can run the ssh daemons, then there's no excuse for any sysadmin to not be able to run the ssh daemons.

    Telnet can, in fact, be replaced with ssh. More than that, I think it should and must be replaced with ssh.
  • Or, compile your kernel without loadable modules. We're talking about firewalls here.

    Er, not necessarily. Bastille is for workstations and servers, really.

  • by disappear (21915) on Wednesday November 15, 2000 @10:39AM (#622270) Homepage
    Among the vast amount of software that comes with SuSE is a hardening script similar to Bastille.

    Yup. That's another reason it hasn't been one of our early target platforms.

    -- Jon

  • 3)You said it yourself, ssh clients are not yet standard.

    They come standard with the RH 7.0 distro. They come standard with several other distros as well. In fact, the only OS I'm aware of which don't ship with ssh are the Microsoft OSes--and Microsoft's reputation on security is so laughable that I can just write off their exclusion of SSH as more-of-the-same.

    4) I've been lots of places without access to an ssh client.

    Ugh. Write emails to the sysadmins. Not including ssh on a system borders on blatant negligience nowadays, and there's no two ways about that. No system, especially no UNIX, should be without OpenPGP-compliant and SSH-compatible software.

    Don't blame SSH for brain-damaged sysadmins, in other words.

    And still. SSH is a commercial product with a long history. OpenSSH is something fairly new, with a severe vulnerability as late as last week.

    First, I haven't heard a thing about this "vulnerability", so I can't comment on it. I'm speculating that either it was an extremely esoteric vulnerability, or else not a very serious vulnerability--news tends to travel fast about inferior crypto where I work. :)

    Second, what makes you think commercial SSH is without flaws? Just because you can't see the bugs (because you can't see the source) doesn't mean there aren't any. In the long run, open source--with withering peer review and brutal accountability--will always be better than any closed-source offering.
  • by festers (106163)
    I suppose your talking about other devices, such as routers and switches that you can use telnet with? Well, guess what genius, those mfgs could use ssh instead of telnet, or at the very least allow both (have port 22 and 23 available). Try again next time and save those +2 bonuses for when you have something 1/2-way insightful.


    --------
  • I for one always chmod o-rwx,u+rxs,g+rx when I want to setuid a program -- and then I set up a group of users that are allowed to use it.
  • I saw this article today - Monday, Nov. 20th so I doubt anyone will read this, but anyway -

    I installed bastille over this last weekend on a box I'm turning into a firewall, my first attempt at any type of security precaution. I was impressed with Bastille even though I didn't understand half (or more) or the questions. It did become a little frustrating to answer pages of questions I didn't understand, but at least I have an idea of what I'm supposed to know something about anyway. I don't really know much about what Bastille did but I do know my box is more secure. How do I know? Because not even my home lan can talk to it. I have to attach the console and keyboard to do anything. :)

    I'm still working on getting it to actually function as a firewall, but for now at least I know it's secure. Thanks for the app, it's been a good introduction to learning what I didn't know I didn't know.

    Ctimes2

  • Translation: "Yes, I am completely unaware of the possibility of telnetting to something besides a shell."

    Ever used a MUD?

    "Try again next time". I bow to your smartassness.
    --
    Obfuscated e-mail addresses won't stop sadistic 12-year-old ACs.
  • by cduffy (652)
    That doesn't mean there's (ever) any reason to run raw telnet on externally visible lines.

    Tunnel the telnet connection to your mud with ssh or ssl. Yes, you still need telnet around -- but the outside world should never see it.
  • Put up a web server which serves a copy of putty over a ssl-protected session. Wallah. Presuming your server is uncracked, you can go to any Windows machine and you have a known-untampered copy of a good client. Put a copy of MindTerm (or whatever it's called) on your web server, and you can ssh in from any Java-capable browser. You don't NEED to have a client wherever you are to get a shell on your server without telnet.
  • by festers (106163)
    hmm, running a telnet daemon on a server and using a telnet client are 2 different things, dumbass. You'll always have a need for a telnet client as long as you are wasting your time MUDs and other lame-ass games.


    --------
  • I totally agree. I ran Bastille on a machine of mine some time ago, and aside from having some annoying little (and, as I later found out, documented) problem connecting to IRC servers with ircII, I didn't have any problems, and it explained to me alot of things that aren't well explained elsewhere. It's nice to have that kind of resource around.

    ----

  • Well, it looks as if I have found myself something to occupy a little of my free time. I will start looking into the more common worms, trojans, and backdoors that are out in the wild and attempt to build a way of detecting them.

    As Jay stated, no, I don't expect this to stop the experienced hacker from having hidden trojans. I do expect it to stop the 'leet skript kiddiez from having the ability to compromise hosts with little or no knowledge on their part.
  • 1) Turn off everything that listens to the network (everything in /etc/inetd.conf, apache, ftpd, named, sendmail, you-name-itd, and use the --nolisten parameter when starting X)

    2) Install sshd - configure to only accept connections from the local network

    3) Install portsentry, and configure to add a reject route to anybody trying to connect to anything on the firewall (except sshd)

    4) Setup ipchains and IP-masquerading to forward any connections not resolved on the local network.

    Optional steps may include adding ipchain rules to forward things like cvs connections from outside to your local server, if you are running your own project (like me).
  • by Mop (30370) on Wednesday November 15, 2000 @07:54AM (#622282)
    Let's say you've cracked the box and installed some custom kernel modules that will report 'correct' file contents for, say, your PAM library even though it's been changed. Tough to do? Yeah. But possible. How would you defend against this?
    Install a kernel module which checks that lsmod reports are correct, and communicate with the installer in a crypto-secure way so that any workaround to this kernel module loading will be detected.
  • is the example of the wrong question.

    Look, forget the distro wars for a few seconds - what is the end goal?

    It's secure Open Source distros. Bastille is a method/process to help the large number of Linux users at least have a chance at this.

    This is not to say that BSD is not a better choice for some, but each user has different needs, and we need to encourage the diversity which is Open Source, not get into blamefests.

    That given, the old rule still applies:
    90 percent of all security breaches are inside jobs.
  • You mean you could build something like floppyfw [zelow.no]
  • Here [bastille-linux.org]
  • What I'd like to know is: when will the royalties for the use of my name start rolling in ? ;-)

    Regards,
    Derek Bastille
  • What I'd like to know is: when will the royalties for the use of my name start rolling in ? ;-) Regards, Derek Bastille

    No, but your web site's URL would be posted on www.gnu.org if you changed your name to Derek GNU/Bastille! ;-)

  • "OpenBSD, as Jon points out, misses vulnerabilities, because their auditors are human and non-omniscient." and what, the Bastille guys are God-like and omniscient?
  • Unless you have personally audited the Linux kernel source, chances are your RedHat box is not as secure as OpenBSD, simply due to the extensive kernel audit that OpenBSD has had and continues to undergo.

    My point is that all of that work that the OpenBSD guys did (are doing) doesn't mean crap if I leave something stupid hanging open. Sure, out of the box, OpenBSD is probably way more secure than ANY Linux distro. But I know where to look to patch up my Linux box, and I don't on OpenBSD.

    So why don't I bite the bullet and learn OpenBSD? I probably should. But I have other stuff to do, like chemistry (computer monkey is not my real job). Linux helps me do chemistry, so I have to know it anyway. But learn the ins and outs of OpenBSD just to throw a firewall around my relatively safe (and frequently backed up) Linux boxes? Not worth my time, especially when i can do it in Linux if I really want that extra layer of security.

  • by festers (106163)
    I won't stop saying telnet can be replaced with ssh because it's not true. I removed telnet from my Linux server over a year ago and have not had any problems connecting from anywhere in the world. Besides, it's such a great feeling to run a sniffer and see your ssh session nothing more than grabled characters.


    --------
  • by Luke (7869)

    Sure, out of the box, OpenBSD is probably way more secure than ANY Linux distro.

    No, actually, it is more secure than any Linux distribution out-of-the-box, period. It requires administrator intervention to make it insecure, rather than being insecure after the first reboot. It does put the responsibility for security after installation squarely on the shoulders of the administrator, but it also gives them the best starting point to work with.

    But I know where to look to patch up my Linux box, and I don't on OpenBSD.

    One of the main points for using OpenBSD is that you can do a default install and be sure that your box is secure. Unlike any other OS, which requires post-installation tweaking to insure security, OpenBSD requires no such tweaking. You have to go manually add/turn on those services you need, and in the process hopefully are aware enough of what you're doing to help ensure their security. I'd rather know how to set up Apache correctly than hope the folks at RedHat did their job right.

    I'm curious also as to which chemistry software you refer that is available only for Linux

  • I'm curious also as to which chemistry software you refer that is available only for Linux

    Fortran95 compilers and such. And it is a snap to download tonnes of software that works on Linux. Granted a lot of it works on generic UNIX type OSes, so OpenBSD is probably cool for those ones.

    Anyway, the point is, we (and lots of other people) have choosen Linux. Not OpenBSD. Maybe we should have choosen OpenBSD, but we didn't. So we need to work with Linux and don't feel like learning YAOS (yet another operating system).

  • Or, better yet, ifconfig eth0 down!
  • by rangek (16645)

    What they said about OpenBSD really struck a chord with me. I have been using Linux for 4-5 years, Solaris for a year or two before that, and IRIX for a year or so. I have admin'd under each of these systems (6-50 boxes at a time), so I know a little about security on each one.

    After a rash of hacks here (UMN), I considered firewalling my labs machines (redhat naked on the network). I was told by another admin, "Used OpenBSD, not Linux." Okay, OpenBSD is better out of the box, but I know Red Hat. I think my Red Hat setup is more secure than OpenBSD, because i know how to fix it better.

    In other words, OpenBSD is not always the answer.

  • by Enahs (1606)
    Heh, they didn't post my question, but I got it answered anyway...dude's working for Mandrakesoft hahaha...maybe they can throw in a "Would you like to supersize that?" I hope that Mandrake will get better settings than low, medium and high.
  • "OpenBSD, as Jon points out, misses vulnerabilities, because their auditors are human and non-omniscient." and what, the Bastille guys are God-like and omniscient?

    Er, no.

    I think we were just pointing out that 'audited' isn't necessarily the same thing as 'secure,' and that in fact the gap is much wider than people give credit for.

    We make mistakes. Heck, we make a lot of mistakes. But we do our best to fix 'em, too.

    -- Jon

  • >> I will start looking into the more common worms, trojans, and backdoors that are out in the wild and attempt to build a way of detecting them.

    How will this be different from using an IDS such as Snort? I'm not flaming you just wondering what you'll provide that most IDS's don't already.
  • by Luke (7869) on Wednesday November 15, 2000 @08:29AM (#622298)

    I think my Red Hat setup is more secure than OpenBSD, because i know how to fix it better.

    Unless you have personally audited the Linux kernel source, chances are your RedHat box is not as secure as OpenBSD, simply due to the extensive kernel audit that OpenBSD has had and continues to undergo.

    Why don't you do a grep 'sprintf' on the source for your Linux box and see what comes back? The OpenBSD team just fixed 800 format string errors in the current source, not because they are known exploits but because they simply could be. This proactive stance sets OpenBSD apart from any other OS.

Loan-department manager: "There isn't any fine print. At these interest rates, we don't need it."

Working...