Slashdot Mirror

Erik writes "In this article, Jay Beale (Bastille Linux Project, Mandrakesoft) explains why Security Through Obscurity is actually a really good idea if you do it right. A good read for sysadmins." Agreed... a lot of really interesting points well written and entertaining. For starters you can't rely just on obscurity to keep you safe. But it doesn't hurt to obscure things sometimes just to make it tougher for your attacker.

Information (yes, in English;)) below about superconducting cables in Denmark, more information on how not to get your server broken into (process, not product, naturally), and another update for the Linux Kernel Summit.

Under the sea, a strange force was brewing ... Dag Willén, Group Leader, Superconducting Technologies at Denmark's NKT Research, wrote in regards to the recent story about superconducting cables in Denmark, saying "Info in english about this project can be found at www.supercables.com. (sorry for our "one-size" web design for 600x800 px, it was limited budget and talent.)"

Thanks, Dag.

Moving pictures of moving words Recently, a kernel summit took place, and many of the top kernel developers gathered in San Jose to wear funny hats, drink, and decide (or at least debate) on further directions for development of the Linux kernel. Chris DiBona pointed out there are now videos and sound recordings available for download, and you no longer need Real (as originally announced) to enjoy seeing and hearing all these smart people at work. Hopefully, these will one day be joined by Ogg versions as well;)

Don't trust malicious scumbags is part of "trust." AltGrendel writes "SecurityPortal has an article on how Apache.com was compromised. As the Billy Joel song says 'It's a matter of trust'." As always, Kurt Seifried is lucid and informative -- and brings up good points on protecting sites no matter how careful the admins are.

Information (yes, in English;)) below about superconducting cables in Denmark, more information on how not to get your server broken into (process, not product, naturally), and another update for the Linux Kernel Summit.

Under the sea, a strange force was brewing ... Dag Willén, Group Leader, Superconducting Technologies at Denmark's NKT Research, wrote in regards to the recent story about superconducting cables in Denmark, saying "Info in english about this project can be found at www.supercables.com. (sorry for our "one-size" web design for 600x800 px, it was limited budget and talent.)"

Thanks, Dag.

Moving pictures of moving words Recently, a kernel summit took place, and many of the top kernel developers gathered in San Jose to wear funny hats, drink, and decide (or at least debate) on further directions for development of the Linux kernel. Chris DiBona pointed out there are now videos and sound recordings available for download, and you no longer need Real (as originally announced) to enjoy seeing and hearing all these smart people at work. Hopefully, these will one day be joined by Ogg versions as well;)

Don't trust malicious scumbags is part of "trust." AltGrendel writes "SecurityPortal has an article on how Apache.com was compromised. As the Billy Joel song says 'It's a matter of trust'." As always, Kurt Seifried is lucid and informative -- and brings up good points on protecting sites no matter how careful the admins are.

An Anonymous Coward writes: "I found this at SecurityPortal, here. I use IPF and I noticed last week in the snapshot the license changed: 'Yes, this means that derivitive or modified works are not permitted without the author's prior consent.' which was kind of bad since it violated OpenSource guidelines. Now the current snapshot of IPF says 'Redistribution is not permitted' which completely violates any Open Source style license. Does this mean IPF will have to fork an older version or someone needs to write a completely new version for all the BSD's/Solaris/etc?" The old license certainly doesn't read this way to me, but IPF author Darren Reed asserts this is only a clarification of the license, not an actual change. Another ssh vs. OpenSSH? More coverage at LWN, partway down the page.

Curious__George writes "Kurt Seifried on SecurityPortal (4-11-01) writes on a topic that deserves wider notice in the Linux world: The potential dangers of installing BINARY RPMs (as opposed to SOURCE RPMs). Here is the article in standard and printer-friendly versions." (Read more below.)

"He begins: 'I'm always amazed at the lack of articles on topics like RPM and PAM. These are basic systems components and tools that people use every day but which, generally speaking, are poorly understood (if at all). Prepare to be educated.. . . Generally speaking, RPM's must be installed as root, which means that RPMs can do anything on your system: install new files, overwrite files, reconfigure system settings, add new users, etc.

Why is this important? Because many people download RPMs from semi-trusted or untrusted sources and blindly install them.'

Curious George points out: "The potential for danger (with many newbies and not-so-newbies making use of binary RPMs from untrusted sources) is that Linux could develop an unwarranted reputation for problems by someone (or perhaps some Corporation?) purposely diseminating RPMs with built in vulnerablilities or exploits. We should do our part to educate and spread the word on this issue."

