 We switched because I had a demonstration for Solaris that was going to be on that screen and there wasn't a screen in the other room, but somebody owned the power adapter so that was kind of a pointless switch but we're going to stay here for this talk anyway. Pretty much we are going to go through a hardening process of Solaris. I had asked for about two hours and I got 50 minutes so we're going to be kind of cruising to get everything done in time. The old and back to the wireless thing for the rest of the day, the breakout area is going to be in Athena and wireless is going to be in here. What I want to do this morning is go through pretty much a step-by-step process of how to lock down hardening Solaris and install. Basically, the best practice of actually hardening a box before you put it on the network is what I'm looking at. However, because I live in the real world and I know that a lot of times these boxes are already on your networks, most of the concepts that we're going to talk about you can do to a live box. Any time that it's going to be something that's dangerous to a live box or to an operational box, I'm going to go ahead and point that out to you so that you know to be careful before you try it. What we're going to cover this morning are basically installation, what we do with the overview process, screen auto lock for the GUI, disabling services, setting up disc quotas, access control lists, set UIDs, set GID files which Solaris by default has a ton of permissions and setting them correctly, setting up, verifying the paths are correct, aliases, system identification, groups, accounts and passwords, logging, chronic add jobs and also the if you must use stuff that I would recommend that you turn off immediately before you even think about looking at your box. But if you've got to use it for some operational requirement, what we can do there. The NDDs and some miscellaneous stuff and finally the border. What I'm not going to cover today are DNS and bind, NIS and NIS plus, NFS and sort of specific or third party software like Apache or anything like that because in one of those we can talk for two hours on by themselves. First off, installation. Load from an official CD. Don't get some burned CD that somebody is that, hey man, this is a great Solaris A version, go with it. Also make sure that you set up your partitions large enough to accommodate patches. I found that one of the biggest problems I run into is that people download the patch cluster but they haven't actually set up a partition big enough to put the patches on the machine and they end up having to either rebuild or skip the patch. Don't load the entire distribution which is actually what I'm covering. I'm covering today from a full and an idiot install in other words. If you just come in and say everything plus OEM, that's how we're looking at it, don't do that. Just install the packages that you need and apply the appropriate patches. There is the link for the patches and the presentation is on your CD and all the links are on there so if you don't have them, you can just copy paste them out of there. Also maintain two current backups. If you have the resources, keep one on site and keep one off site. Open boot. Open boot is fun because I like to make things difficult with open boot. First of all, I suggest that you set the security level to full instead of command. However, at a minimum it needs to be set to command. To do that, from the root prompt, ee prompt security mode equals command. Very difficult. From the open boot prompt, set in security mode command. Also very easy. For full, pretty much the same things that you go with full instead of command. Open boot password. You should always set the open boot password. That way when somebody comes by and reboots your machine because somebody didn't lock the screen, they have to know an additional password before they can even begin to start playing around with your system. To do that, from the root prompt, ee prompt security password, it will prompt you and you can put your password in. From the open boot prompt password. Also set an open boot banner. To set the environment variable for the oan banner to true. And then the system property of or unauthorized access or whatever you want to put in there. Make sure that you've got something, it's an extra little no trespassing sign that you can put on the machine. The GUI really should be in the if you must view section because mainly what I'm talking about today are servers. And the fact of the matter is there is no reason that you need to have a GUI enabled on your server. If for some reason you are some idiot manager that decides that you need to have the GUI on there so that you can come look at pretty output or whatever. Then make sure that you have the auto lock enabled. For CDE, very easy to do. Right click on the desktop, choose desktop controls. Choose the screen style manager and click the on button. And then make sure to scroll the screen wherever you want it to be set. I like to do it at one minute. That way if I walk away for any reason it would immediately pretty much go to a screen lock. However, most people seem to like five or ten minutes a little bit better. It's a little bit more realistic in case you turn around to pick up a piece of paper. Open windows, properties, miscellaneous and set the screensaver to auto and fill in the number of minutes that you want to actually have it turn on the auto lock. Services. Before I get started on services, one thing. Disable all unneeded services. When I go out and do assessments pretty much at least one a week. And one of the biggest problems that I have there from an assessment standpoint and from an incident response standpoint is somebody that has got owned because they have their box sitting there with telemet running and FTP running or SEMP. Any number of services. Solaris starts about a 900,000 by default. So you want to make sure to actually disable only have the services that you're running. If it's an SSH server, make sure to have it running only SSH and nothing else. If it's Apache, just web and whatever method you're going to use to actually access the box remotely. SSH being the best choice there. I'm going to switch real quick to what I did was I did an ISS scan of a default Solaris installed with OEM. That is what ISS picks up as you see there are a ton of highs, a ton of mediums and a ton of rows. But I also did was at the end of this, after I went through the whole process, I did another scan to show you what the difference is and we'll take a look at that in a few minutes. But as you can see, this is what most people have sitting on that network. Most people just put it to fault install. If it works, they're good. So they think, unfortunately they don't realize the admin D has started, well this admin D has started by default. They don't realize that SEMP gaming is running and the UNFS server is running. Let me catch myself back up for that separate PowerPoint. Exciting. Okay, so disable unneeded services. First off, INED.com, that is where you're going to have about 30 unneeded services that are enabled by default. Telnet's in there, FTP is in there. What else? SMMD is in there, Tool Talk database server is in there. If you're not using them, disable them. If you're using any of those, try and figure out why and see if you can't get rid of them. The way to do that is just quite simply to comment out the lines that aren't needed. Also check your RC2.D and RC3.D directories that have the startup scripts in there. You don't want to move the file to a different name and stop the service that it's already running. I usually just use a lowercase letter then when it boots up it won't get it. Other people put dots in front of them and do all kinds of things, but whatever method you want to use is fine just as long as it has changed the name from a capital S with the number and the service. One thing that I like that people know is the GUI interface. Checkpoint 501, people love this stupid GUI on that thing. What I've been able to find out is if you've got some manager that wants you to run a GUI so he can come and look at the pretty firewall rules, what you can do is disable the GUI for having it running by simply killing an RPC. If you had an RPC dead, the GUI will not work. All you have to do if you want to enable the GUI is restart RPC manually, just a S71 RPC start and then start the GUI up and you can do whatever you need to do and then disable it when you're done. Make sure to disable send mail, it is started by default. If it's not a mail server and you want to get rid of it, it opens up a ton of problems for you. To do that, that is in rc2.d and it's the SADA script. If it is a mail server, configure it to prevent message source routing. I'm now running out the next few lines in the send mail.cf. I'm not going to read those but you can look at them and they are on the CD. Expand and verify are started by default. What you want to do with those is add the following two lines to send mail.cf. I've no expand, I've no verify, that would kill those for you. Install and configure secure shell on the CD in the directory. I actually put the HTML file for how to install OpenSSH on the CD so that you can read through it. It's got pretty good directions on what files you need. I actually wanted to put several other things including OpenSSH and the recommended zip files on there. But when I got done with all the stuff I wanted to put on the CD, I think I had a CD by myself so they told me to dial it back a bit. Use reporters. Does anybody have any idea why you would want use reporters? Mainly? Good. I'm going to assume you're right because I can't hear you. But if he said because you don't want your users to have... Users are generally running their own scripts. They've got all kinds of things they're running in their home directories. You don't want them to have something get away from them and run away and take up all of your disk space. If you have a quota there, it will stop all from happening. And putting these in quotas is actually pretty easy. The first thing you do is you edit the VFS tab and add the mount option for quota, which is just quota at the very end. There's a dash there by default, replace it with quota. Create a file called quota in the root directory of the file system. And for what we're doing here, we're going to take a look at export home. Touch export home quotas. Then you're going to need to set up a prototype quota entry. And to do that, you use egg quota. Egg quota, quota user, whatever the user that you want to be there. And you add the number of blocks, hard and soft blocks and inodes. What that does is that tells you how big of a disk space they're allowed to have and also how many files they are allowed to have. The inodes are the number of files. So in our example here, they're getting five megabytes of space and they are getting up to a thousand files in their home directory. That would be when they get a warning. That's the soft limit. The hard limit is when it will actually cut them off. They will not be able to log back in until they get that fixed. I'm sorry, they will be able to log back in. They will not be able to create any new files or add any new space to the disk. Then what you need to do is replicate that across the board for all the users. So if you have 10 users in there, egg quota minus p, then you're quota user. And then just list out the names of the users that you want to set that quota up for. Next thing you do is activate them with quota on, which is the quota on and the file system that you want the queries to be enabled on. Quota check command is used next and that is going to build the statistics. That's so that you can actually go back and see where people stand. Is anybody getting close to their quota limit and why? And to do that, just quota check minus a. That quota will then report that data back to you and it will look something like that, tell you where people are. Access control lists. Next, ACLs are very, very easy to set up in Salares, unlike some distros. There's a ton of things I like about it because you can change things around and only let people get to what they need to get to. It will allow you to avoid the group account problems. To do that, just use setFACL to set the access controls. For our example here, what we're going to use is a file called access file. It will give you an output of what it currently looks like. You can see that I have the ownership and the admins group get access to the file. Do a getFACL on it and it will show you that user has re-write, group has re-write, other has nothing. If we want to change that to allow a user named Russ, who was actually going to be sitting there showing you guys how to do this, but he's going now to have access to that file. He's not part of the admins group. Just do a setFACL minus a. The user and code one and then whatever user you want to have access to the file, what access is going to have in this case re-write and then the name of the file. Then when you do another getFACL on it, you will see that user Russ has been added to the list. SetUID and setGID files. I would actually recommend that rather than do exactly what I say here, I would actually script this out because otherwise it will take you a long time, but you simply do a find on the type here that will give you your setUID files. You can pipe that out to a file somewhere to look at later because like I mentioned before there are a ton. For the most part, very, very few of them actually need to be setUID. Same thing as setGID. Once you have those piped out, you can go through them kind of at your leisure and look at them or if you want to take the time to actually write a script out for it, you can have a grep through the file and pull out the ones that you want and change them, change the farms on them. Next, you want to find all the world-rightable files. Again, SolarOS has quite a few of these. Simply do a find on them, pipe it out to a file and go through and look at them. You should be able at that point to go through and figure out which ones need to be and which ones don't because there aren't that many that do, especially in a server environment. Permissions. Root UMass. Set to either 027 or 077 to do that. You edit the Etsy default login file and just set the root UMass to 077, which is what I actually recommend. The way the UMass works is it XORs, every time you create a new file, it XORs with the root UMass that is set in that file and it will then give you the opposite. So in our case, every file that Root creates is going to have initial permissions of 700. You also want to check the system device permissions by default. So the device permissions are set correctly. You shouldn't change them. There's really no need. What you would want to do is actually verify and make sure that they don't change and they have not been changed. You can check that periodically. You also want to check the permissions on UTMP. Ensure that they are set to 644. Ensure that the Etsy password is set to 644. Got to love the Root UMass graphic. And you want to make sure that the Etsy shadow is set to 400. Also, to really restrict the host type query of our hosts and .NET RC files, what I suggest doing on those is actually touching create them and then chmod zero them so that when you look down there, no one has read, write, or execute access to any of those. Restrict the privileges on Snoop to Root only. By default, I think that it sets it to, yeah, pretty much everybody can use it. So you don't want that. You don't want anybody who is on your network, especially if you're not in a switched environment to be able to sniff all your network traffic. So we're going to set the default provisions to execute for Root and no one else. The root user path. User bin has been and user has been. Root user really does not need to have anything other than Madness path. That's done by editing the .pro file file in Roots home directory. Also, this is another one that you're probably going to want to script out a little bit and I actually wanted to do that for you guys, but again, they had me pull a bunch of stuff off the CD so you didn't get everything. But you want to make sure that no user has a . in his path. Just if you're going to do it manually, if you're in an environment where you don't have a lot of users, it's pretty easy to just let the read user's path and make sure that there are no dots in there. Now, alternatively, it can be scripted, thanks. I recommend that you alias both the ls and the rm command. With ls, I like to add the dash a and dash b option and with rm, I like to add the dash i. What that will do is with ls, you will get all of your dot files. Without having to actually do a minus a, every time you type ls out, you'll get all the hidden files that may be shown to you so you can keep track of them and you make sure that nothing has popped up that you aren't aware of. With the dash i, what you do is, it's going to ask you before you, I'm sorry, before it deletes the file, it will ask you, are you sure you want to do this? This is particularly important with root because root can delete very important files very quickly. The example that I always like to give is a mistake that I made a long, long time ago where I did an rm minus rf dot dot slash star and that is recursive and it started going up and up and up and up and up to leading files. I would have very much liked to have had that ask me before it destroyed my entire file system. To do that, depending on the shell that root is using or the user is using, you follow the steps on there, you use cshell, you use the alias command inside the dot login file, born and corn, you add those lines to dot profile and with bash, you use the dot bash rc and do the same commands that you would use in the born and corn shell. Include the system name in the root and admin shell prompt. Most of your admins have access to multiple boxes at a time. So they're ssh'd into four different machines running around making changes. What you want to do is make sure that for at least those people, the name of the system that they're on is in their prompt. That way they don't accidentally change things on the machine that they did not mean to. Again, you do that with the cshell and the dot login file, born and corn in the dot profile and with bash and the dot bash rc. And you just do, for born and corn, the ps1 equals uname minus n for the cshell you set the prompt. Groups, accounts and passwords. What you want to do is require the users to use the new group command to change groups. To do that, don't have any users assigned to groups other than staff. Every single user to include your admins to have just a regular staff user group. Then you want to choose a strong group password for, let's say we're going to have the admins group in this case. You want to choose a strong password for that group. The easiest way to actually set that password is to change the password on a normally locked account. I like to use LP. To do that, just obviously the password LP, put the password in and then that's the slide that I lost. Then what you do is you actually cut and paste that out, edit the etsy groups file and replace the no password in the etsy groups file with that password. Then whenever someone wants to actually change to that group, they just issue a new group command. New group admins, for instance, it will then prompt them for the password. They put the password in and they are then part of that admins group. If they do not have the correct password, they cannot change groups. Obviously also you'll probably want to go back and relock the LP account when you're done. I like to restrict the use of SU. I'm kind of a jerk when it comes to getting rude access. I like to make it as difficult as possible even for people that are supposed to have it. If you want to actually get UID0 on one of my machines, you're going to have to provide me with about eight strong passwords before you're done. One of those ways is by restricting the use of the SU, there's our admins group. A sign of password to that group which we talked about. Then anyone, then change your permissions on the group and anyone who wants to then SU has to add as to new group first to the admins group and then they'll be allowed to SU. That's the system accounts. This one I'm not quite sure why so many of these accounts are unlocked by the Fed, the Solerys. Make sure to lock the Daemon, the LP, the BAN, the Sys, the ADM, the UCP, blah blah blah blah blah. Lock them all so that they look like that. Also lock the sysadmin and sysgroups in the Etsy group file. Same group process. Next you want to add the Etsy default password to require a password change. At least every eight weeks with a one-week interval between password changes. Also in that file you can set your minimum character length for passwords properly configured. You're going to look something like that where you have a max weeks of eight and then weeks of one and the password length. Eight, nine, ten, whatever you want to use there at least eight for the password length. One thing if the password is already enabled is not going to do anything until they have to change. In other words, if you've got some guy who's got his username, it's three characters for his password as well, until eight weeks have passed and he has to change his password, that password is still going to be sitting there. One PW check to check for inconsistencies. What that will do is it will check the field number, the login name, the UID, the GID and the login directory and shell for the user. Verify that those are correct. Do the same thing with the group. Run group check to make sure that those are properly configured and what you're expecting to see. Then you're also going to want to verify the permissions of Etsy group for 644. No all SU attempts. I like to, some people have this said so that they're not all logged, that only the failed issues are logged. I like to log them all. I want to know everyone that tried and everyone that succeeded to get SU. Disk space can be an issue if you don't check this and clear it out every once in a while. First of all, to do that you just verify that Etsy default SU exists and provides a path to the SU log. If you want to log something like that, then you also want to log the failed login attempts to the login log. You have to actually create that file. It is not created by default. On a very large network where you have a whole lot of users that are going to be logged in on a regular basis. This may not be feasible because you don't need to necessarily know every single login. It will just take up too much space and it's going to be something that you're never actually going to go through and look at anyway. But if you're in a small environment where you have only a few users, it's a good idea to actually see when and where and how they log in. To do that, after you touch it, you change the ownership over to root and assist group and you change the permissions to root only. Fail login attempts are going to look like this. Hacksaw did not get in. What that tells us is the time that he attempted to log in and failed and where he tried to log in from. You want to turn on INET D connection tracing and what that will do is attempt to trace all incoming TCP services and that will log in SysLog. To do that, you just edit the init.d INET services file and add a minus T to the INET D start line. So it will look like that. Then you're going to want to kill and reboot the INET daemon because it is not currently running with tracing on. This is assuming, of course, a live system. It's not going to be rebooted before you put it on the network. Just kill it. Restart it with the minus T switch. This is one of those things I was talking about before where if you're in an operational environment, this can be very dangerous. You want to configure the instance system to prevent stack-based buffer overflow attacks. Prevent is probably a little bit strong of a word there. Maybe help prevent is better. To do that, you edit the instance system and set the no-exec user stack to 1 and also the no-exec user stack log to 1. What that will do is any attempts to execute code on the program stack will be logged to SysLog. What I would do if you were in an operational environment is I would set the rev to 1 and not actually set the no-exec user stack. I say that because especially with some legacy third-party software, they are programmed to intentionally run code on the stack. If you have a bootable of 7 is actually one of those. So if you have a local 7 running on your machine, it will kill it and it will not work anymore. But if you log it for a couple of weeks, a month of normal environment time, then see if anything actually showed up in the log. If it did not, you're probably in good shape and you can go ahead and do this. If it did, then you know that you need to probably either upgrade that piece of software or if that's not going to happen, you don't want to do this. Next you need to check your Cron and add jobs for validity. Pretty much just look at them, make sure that what you expected to be there is what is there. Place the user IDs of the users that are allowed to create Cron jobs in the cron.allow file. Place the user IDs of the people that are allowed to create add jobs in the add.allow file. Conversely, you want to make sure that people that are specifically not allowed are in the cron.deni. I say that because the cron.allow is your default. That is what it's going to use. However, if for some reason that is bypassing and fails, the cron.deni will at least users that you know on the system that you absolutely do not want creating cron and add jobs, it will fail over to there and if they're in there, you'll have a secondary measure to make sure they're not allowed to create the job. It's also important to verify that cron jobs are legit before and after adding a user to cron.deni. That's because it only disallows users from creating future jobs. If they already have the job scheduled with cron or add, it will continue to run. You need to ensure that the scripts and programs that are launched by cron and add are readable only by the owner. You don't want anybody in their brother to be able to take a look at these. An example of that is if mail1.pl is scheduled to run in the cron tab, it should look like that. I'm the only person that has access to it. I'm the only person that can modify it. I'm the only person that can look at it. To the if you must users, FTP disabled. Use SFTP instead. If you have to use it, enable logging debugging by adding the ined.conf and adding the minus dl switches. Probably logging entry in ined.conf is going to look like that. Just at the end you have the minus dl. You also want to make sure that at a minimum, we will use FTP ban anonymous in the etsyftp users file. The etsyftp users file is the file that says who cannot use FTP. Who cannot FTP into your system? At a minimum those need to be in there. You want to configure the etsydefault FTP to remove the OS banner. You don't want every login to Solaris. They'll come back and they'll say sonos5.whatever. You want to get rid of that. You don't want to give them any eggs. There's enough programs and tools out there that will tell them what operating system you're running. They'll just freely give them the information and cut half the time out of their work. Also, if they actually haven't used NMAP or whatever, you're going to be getting something along the line to let you know that you've been scanned or whatever. If they are able to just FTP to and it tells them what version you're running, you've cut a lot of their work off. To do that, you just echo banner with null that's open and close quotes into the etsydefault FTPD. When they log in at that point, it will then have no login banner. Tell that banner is essentially the same thing. The etsy issue is the issue of warning banner. First of all, you're going to have to create that file. It is not created by default. Just again, put something in there. Unauthorized access. You're going to die if you come in, whatever. I don't care. Just something that tells them I don't want you here if you're not supposed to be here. The only reason you're doing that, I mean, it felt like Joe Lee guy is going to come in and say, oh well, I'm sorry, I have unauthorized access. I've never logged off. But what it will do is if you have a properly authorized by your deal department etsy issue and a warning banner, when it comes time for prosecution, you can take that to court and say, we told them don't come here. They came anyway and we want them to pay. Configure the file time at date or remove the OS banner. That is the exact same process as the FTP banner. And it will just get rid of the OS version once somebody logs in. The NDDs. Most of you guys are familiar with the NDDs. I like to use them. They allow you to do quite a few things that otherwise you don't really realize are running because nowhere does it say, oh, I have IP source routing enabled. There's no script that you can run through and find that where that is. But you can actually sit here with the NDDs and disable that stuff. First thing I'd like to do is get rid of the IP forwarding and directed broadcast. To do that, you just do an NDD-set, slash dev, slash IP, IP underscore forwarding, set to zero and hit enter. Same thing for forward directed broadcast. If you do a dash get instead of a dash set, it will tell you what it is currently set to. You want to configure the system to ignore redirects and disable the forward source routing. If you want to redirect, you want to set to one forward source routing. You want to set to zero to disable. You also want to configure the system to not respond to address mask broadcast, echo broadcast, time stamp and time stamp broadcast. Set all of those to zero with your NDDs. Also, while I'm thinking about it, there's not just dev IP. You have UDP, you have TCP specific. You can go through and look at them and see what exactly you do need, what exactly you don't need and there's a lot that you can disable. There's a lot of enumeration info that will come back to haunt you later that you can stop right there at the OS level and not have to rely on your board of devices. Here comes what I was talking about before about making it very, very difficult. A lot of people do not like to do this because it becomes very hard for your admins, as well as everyone else to gain access to the box. What I like to do is totally disable root log in from everything. Root can never log in, period. The only way that you can get UID zero is to log in at this point. If we do this, we'll have to know the open group banner to get the machine up. Then they'll have to have a regular user account and password so that they can log in. Next, if they want to ask you to root, they're going to have to have the admins group password so that they can get in and finally they're going to actually have to know the root password so they can ask you. If they can get through all that and only you deserve to be on because you have crappy passwords. To do that, console only access. You have the console setting and the Etsy default log in to dev console. That way, root can't come in any other way. As a sage can't tell and I can't FTP but it can still come in as a console user sitting at the box. Like I said, I like to go a step further and disable it completely and just set it to dev null. TCP sequence prediction. Do any of you guys use ISS? The ISS sucks with TCP sequence prediction. It shows up every time no matter what version of what software you're running. Everything apparently has a TCP predictable sequence and that's because they said it's like, if they guess it's one out of 500,000 correctly then it's predictable. But you can actually with Solaris 8, you can take care of that problem even for ISS's toughness. To set the TCP strong ISS to two in the Etsy default magnet in it, it is by default set to one. Next you want to edit the Etsy profile and set the U limit to zero to restrict the generation of core files. It doesn't always work but it's worth a try. Here's another one that can be kind of dangerous. Randomizing the file system i-load numbers with FSI ran. It tells you why, but again, very dangerous. You have to unmount the file system before FSI ran to be run. You want to make sure that you have backed them up before you do it and you check the file system on them because the chances of it actually ruining your file system i-nodes are just as good as it's working. That's one that you're going to kind of take with a grain of salt. If it works and you've got a system in place where you can actually do it on a regular basis, it's great. If you actually have a problem where you have an operational system that cannot go down for any length of time, I would actually skip this step. Tripwire and load check. Install and configure those to monitor for file system integrity. Install SLORT. Any other intrusion detection IDS that you have at your disposal. I like SLORT. It's free. It works. It's just what I prefer. If you want to use RISCure or something else, go for it. There aren't freeware IDS products out there that you have access to so you really don't have an excuse for not having some intrusion detection sitting on your servers. At the border, you are going to want to stop at UDP-113 and TCP-113 traffic inbound. Also, you want to block ICMP-17, that's your mask request traffic at the border. And finally, allow access through the firewall and any necessary ports on specific machines. In other words, if you have a web server, a mail server, and a DNS server sitting behind your firewall, what you want to do is allow port 25 traffic only inbound to the mail server, not port 25 traffic across the board. Same thing would go for HTTP, port 80, and port 53. Specifically to that box that way, if you for some reason skip a step, miss a step, or somebody accidentally re-enables a service on one of those machines, you have another layer of protection to keep somebody from making access to your machine on that port. Influencing the stuff that we talked about here today is not going to make you totally secure. We were talking about the other day that you have to find you're actually totally 100% secure and you know it box. It cannot be made. If there is a determined attacker out there and you are his target and he is knowledgeable, he is probably going to get you. But what you can do by doing this is taking time to reduce your script kitty thread to essentially nothing. You will also be able to, if you have an attacker that is looking for a target of convenience, you are not convenient. It's like the club. Car thieves can get the club off of your car very quickly. However, when they walk by and they see tubes sitting next to each other, one has the club, one doesn't, they steal the car without. Unless it sucks. Finally, also patches. One of the biggest problems I've seen and I mentioned it before is people not applying the patches. If you maintain patch level, you will reduce the bulk of your problems. Just by maintaining patch level and disabling unneeded services, you've probably reduced your risk by about 90%. I have a few references in here. Some of you are online, some are books. So, we're Security by Peter H. Gregory. Some press actually put that out. It was a very good book. The info that came from this can be found in that book. Unfortunately, it is Slayer 7 specific. So, that's why I had to update quite a few of the things from this book. The other thing that I wanted to do was show you the results of the ISS scans. So, that is the initial scan with essentially a default install or dummy install. If you run through this process and do all the steps when you are done, you will have, not that, this. You have four rows remaining trace route. I see if you wet mask. I see if you timestamp all of which should be blocked at your border. And open SSH running, which is more of an informational item to let you know that you have it. There is not a vulnerability actually associated with that assuming that you have your open SSH to the current patch level. I had hoped to actually get this presentation updated for Slayer 9. Unfortunately, I am not the processor system, so I had to buy this software. I didn't get it in in time to update the slides. But I did get it in and get it installed. I ran through the process on Slayer 9 with actually better results because there is no open SSH. It comes bundled with SSH now. However, I have tested everything to actually make sure that I'm not breaking anything. So, before you do this on Slayer 9, you didn't want to do it in a non-operational environment and verify that none of the steps are going to break your system. I have time. That is it. I have time for about three questions because I have to go to the road driving contest right from here. So, yeah, if you want to come up, people that want to ask questions, if you come up and use the mic so everybody can hear. Yeah, just a question about the slides. If people don't have them, they will be posted on a DEFCON site eventually. But if you want them before that, you can go to www.securitytrag.com and I will have a link off of there to the slides so that everybody can get a copy of them. Do you have a question? Hi. We see Venoma used to have software to help protect RPC services, like RPC buying and stuff. I don't know if they still work for Slayer 8 or are there any other... You can also use it in combination with TCP wrappers to help wrap our eyes and protect your RPC services. Is anything recommended for Slayer 8 or 9? Does that matter? Unfortunately, I don't really have a very good answer for you. I don't know. Explain your pros and cons of using SUDU instead of SU. Actually, SUDU I have absolutely no problem with. It essentially is doing the same thing that I'm doing with the lockdown with the groups. And thank you very much because I meant to mention that. If you want to make it a little bit easier on your admins, that is a definite way to do it. And I don't see any problem with doing it that way. If there are no other questions, I would just like to say thank you. And actually, I have a couple of questions for you guys. And those of you who have left have missed out. I've got two boxes. I'm going to ask a couple of questions from you and... What are you guys going to ask them? Are you guys going to ask questions? Are you going to give them away? Excellent. I'm getting out of your way.