Answers About Bastille Linux From Jon & Jay 66
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.
Re:Debian and such (Score:1)
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.
---
Re:Royalties? (Score:1)
Re:Why this is unnecessary... (Score:4)
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.
Thanks Guys. (Score:2)
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!
Re:Detecting kernel module intrusions (Score:1)
from the suspect machine.
Re:Why this is unnecessary... (Score:1)
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.
Another option? (Score:1)
1. let users access/mount removable drives.
2. run various services
3. add suid to some things
etc..
Nick
Re:Why this is unnecessary... (Score:2)
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.
Re:OpenSSH and the RSA patent (Score:1)
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.
Bastille Linux vs. OpenBSD (Score:1)
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-B... [mailto]
Re:A couple thoughts (Score:1)
distributions (Score:3)
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?
telnet vs ssh (Score:2)
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.
Re:Trojans / Worms (Score:1)
Re:Detecting kernel module intrusions (Score:2)
'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...
TrinityOS? (Score:1)
Why this is unnecessary... (Score:1)
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.
Re:No (Score:2)
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.
Another control panel applet (Score:1)
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.
Re:A couple thoughts (Score:1)
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.
Re:OpenBSD (Score:1)
I may be way off but I think Debian is the only Linux distro to organize their development like this.
The Big Clue... (Score:1)
...AUGH! Kerberos is eating my soul!
---
pb Reply or e-mail; don't vaguely moderate [ncsu.edu].
Re:The Big Clue... (Score:2)
First... (Score:2)
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.
Debian and such (Score:3)
Definition of Clueful User (Score:2)
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.
typo (Score:1)
i think this might be a typo, it's meant to say leet haxxors.
---
A couple thoughts (Score:3)
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
Re:bastille? - Maginot Line (Score:1)
Maginot Line was what you were thinking of.
Re:ROFL (Score:2)
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 mistake. . . (Score:2)
But on the other hand... (Score:1)
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.
Re:Trojans / Worms (Score:1)
SuSE.... (Score:1)
Re:Four (semi-)easy steps to a secure firewall... (Score:1)
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.
OpenSSH and the RSA patent (Score:4)
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.
Re:Detecting kernel module intrusions (Score:2)
Er, not necessarily. Bastille is for workstations and servers, really.
Re:SuSE.... (Score:3)
Yup. That's another reason it hasn't been one of our early target platforms.
-- Jon
Re:OpenSSH and the RSA patent (Score:2)
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.
Re:No (Score:1)
--------
World-executable SUID programs (Score:2)
Thanks, and my experience (Score:1)
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
Re:No (Score:2)
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.
Re:No (Score:1)
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.
Re:OpenSSH and the RSA patent (Score:2)
Re:No (Score:1)
--------
Re:Definition of Clueful User (Score:1)
----
Trojans / Worms (Score:2)
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.
Four (semi-)easy steps to a secure firewall... (Score:2)
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).
Detecting kernel module intrusions (Score:3)
Is Bastille Better Than OpenBSD? (Score:2)
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.
Re:Four (semi-)easy steps to a secure firewall... (Score:1)
Bastille URL is broken (Score:1)
Royalties? (Score:2)
Regards,
Derek Bastille
Re:Royalties? (Score:1)
No, but your web site's URL would be posted on www.gnu.org if you changed your name to Derek GNU/Bastille! ;-)
What? (Score:1)
Re:OpenBSD (Score:1)
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.
No (Score:1)
--------
Re:OpenBSD (Score:1)
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
Re:OpenBSD (Score:1)
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).
Re:Four (semi-)easy steps to a secure firewall... (Score:2)
OpenBSD (Score:2)
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.
ROFL (Score:1)
Re:What? (Score:2)
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
Re:Trojans / Worms (Score:1)
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.
Re:OpenBSD (Score:4)
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.