Curious__George writes "Kurt Seifried on SecurityPortal (4-11-01) writes on a topic that deserves wider notice in the Linux world: The potential dangers of installing BINARY RPMs (as opposed to SOURCE RPMs). Here is the article in standard and printer-friendly versions." (Read more below.)

"He begins: 'I'm always amazed at the lack of articles on topics like RPM and PAM. These are basic systems components and tools that people use every day but which, generally speaking, are poorly understood (if at all). Prepare to be educated.. . . Generally speaking, RPM's must be installed as root, which means that RPMs can do anything on your system: install new files, overwrite files, reconfigure system settings, add new users, etc.

Why is this important? Because many people download RPMs from semi-trusted or untrusted sources and blindly install them.'

Curious George points out: "The potential for danger (with many newbies and not-so-newbies making use of binary RPMs from untrusted sources) is that Linux could develop an unwarranted reputation for problems by someone (or perhaps some Corporation?) purposely diseminating RPMs with built in vulnerablilities or exploits. We should do our part to educate and spread the word on this issue."

Curious__George writes "Kurt Seifried on SecurityPortal (4-11-01) writes on a topic that deserves wider notice in the Linux world: The potential dangers of installing BINARY RPMs (as opposed to SOURCE RPMs). Here is the article in standard and printer-friendly versions." (Read more below.)

"He begins: 'I'm always amazed at the lack of articles on topics like RPM and PAM. These are basic systems components and tools that people use every day but which, generally speaking, are poorly understood (if at all). Prepare to be educated.. . . Generally speaking, RPM's must be installed as root, which means that RPMs can do anything on your system: install new files, overwrite files, reconfigure system settings, add new users, etc.

Why is this important? Because many people download RPMs from semi-trusted or untrusted sources and blindly install them.'

Curious George points out: "The potential for danger (with many newbies and not-so-newbies making use of binary RPMs from untrusted sources) is that Linux could develop an unwarranted reputation for problems by someone (or perhaps some Corporation?) purposely diseminating RPMs with built in vulnerablilities or exploits. We should do our part to educate and spread the word on this issue."

Jason Bennett, frequent reviewer of books, now regales you with this great piece on the background and development of the new encryption standard to replace the pretty-good-till-now DES. It's full of linked information you'll want to digest, too. Update: 02/23 12:32 AM by T : Note: The links I borked are better now; mea culpa (and beware copying in Mozilla).

Since it was officially approved by the U.S. Government in November of 1976, most of the world's sensitive commercial traffic has been secured through the use of the Data Encryption Standard (DES). In its twenty-five year lifetime, it has become the most widely used, most widely trusted, and most widely studied encryption algorithm in existence. Alas, in the same way that your Atari 2600 ^[?] is currently sitting on the floor of your closet, DES' lifetime has come to an end as well. This was most dramatically demonstrated in the three DES Challenges sponsored by RSA Labs between January of 1997 and January of 1999, with a DES-encrypted message eventually being broken in less than 24 hours. This challenge also witnessed the birth of a DES-specific cracking computer, a machine widely theorized about, but never before (publicly) built. Although variants of DES (most notably Triple DES) are still widely used, it became clear that a new algorithm would be needed for the next twenty-five years.

Thus was born the Advanced Encryption Algorithm Development Effort. Beginning in January, 1997 (just before the RSA challenges finally broke DES), the National Institute of Standards and Technology announced its intent to begin the Advanced Encryption Standard (AES) process. The initial AES workshop was held in April, with the official call for algorithms going forth in September. Importantly, this call specified that the algorithms submitted have a key length of 128 bits, and be free of intellectual property constraints. Algorithms would be accepted from domestic and international submitters, and the resulting algorithm would be completely public. The con test would also consider both the hardware and the software implementation -- a divergence from DES, which was specifically designed for use in hardware. Importantly, the hardware that the AES had to operate in could vary from the largest supercomputer to a ROM-based smart card or other embedded ed environment. A candidate algorithm might well be optimized for one or the other, but had to perform at least reasonably well on all to have a real chance of being selected. Finally, this algorithm would be designed from the ground up to use the long key length, and thus would be faster and more secure than Triple-DES is at that length.

