First, Solaris 9 comes with 61 listening ports, as shown in the analysis here. I did the netstat on my VMware image of a completely virgin Solaris 9 system. I thought it was 60+ for TCP alone, but this is still over 10 times what Red Hat 9 was shipping with. Solaris 8 was worse, so Sun is improving.
Next, tnamed is still active on Solaris 9. From the same box:
# grep tnamed/etc/inetd.conf
name dgram udp wait root/usr/sbin/in.tnamed in.tnamed
Finally, as another poster pointed out, Sun's got a great tool in JASS, a vendor-supplied tool. And we all owe a debt to Titan, the first majorly popular Sun hardening program. YASSPis also out there for Sun.
I think projects like Bastille, and to a greater extent the Center for Internet Security's work, both illustrate to vendors what improvements they could make and create a sysadmin awareness of and experience with hardening measures. Creating that awareness and experience then creates demand on the sysadmin's part that their vendor give them systems in better default configurations and comfort in the vendors' minds that the sysadmins can handle the hardening measures. Finally, these kinds of projects demonstrate the effect of hardening to sysadmins when their hardened systems fare better than their stock systems in the face of an attack.
The effect of easing the hardening of systems is to produce far more hardened systems, which has the macroscopic effect of making the Best Practice into a Standard Practice. Take the example of telnet on by default. Bastille and programs like it had been turning off telnet for years and educating sysadmins about SSH as a replacement before vendors became comfortable turning it off.
Here's another example, more complicated. Most Linux vendors chroot their DNS servers, for instance -- they didn't do this for the first two years that Bastille was around until the Lion worm changed their minds. Chroot'ed DNS servers fared much better, it had been best practice to chroot for a while, and projects like Bastille created a larger base of admins comfortable with the practice. When vendors' packagers decide whether to do this by default, they feel more comfortable with the idea if they've seen it done a great deal in the field. They feel even more comfortable if they've seen it done successfully programmatically.
The CIS benchmarks are excellent. The Linux benchmark is based strongly on the Solaris benchmark, edited by SANS's Hal Pomeranz and collaborated on by a number of great people in industry and government. Bastille and the CIS Benchmarks/Auditing Tools are pretty complementary.
Anyway, Bastille is also educational -- it was the first hardening program to interactively educate the user as it hardened the system. It educates to allow the user to make more informed decisions in how their system is hardened.
The question is entirely one of pre-install system hardening. Solaris 9 barely improved anything hardening-wise over Solaris 8. It still ships with over 60 TCP ports open, a large number of UDP ports open, and some default-listening network services that have been deprecated for over five years, like tnamed. tnamed is the Trivial name daemon and pre-dates DNS!
Red Hat, on the other hand, has moved to both turning no remotely-accessible inetd/xinetd services on by default and offers an easy install-time firewall that works transparently on workstations and very simple servers. The difference in exposure of vulnerabilities to attackers is tremendous. The vulnerabilities may still be there, but the attacker often can't get to them or can't get the same level of privilege out of them. For instance, running OpenSSH in privilege-separated mode the way most Linux distros do now means that some exploits don't work, while others only grant the attacker non-root access.
Linux vendors/creators have led the commercial Unix world in pre-install hardening - I like to think this is due in part to the success of Bastille Linux, a hardening program for SuSE, Red Hat/Fedora, Debian, and Mandrake Linux, as well as HP-UX and Mac OS X. Bastille ships on recent HP-UX O/S's, is available from both Debian and SuSE as a vendor-supplied package.
Colleges and universities need to stop being lazy and actually generate their own unique social security numbers instead of using numbers that wer e supposed to remain secret and only be used for tax and federal benefit programs. This is so simple and yet because of this mistake, this keeps happening. We hear about it twice a year, but it probably happens at least 10 times per year -- organizations don't tell us when they get hacked unless they are required to do so.
I wrote a chapter in the fictional book Stealing the Network - How to Own a Continent about a college student who steals social security numbers from his college. This is the second public story about universities losing tons of social security numbers because they continue to use them as student IDs since that book was released about 7 months ago. Universities should have stopped doing this so long ago...
Anyway, read my chapter! The whole book was really good. Ryan Russell and Kevin Mitnick edited it and it features amazingly cooler authors than me, like Nmap's Fyodor, Dan Kaminsky, FX and a number of other amazing people.
Read the reviews at Amazon if you don't believe me.
I wrote a chapter in the fictional book Stealing the Network - How to Own a Continent about a college student who steals social security numbers from his college. This is the second public story about universities losing tons of social security numbers because they continue to use them as student IDs since that book was released about 7 months ago. Universities should have stopped doing this so long ago...
Anyway, read my chapter! The whole book was really good. Ryan Russell and Kevin Mitnick edited it and it features amazingly cooler authors than me, like Nmap's Fyodor, Dan Kaminsky, FX and a number of other amazing people.
Read the reviews at Amazon if you don't believe me.
We've got Bastille Linux working on OS X 10.2.x. Within a couple weeks, we'll have 10.3.x support. We could prevent exploitation of this vulnerability (on systems running sshd) by disabling network authentication systems from getting data by DHCP.
If this is interesting to you, please join our mailing list and/or e-mail me via jay AT bastille HYPHEN linux DOT org.
Well, this isn't going to be a "super nessus" really. It still requires that some human being write the initial signature (XML encoding of the vuln/exploit). While it may provide an easier framework for creating those signatures than Nessus' NASL language (and that hasn't yet been proven), the core technology doesn't advance the state of attacker tools enough to really be that dangerous.
The only thing to fear (potentially) is that all those signatures are getting written now! And I'll agree with SHEENmaster that the creation of security tools, while a double-edged sword, benefits defenders even more than attackers.
I'm actually working on OVAL. The first critical difference to understand is that OVAL covers all vulnerabilities, while VulnXML only covers web-based vulns.
BTW, all the software described below either is or will be free.
Now, OVAL is in SQL right now, but we're working on an XML translation mechanism. The SQL is nice because it's intensely readable and writable by humans and also because it can be used to query a database of system attributes. That database leads to a technology called QNA, formerly known as Outpost.
QNA involves a system whereby which host-based agents insert data about the system into a SQL database which you can then query. The host-based agents give you far better accuracy than a network vulnerability scanner like Nessus. The database gets you massive scalability, so that you can check a thousand hosts in pretty reasonable times. (Nessus still rocks, btw. Go Renaud!)
BTW, you don't need QNA to make this useful. You can run an OVAL query interpreter on a single host to check a vulnerability. This query interpreter already exists for Windows -- we'll build it for Linux too.
I totally agree. But they're tools, not "solutions."
Anyway, Defense in Depth is always good -- if an attacker penetrates the firewall, it's good to have hosts that are harder to crack. If the host gets cracked, you'd want to have an incident response plan and policy so that you can contain the damage.
In Bastille Linux's defense, we try very hard to educate the sysadmin/user so they'll make better decisions. Bastille tries to educate the user, to help her build a good hardening policy for her hosts and hopefully her site.
And that education is one of the few things that will actually keep your sysadmins or users from blowing the entire site's security away with a bad decision... Who cares if you're proactively scanning for open ports when you don't know why some of those open ports are worse than others? Your admin has to know that allowing Samba/CIFS/Windows filesharing through the perimeter firewall is asking to be hurt badly. Your admin has to know that setting every Unix box to give root via rsh from a particular (spoofable) IP addess is asking for a domino effect.
We'll see if it breaks applications. Even if it doesn't, the fear of it breaking apps will probably stop many people from activating it if it's optional.
Tons of Solaris sysadmins still don't set the non-executable stack, even though it doesn't seem to break any major applications outside of certain debugger functionality... They're just too afraid that they'll break an app and lose their jobs. And that's rough, because nonexecutable stack defeats a fair number of buffer overflows on that platform...
kismac looks pretty cool for wireless audits. BTW, Bastille Linux is even more badly misnamed -- we've got it working on Mac OS X now! It takes a perl compile and a tweak to perl-Tk, but it works under X on Mac.
Anyway, if anyone here is interested in helping package Bastille for Mac, especially with that perl upgrade, please contact me!
Jay Beale, here, replying: Actually (plug mode ON), I'm writing a book called "Securing Linux the Bastille Way". It's just not done yet, whereas Jon's excellent book is.(plug mode off)
Slashdot Mirror
Next, tnamed is still active on Solaris 9. From the same box:
# grep tnamed /etc/inetd.conf
name dgram udp wait root /usr/sbin/in.tnamed in.tnamed
Finally, as another poster pointed out, Sun's got a great tool in JASS, a vendor-supplied tool. And we all owe a debt to Titan, the first majorly popular Sun hardening program. YASSPis also out there for Sun.
Finally, these kinds of projects demonstrate the effect of hardening to sysadmins when their hardened systems fare better than their stock systems in the face of an attack.
The effect of easing the hardening of systems is to produce far more hardened systems, which has the macroscopic effect of making the Best Practice into a Standard Practice. Take the example of telnet on by default. Bastille and programs like it had been turning off telnet for years and educating sysadmins about SSH as a replacement before vendors became comfortable turning it off.
Here's another example, more complicated. Most Linux vendors chroot their DNS servers, for instance -- they didn't do this for the first two years that Bastille was around until the Lion worm changed their minds. Chroot'ed DNS servers fared much better, it had been best practice to chroot for a while, and projects like Bastille created a larger base of admins comfortable with the practice. When vendors' packagers decide whether to do this by default, they feel more comfortable with the idea if they've seen it done a great deal in the field. They feel even more comfortable if they've seen it done successfully programmatically.
Anyway, Bastille is also educational -- it was the first hardening program to interactively educate the user as it hardened the system. It educates to allow the user to make more informed decisions in how their system is hardened.
Red Hat, on the other hand, has moved to both turning no remotely-accessible inetd/xinetd services on by default and offers an easy install-time firewall that works transparently on workstations and very simple servers. The difference in exposure of vulnerabilities to attackers is tremendous. The vulnerabilities may still be there, but the attacker often can't get to them or can't get the same level of privilege out of them. For instance, running OpenSSH in privilege-separated mode the way most Linux distros do now means that some exploits don't work, while others only grant the attacker non-root access.
Linux vendors/creators have led the commercial Unix world in pre-install hardening - I like to think this is due in part to the success of Bastille Linux, a hardening program for SuSE, Red Hat/Fedora, Debian, and Mandrake Linux, as well as HP-UX and Mac OS X. Bastille ships on recent HP-UX O/S's, is available from both Debian and SuSE as a vendor-supplied package.
I wrote a chapter in the fictional book Stealing the Network - How to Own a Continent about a college student who steals social security numbers from his college. This is the second public story about universities losing tons of social security numbers because they continue to use them as student IDs since that book was released about 7 months ago. Universities should have stopped doing this so long ago...
Anyway, read my chapter! The whole book was really good. Ryan Russell and Kevin Mitnick edited it and it features amazingly cooler authors than me, like Nmap's Fyodor, Dan Kaminsky, FX and a number of other amazing people. Read the reviews at Amazon if you don't believe me.
Anyway, read my chapter! The whole book was really good. Ryan Russell and Kevin Mitnick edited it and it features amazingly cooler authors than me, like Nmap's Fyodor, Dan Kaminsky, FX and a number of other amazing people. Read the reviews at Amazon if you don't believe me.
If this is interesting to you, please join our mailing list and/or e-mail me via jay AT bastille HYPHEN linux DOT org.
The only thing to fear (potentially) is that all those signatures are getting written now! And I'll agree with SHEENmaster that the creation of security tools, while a double-edged sword, benefits defenders even more than attackers.
-
BTW, all the software described below either is or will be free.
Now, OVAL is in SQL right now, but we're working on an XML translation mechanism. The SQL is nice because it's intensely readable and writable by humans and also because it can be used to query a database of system attributes. That database leads to a technology called QNA, formerly known as Outpost.
QNA involves a system whereby which host-based agents insert data about the system into a SQL database which you can then query. The host-based agents give you far better accuracy than a network vulnerability scanner like Nessus. The database gets you massive scalability, so that you can check a thousand hosts in pretty reasonable times. (Nessus still rocks, btw. Go Renaud!)
BTW, you don't need QNA to make this useful. You can run an OVAL query interpreter on a single host to check a vulnerability. This query interpreter already exists for Windows -- we'll build it for Linux too.
Anyway, check it all out. oval.mitre.org.
- Jay
Anyway, Defense in Depth is always good -- if an attacker penetrates the firewall, it's good to have hosts that are harder to crack. If the host gets cracked, you'd want to have an incident response plan and policy so that you can contain the damage.
In Bastille Linux's defense, we try very hard to educate the sysadmin/user so they'll make better decisions. Bastille tries to educate the user, to help her build a good hardening policy for her hosts and hopefully her site.
And that education is one of the few things that will actually keep your sysadmins or users from blowing the entire site's security away with a bad decision... Who cares if you're proactively scanning for open ports when you don't know why some of those open ports are worse than others? Your admin has to know that allowing Samba/CIFS/Windows filesharing through the perimeter firewall is asking to be hurt badly. Your admin has to know that setting every Unix box to give root via rsh from a particular (spoofable) IP addess is asking for a domino effect.
Education, unfortunately, is the hardest step.
We'll see if it breaks applications. Even if it doesn't, the fear of it breaking apps will probably stop many people from activating it if it's optional.
Tons of Solaris sysadmins still don't set the non-executable stack, even though it doesn't seem to break any major applications outside of certain debugger functionality... They're just too afraid that they'll break an app and lose their jobs. And that's rough, because nonexecutable stack defeats a fair number of buffer overflows on that platform...
Anyway, if anyone here is interested in helping package Bastille for Mac, especially with that perl upgrade, please contact me!
- Jay
Jay Beale, here, replying: Actually (plug mode ON), I'm writing a book called "Securing Linux the Bastille Way". It's just not done yet, whereas Jon's excellent book is.(plug mode off)