Thus came the warriors to the joust. On August 20-22, 1998, the first AES conference was held, with fifteen different algorithms being presented. Over the next seven months, these algorithms were tested in laboratories around the world to probe for weaknesses and to test the their speeds. There is a huge selection of papers on these tests at the AES1 site for your perusal, so I will not try and detail those tests here. Suffice to say, several of the algorithms had serious problems identified, while others came through with flying colors. The next March, the second AES conference was the forum for the presentation of these results, and a subsequent discussion of which algorithms should thus advance to the final round. These finalists were announced in August of 1999, thus beginning the second round of competition. NIST subsequently issued an excellent report detailing their rationale about each algorithm, including the problems and benefits associated with each.

The AES finalists were:

• MARS (IBM) (their case)
• RC6 (RSA) (their case)
• Rijndael (their case) (how to pronounce it)
• Serpent (their case)
• Twofish (Counterpane) (their case)

Obviously, each candidate comes to the conclusion that their cipher is the best. Nevertheless, there are some shared criticisms of the various ciphers that show patterns in each one. Serpent, for example, is universally named the slowest algorithm (in software), even by its creators. Nevertheless, they make their case based on being the most secure algorithm of the bunch. RC6 and MARS are both very fast on certain processors, but terrible on others. As noted above, any serious AES candidate had to perform well across all platforms, and thus this variable performance tended t o compromise these candidates. None of the algorithms were ever broken by a practical attack, however, and all should be considered secure enough for serious encryption work. Thus was held the third AES conference in April of 2000. This was the final conference before the official AES selection, and the last chance for each algorithm to make it s case. The statements above were presented at the end of this conference in an effort to make that case. Once the conference ended, it was up to NIST to make its selection. The candidates could only wait.

Finally, on October 2, 2000, NIST released their final decision, that R ijndael was to be the AES selection. Simultaneously, NIST released a paper detailing their rationale for the selection. In sum, this paper says that any of the finalists could have been selected (an opinion echoed by man y in the industry), but that Rijndael proved to have the proper balance necessary between speed in hardware, speed in software, and security. To quote from NIST's statement:

Rijndael appears to be consistently a very good performer in both hardware and software across a wide range of computing environments regardless of its use in feedback or non-feedback modes. Its key setup time is excellent, and its key agility is good. Rijndael's very l ow memory requirements make it very well suited for restricted-space environ environments, in which it also demonstrates excellent performance. Rijndael's operations ons are among the easiest to defend against power and timing attacks. Additionally, it appears that some defense can be provided against such attacks without significantly impacting Rijndael's performance. Rijndael is designed with th some flexibility in terms of block and key sizes, and the algorithm can accommodate alterations in the number of rounds, although these features would require e further study and are not being considered at this time. Finally, Rijndael's internal round structure appears to have good potential to benefit from instruction-level parallelism.

At this point, it's all over but the shouting. At some point later this year, the Secretary of Commerce will officially designate Rijndael the Advanced Encryption Standard, and a new era will have begun. AES was specified (and is expected) to remain a standard for at least as long as DES, and to protect data for even longer, and barring a major development (such as faster-than-forseen developments in quantum computing), this standard will likely be met. No one expects research into new algorithms to die, however. There will continue to be parallel algorithms developed and used, just as there are today. Thanks to be combined efforts of NIST and the community, however, there will always be the bedrock of AES available.

In conclusion, I'd like to point out the positive role that the U.S. Government, as represented by NIST, has played in this process. The Free Software/Open Source community has taken its share of shots at the government over patents, copyright and crypto export over the past several years, and deservedly so. The AES process, however, was lauded throughout the encryption community as a fair and open process that brought together the best minds available to select the algorithm for the next century (as NIST likes to say). Making an algorithm a FIPS standard gives it a legitimacy that cannot be obtained in any other way, especially given the way that this standard was arrived at. The algorithm is completely free of any IP hurdles, as was specified at the beginning of the process, and since the code is open, it can be downloaded by anyone in the world (and since it was designed outside of the U.S., any attempt to regulate its export from the U.S. would be silly). It is reasonable to criticize when a situation is bad, but it is only fair to praise when something is good.

Bibliography

I used a great number of sources from print and the web, so it's only fair to list them here. I also put many links in the body itself, most of which go into much more detail than I did.

• NIST's main AES site is the place to start. It links to most of the technical information I linked to above.
• RSA's crypto FAQ has been around for many years, and the latest edition only gets better. Covers all sorts of ground on cryptography, both general and specific. If you're trying to learn more about crypto, this is the definitive place to go.
• SANS InfoSec has a good overview of the process and the finalist algorithms.
• A Cryptographic Compendium has a good AES section
• SecurityPortal has an excellent perspective on what AES means
• Everyone's favorite IT rag The Register has a solid overview of the process
• Bruce Schneier publishes a crypto newsletter through his company, Counterpane Internet Security. See especially the issues from May 15, 1998, March and August 15, 1999, and April and October 15 of 2000.
• Simon Singh's The Code Book provided some excellent background

This is Slashback for the evening. Please be advised, through the following items, about ... how to turn that extra Pentium into a firewall running iptables; the state of the Symantec patent on software updates (uughh!); more on can satellites, and more.

a filtration system for your 2.4 goldfish Jay Beale points to this followup to his "Why iptables rocks" article of a few weeks ago: "It fulfills my promise to show how to actually build a home/SOHO firewall with Linux 2.4's iptables aka Netfilter. It contains the full code, explained piece by piece, to build a working firewall with 2.4, including all kinds of cool packet mangling for load balancing, redirecting stuff to transparent proxies, or avoiding nmap stealth scans ..."

Out of embarrassment, perhaps? An unnamed correspondent points out this bit of news regarding Symantec's patent on software updates. The upshot is, without pointing out that updating software incrementally is not a patent likely to win them a lot of favor from the industry they have simply decided not to enforce it. Smart move.

Not yet in the can, or the cube either Casey Ho of San Jose's Leland High wrote with some interesting information for those interested in tiny amateur satellites; Leland is one of the handful of schools whose students are designing experimental payloads for inclusion on an upcoming launch.

[We] are focusing on making a CubeSat. Leland High school officially has one satellite to launch, and there are four teams now competing to make a design that will be approved by CalPoly technicians. My own group will attempt to broadcast a powerful long term signal using only a small satellite. The project is not easy since there are a lot of scientific guidelines we must meet. We are discussing how to create a reliable circuit and transmitter that will function in extreme temperatures, vacuum, radiation, and most importantly, after an extra powerful rocket launch. The requirements are available here.

For some of you posters out there, sorry, no living organisms or explosives are allowed on the satellites. ;)"

Machinima makes the grade ILL Robinson writes: "Wanted you guys to know that our Quake II-based machinima film, Hardly Workin', received top honors at Showtime Networks' Alternative Media Festival - alt.sho.com. In an awards ceremony on February 8th at MTV Studios, Showtime awarded The ILL Clan with awards in both Best Experimental Short as well as Best of SHO for the festival. Using Machinima (films created with a PC game that can be modified with users' assets), The ILL Clan's film gained notice from the festival's judges - citing Hardly Workin' as a short with a high degree of innovation, design & creativity. We're pretty excited to receive the recognition, all the way from fans of ours who had been following us from the beginning and now, from a top-tier cable TV network. Cruise on over to our site for the official announcement, or to Machinima.com for more machinima works. And thanks also to the Slashdot readers, as they helped spread the word of what Machinima is all about."

Congatulations!

Much has happened in the world, some of it even worth reading about. For instance ... More on BIND and where it's headed regarding openness, licensing and other things; an update on Protozilla, and what is undoubtably not the final word on Linuxgruven, SAIR and company.

Why is there a lizard in my hard drive? chromatic writes: "The Protozilla team has responded to the earlier Slashdot article with answers to some common questions." This helps explain a lot of the questions raised in comments about why anyone would want or need to run CGI processes locally.Yet another win for documentation!

The ties that BIND make great cable-holders, too. fredpasteck writes: "LinuxSecurity.com has a FAQ from Paul Vixie that helps to explain some of the controversy and misunderstanding surrounding the ISCs creation of a 'members-only' mailing list. Perhaps the community was a bit quick in their assessment of what's going to happen?"

Do you feel reading Bugtrak makes it easier to talk to people? Speaking of BIND, to dispel any misconceptions which may have entered the minds of readers of this story (which cited the reaction of several Big Names to recent moves to restrict certain information about BIND), Kurt Seifried of Securityportal wrote to clarify:

I actually interviewed Vince/Theo/Dragos/Greg via phone/email seperately, they didn't post those things to Bugtraq. Although they are all Bugtraq users ... hehehehe. (that makes it sound like we're all shooting up heroin or something).

Let it not be said that Bugtraq is a controlled substance.

Stop kicking, stop kicking! A nameless shirker writes: "More 'clarifications' from Linuxgruven CEO Matthew Porter can be found during a recent discussion on the Kansas Linux and Unix Users Association(KULUA) mailing list. His answers were very evasive to what were considered very straightforward (if direct) questions. The beginning of his involvement in the discussion can be found here with follow-ups linked from that message. Other discussion on this topic before and after Porter's response can be found near near the bottom of the following archive thread page.

Just wanted to make sure everyone could see how "clear" Porter makes things in his "responses" to the questions he is asked."

Much has happened in the world, some of it even worth reading about. For instance ... More on BIND and where it's headed regarding openness, licensing and other things; an update on Protozilla, and what is undoubtably not the final word on Linuxgruven, SAIR and company.

Why is there a lizard in my hard drive? chromatic writes: "The Protozilla team has responded to the earlier Slashdot article with answers to some common questions." This helps explain a lot of the questions raised in comments about why anyone would want or need to run CGI processes locally.Yet another win for documentation!

The ties that BIND make great cable-holders, too. fredpasteck writes: "LinuxSecurity.com has a FAQ from Paul Vixie that helps to explain some of the controversy and misunderstanding surrounding the ISCs creation of a 'members-only' mailing list. Perhaps the community was a bit quick in their assessment of what's going to happen?"

Do you feel reading Bugtrak makes it easier to talk to people? Speaking of BIND, to dispel any misconceptions which may have entered the minds of readers of this story (which cited the reaction of several Big Names to recent moves to restrict certain information about BIND), Kurt Seifried of Securityportal wrote to clarify:

I actually interviewed Vince/Theo/Dragos/Greg via phone/email seperately, they didn't post those things to Bugtraq. Although they are all Bugtraq users ... hehehehe. (that makes it sound like we're all shooting up heroin or something).

Let it not be said that Bugtraq is a controlled substance.

Stop kicking, stop kicking! A nameless shirker writes: "More 'clarifications' from Linuxgruven CEO Matthew Porter can be found during a recent discussion on the Kansas Linux and Unix Users Association(KULUA) mailing list. His answers were very evasive to what were considered very straightforward (if direct) questions. The beginning of his involvement in the discussion can be found here with follow-ups linked from that message. Other discussion on this topic before and after Porter's response can be found near near the bottom of the following archive thread page.

Just wanted to make sure everyone could see how "clear" Porter makes things in his "responses" to the questions he is asked."

Pac writes: "ISC suggestion of a new 'members-only' security information list for BIND has been the topic of the week over the Internet security community. Kurt Seifried has interviewed Paul Vixie, head of ISC, about the announcement for SecurityPortal. The article includes some (not very suporting) comments from Bugtraq users, including Vincent Danen's (from MandrakeSoft) and Theo de Raadt's (from the OpenBSD project)." If joining the program already in progress, you may want to take this as a chaser to the BIND vulnerabilities and members-only BIND info stories of a few days ago.

Pac writes: "ISC suggestion of a new 'members-only' security information list for BIND has been the topic of the week over the Internet security community. Kurt Seifried has interviewed Paul Vixie, head of ISC, about the announcement for SecurityPortal. The article includes some (not very suporting) comments from Bugtraq users, including Vincent Danen's (from MandrakeSoft) and Theo de Raadt's (from the OpenBSD project)." If joining the program already in progress, you may want to take this as a chaser to the BIND vulnerabilities and members-only BIND info stories of a few days ago.

Jay writes: "There's a story on Linux 2.4's new Stateful firewalling. Rusty and friends have vastly improved Linux capabilities, allowing it to filter against many stealth scans and DoS attacks. Their code rewrite brings powerful "stateful" firewalling that was originally impossible under Linux. The muchly improved packet mangling allows not only better transparent proxies, but load-sharing clusters and stuff. Actually, the coolest thing about the new architecture is that it's designed so anybody can add filtering methods, for stuff like rate limiting and MAC address-based filtering."

Kurt Seifried, who started out this End of SSL and SSH string, with Silverman responding, has now issued his follow-up. I promise anymore of this string will just go in Slashback.

guido_sst writes "Richard Silverman, co-author of O'Reilly's SSH, The Secure Shell: The Definitive Guide , has written a response to Kurt Seifried's article entitled 'The End of SSL and SSH?' at at Security Portal written after the release of dsniff 2.3. You can read the original article at SecurityPortal, the original Slashdot coverage on Slashdot, and Silverman's response at O'Reilly.." We had link to the story as well.

guido_sst writes "Richard Silverman, co-author of O'Reilly's SSH, The Secure Shell: The Definitive Guide , has written a response to Kurt Seifried's article entitled 'The End of SSL and SSH?' at at Security Portal written after the release of dsniff 2.3. You can read the original article at SecurityPortal, the original Slashdot coverage on Slashdot, and Silverman's response at O'Reilly.." We had link to the story as well.

AndyR writes: "SecurityPortal has a very interesting article by Kurt Seifried in which he writes "dsniff 2.3 allows you to exploit several fundamental flaws in two extremely popular encryption protocols, SSL and SSH." He makes many very strong arguments about key validity and the problem with not having a trusted third party signing keys." Don't throw away SSH just yet, it's still a lot better than nothing.

AndyR writes: "SecurityPortal has a very interesting article by Kurt Seifried in which he writes "dsniff 2.3 allows you to exploit several fundamental flaws in two extremely popular encryption protocols, SSL and SSH." He makes many very strong arguments about key validity and the problem with not having a trusted third party signing keys." Don't throw away SSH just yet, it's still a lot better than nothing.

AndyR writes: "SecurityPortal has a very interesting article by Kurt Seifried in which he writes "dsniff 2.3 allows you to exploit several fundamental flaws in two extremely popular encryption protocols, SSL and SSH." He makes many very strong arguments about key validity and the problem with not having a trusted third party signing keys." Don't throw away SSH just yet, it's still a lot better than nothing.

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.

A reader writes "Check the latest Kurt's Closet; he points to some interesting flaws on Debian 2.2, from a security point of view. " Kurt's Closet is part of SecurityPortal - he's got some good points, but it's also good to remember, as the article points out, that nothing is automagically secure. Always do testing on your own.Update: 08/30 01:44 PM by H :Thanks to Ben Collins, Debian guy, for sending a response which I've included below.Update: 08/30 04:32 PM by H :Kurt has written an update that will be appearing on the site soon. In the meantime, he also sent me the text - read below for more. From Ben Collins, To Kurt Seifred:

If you would have bothered to check the changelogs for the packages you noted as having "root hacks in them", you would have noticed that every daemon you pointed out is not vulnerbale to the holes you point out. Here is a list:

apache (1.3.9-13) frozen unstable; urgency=medium

* [RC, security] Backported security fix for Cross Site Scripting issue (CERT Advisory CA-2000-02) from apache 1.3.11 patch.
* Added default charset iso-8859-1 to initial configs.
* [RC, critical] Perl dependency reordered to "perl5 | perl", closes: #61421, #62427, #60575.
* Postinst no longer complains on missing /etc/aliases, closes: #60575.
* Cron script detects logfile lines with whitespace, closes: #59995.
* Fixed apxs filename edited when enabling modules (missing /g in rules sed); suppressed linking to -ldbm, closes: #53172.
* The apxs in apache-dev no longer needs apache binary, closes: #47221.
* Perms registered for suexec changed to 4755 from 4555, closes: #60147.
* Added text from beleagured Debian Webmasters to intro.html, making it clear the project is not responsible for installations, closes: #61414. * LICENSE file of manual included since 1.3.9-1, closes: #42940, #60994, #60995.

-- Johnie Ingram Sun, 16 Apr 2000 08:29:56 -0500

* Use setproctitle(%s,foo) in main.c, lamagra@DIGIBEL.ORG advisory.

-- Johnie Ingram Wed, 5 Jul 2000 18:50:07 -0500 As for netscape 4.75, it is *already* available in our potato-proposed-updates directory. Now I suggest you change the utter bullshit you have on your review to reflect the real information, and next time do some more digging before you make false accusations and spread misinformation like this.

From Kurt

Well, it looks like I made some significant mistakes in this article. I'm not a long time Debian user, so I am somewhat unfamiliar with it. It appears Debian backports fixes, and that Apache 1.3.9 and ProFTPD 1.2.10pre10 are not subject to the various vulnerabilities I mentioned. Unfortunately I did not read all the changelogs in question (in /usr/share/doc/*/). If I had, I would have noticed this.

Folks, I assumed (assuming is bad, I know) that Debian does updates like most distro's. I expected that if Apache 1.3.12 comes out with bugfixes, that they would issue a 1.3.12 package, not backport the changes to 1.3.9. I've also been writing a weekly Linux security digest for several months now, and while there have been Debian advisories regarding Potato, most of them mention the changes being merged in, rather than warranting a new release. I should have noticed that.

While RBL's failure isn't Debian's fault, my point is that they go to great lengths in some areas to make the distro "more secure", but are missing other very key elements.

I officially apologize to the Debian community, and am glad to have been made aware of an important point: Debian backports fixes, and it is necessary to read all the changelog files in question.

-- Kurt

Do you remember the Piranha debacle back in April? Welcome to Part II. Last Tuesday, it was revealed that Microsoft SQL Server 7.0 is shipped with a default password - just like Red Hat's piranha module. Unlike Piranha, SQL Server is very common software for large e-business websites. Unlike Piranha, the vulnerable software has been shipping for months. Unlike Red Hat, Microsoft refuses to take responsibility for their mistake, which, unlike Red Hat's, has resulted in actual documented break-ins, some at high-profile websites. So why haven't you read about it?

Because unlike Red Hat, Microsoft is getting a pass by the media.

Piranha is web clustering/failover software that was released in April by Red Hat without much QA. It somehow went out the door with a default password ("Q") and without docs explaining in big bold caps that it must be changed. If you installed the Piranha RPM without reading the docs carefully, you had a security hole on your site.

The hole allowed an attacker to come in over port 80 and execute arbitrary commands as the Piranha user, which would have been the web user. Typically that's a nonprivileged "nobody" account. While this is never good, let's just note for the record that this is a read-only exploit unless the webserver is very poorly configured.

The media flipped, in a word, out.

Piranha: A Case Study

On April 25, Computerworld announced that the "backdoor password ... could allow an attacker to compromise a Web server and deface and destroy a Web site." Informationweek and Internetweek both warned about "a back-door security flaw that carries ISS's highest danger rating." MSNBC/ZDNET ran the story as "Red Hat Linux open to backdoor password" and explained "there's a backdoor account in Red Hat's Linux that would let a computer intruder access and alter files." The Standard's early report on April 25 wasn't too bad but attacked -- as all reports did to some degree -- the strawman myth that open source is inherently secure. At least it didn't use the word "backdoor." Newsbytes was pretty much the same.

"Backdoor" implies that the flaw was deliberately inserted, by a thoughtless or even malicious programmer. Why did most stories incorrectly use that word? Mostly because that was how it was described in the press release. A security firm called Internet Security Systems found the flaw on April 24 and sent out a security advisory that used the term four times by the end of the first paragraph.

ISS also made some interesting statements when speaking to the press about the vulnerability. Oft-quoted was a line about open-source being both a blessing and a curse (the media loves "on the one hand, on the other hand"). I also liked this comment from their research director:

"There's limited quality assurance in the open-source environment," says Rouland, "because open-source software is basically a bunch of peoples' hobby."

Of the early stories about Piranha, the best one I found was Henry Kingman's ZDNet piece on April 24 (both early and accurate: amazing). CNET's on April 25 wasn't bad either, though they let ISS lay down the anti-open-source and pro-Microsoft propaganda a little thick.

In the days to come, the story didn't change much except to note that Red Hat -- correctly, as it turned out -- denied the seriousness of the vulnerability and tried to explain that it wasn't really a backdoor. Inter@ctive Week's Charles Babcock did such a piece on May 1.

Computer Reseller News still called it a backdoor on April 27. And NetworkWorldFusion's report and Informationweek's followup both came out on May 1, both got the important facts right, but both still called it a backdoor.

ClieNT Server News ran an article in their May issue explaining "Red Hat Red-Faced." I'm not about to pay to read the whole thing. The free synopsis that's available smirks at how "embarrassed" the company must be, and ends: "It seems that Red Hat left a back door in," dot, dot, dot.

The Standard had a second, fair piece that eschewed the term and even, after quoting the line about open-source being a "hobby," gently suggested otherwise.

But the gold stars go to just two good reports. SecurityFocus' Elias Levy, on May 1, turned the spotlight on ISS by pointing out how they "...can make headlines by using the right jargon, even when it's wrong." And Linux World News' Liz Coolbaugh, who had weighed in a few days earlier, questioning the media's coverage in her story "Red Hat Security Hole Not a 'Backdoor'."

If you find any more stories about Piranha, post them below. The Red Hat-bashing pretty much came to a halt a week later, when a little Microsoft-specific email virus named "ILOVEYOU" did a few billion dollars' worth of damage.

(Breaking news: all charges dropped; to quote 10,000 Maniacs, "who ya wanna blame?")

Microsoft SQL Server 7.0

You've heard about the SQL Server vulnerability, right? The one found on Tuesday, six days ago?

Well, no, you probably haven't, unless you read NTBugtraq. Even the maintainer of SecurityPortal's Microsoft Security Digest missed it this week (don't worry: I dropped him a note, he added it).

As the cracker Herbless describes it:

"It has come to light that it is now common knowledge that MS-SQL has a blank 'sa' password by default. This seems to affect a _lot_ of servers on the internet."

A default password vulnerability? Sounds familiar, doesn't it?

Here's Herbless's description and exploit code, posted to BugTraq last Tuesday. And here's Microsoft's acknowledgement, posted on Thursday.

Herbless wasn't kidding when he said it affected a lot of servers. If you're running SQL Server 7.0, with a firewall that doesn't block its port, and you haven't changed the sysadmin password, you're vulnerable.

As he described it to me, unlike Piranha's vulnerability which gave read-only access as an unprivileged user, this one typically gives access as "BUILTIN\System." I don't speak NT, so he had to describe to me what this is: "god-like powers ... greater that those of even the 'Administrator' user."

In other words, you have been 0wn3d.

You may be thinking that this is a vulnerability. Go back and read Microsoft's acknowledgement again. They say quite clearly, "The code does not exploit a vulnerability."

Does it confuse you that what was previously a "backdoor" is now not even a "vulnerability"? That threw me for a loop too -- as well as some of Microsoft's other disclaimers, which only make sense when you realize you're reading non-sequiturs about the newer version SQL Server 2000 (the vulnerability only affects SQL Server 7.0).

All will become clear, though, once you read this story from vnunet.com -- the only media story I've seen, by the way. The fault lies with the website administrators:

"Hacked websites 'didn't read the manual'

"Microsoft has blamed administrator error, rather than a bug in its software, for leaving hundreds of websites running SQL server open to attack this week."

Did they say hundreds? Yes, hundreds, at the very least. And did they say "hacked websites"? Yes -- this is not a theoretical vulnerability with no known attacks, like Piranha was.

All this month, Herbless has been cracking into websites like the National Transportation Safety Board and leaving edgy political messages (while backing up the original files and telling the admins how to close the holes). He confirmed to me that all his attacks, including the Fish and Wildlife Service, the UK's Adult Learning Inspectorate, and the Commonwealth Telecommunications Organisation, were done by exploiting Microsoft SQL Server.

Just to make the story that much better, according to Herbless, the default configuration of SQL Server 7.0 also has logging turned off -- in which case a successful attack would leave few if any tracks.

Sites are lucky if their webpages are hijacked; that way they know to fix the problem, format and reinstall. But some of those "hundreds" of websites running the vulnerable installation have surely been cracked by black hats who quietly installed Back Orifice or a similar remote-exploit program. They can set an SQL Server password, but it won't help them: they'll still be 0wn3d.

The proper fix would be to force the password to be changed before the software can be used, as piranha now does. Wayne Sowery of MIS Corporate Defence Solutions confirmed for me that "versions up to SQL Server 2000 do not ask for the SA password during installation ... we also tried various install options such as 'typical' and 'custom,' neither prompted for a new SA password." Incidentally, he too questions whether this is properly described as a "vulnerability," but I'm not sure what else it could be called.

The lesson here is that the media doesn't treat security reports very fairly. Some organizations have their own selfish reasons to push one agenda or another. (Like Slashdot? You bet. But you know where we stand.)

The motive doesn't have to be that devious, though sometimes, of course, it is. If a reporter gets to write a story that questions a core belief of Linux zealots -- whether or not it's actually a core belief, and whether or not they're actually zealots -- that will be much more attractive than simply reporting security news. The nitty-gritty of security news, after all, is rather dry.

So next time you see a biased polemic about system security, or even a small media feeding frenzy about the latest exploit, take a moment to ask why it's being reported outside of the admins' mailing lists. Open source software is still a new idea to many in the traditional news media, and that means that it's a hook for them to hang any kind of story on -- good or bad.

qbasicprogrammer writes: "Security Portal has a review on the security of Red Hat, SuSE, TurboLinux, and Caldera Linux distributions." Debian and Slackware are absent, but its a decent piece.

qbasicprogrammer writes: "Security Portal has a review on the security of Red Hat, SuSE, TurboLinux, and Caldera Linux distributions." Debian and Slackware are absent, but its a decent piece.

solar writes "SecurityPortal.com is running a comparsion between RedHat, Microsoft, and Sun Microsystems on the response time between software bugs being found and patch releases. Find out if open-source is the champion bug squasher we all believe it to be. " Interesting bit.

solar writes "SecurityPortal.com is running a comparsion between RedHat, Microsoft, and Sun Microsystems on the response time between software bugs being found and patch releases. Find out if open-source is the champion bug squasher we all believe it to be. " Interesting bit.

wozz writes "Kurt Seifried, author of the Linux Administrator's Security Guide, has written good article which discusses OpenBSD and demonstrates how to set up a simple NAT/IPF gateway box."