Thanks a lot folks. I'm Jason Anthony Guy. I manage one of the developer technical support teams and I have the great pleasure of bringing up two people who have a lot, who spend their days worrying about security. Brian Sathianathan is part of our Emerging Technologies team and Damien Weiss is part of our Apple Consulting team and they spend their days, as I said, thinking about how to make things more secure. So if you'll help me welcome to the stage Brian Sathianathan.

Thank you, Jason. I would want to say welcome again for this section 635, Security Best Practices Using Open Source Tools. My name is Brian Sathianathan. I work for a group called Emerging Technologies. We are involved in design, architecture and security for Apple's internal IT group. And my co-presenter here is Damien Weiess. He is an Apple consulting engineer. He will be introducing himself during his presentation. And having said that, let's move to the presentation.

With the growth of the internet, more and more people are getting into the internet, businesses are getting into the internet, there's a lot of commerce done on the internet, all these different factors. have created the demand for security. To make things worse, in the past five or six years, the number of vulnerabilities that have been reported, the threats that have been reported, the virus attacks that have been reported, have almost doubled. So all these events tell us a simple story. 19 letters, three words, one idea. Security is important.

The good news here is that OS X is a secure platform. It's got Unix at its core, it's got security at its core, and it's got security at all the different levels. It also has so many different tools to enhance security. Especially as a system administrator, you could use OS X to increase the security of your platform. And especially, you could use OS X as an administrative platform to administer other machines in the network. You could use OS X to do scanning, to do detection and so many different secure activities.

What are you going to learn here? In this presentation, initially you're going to learn about some of the user level open source tools. Tools that ship default with the OS. Tools that you can use to enhance the security in your organization. How do you configure these tools? And what are some of the hardening techniques that you can apply to these tools? And also you're going to look at some of the network scanning tools. How do you use intrusion detection software? What are some of the scanning tools? What are some of the event correlation softwares? And how can you detect file changes, file system changes? File tampering and all these different activities.

And finally, you're going to see how we can use some common security libraries, which are common to all these different tools. And how we can build our own tools and get a general awareness of what's inside these security tools and so on. So it's going to be a real interesting journey.

We're gonna approach security from three different angles. There are three different areas where potential and possible security attacks can come from. From the physical side of it, from the application side, an attacker could attack your application and gain unauthorized access through your application, upload malicious code through your application, so from the application side, and also from the network side.

This section is actually added to make the presentation complete, but I'm actually going to quickly skim through this section, physical security. This is often the hardest to obtain because this involves humans, and it also involves responsibility of all the different departments in the organization. So this is actually the hardest to obtain.

No matter how secure your system is, in terms of software and hardware, if somebody gains physical access to your system, there are so many different ways that they can jeopardize the system. And I just want to highlight two things here. I want to talk about unprotected wireless networks, especially networks that aren't protected.

And people can drive around with antennas and trying to get into these networks, and attackers can use such networks as launchpads. Especially in the network that you have here at Apple, there are guys out there who are detecting and scanning. And preventing vulnerabilities as it's happening, as I speak. And the next thing I want to talk about is... Having multiple applications.

Well, having to use multiple different applications are inevitable because you need so many different applications to do your day-to-day activities. But all these applications need some form of authentication and eventually it's going to be a password. So at the end of the day, you have to remember all these different passwords and you cannot remember all of them. You're going to write them in yellow stickies, stick them somewhere, and eventually they're going to go to the trash can and get into some attacker's hand.

Or somebody who has physical access is going to get his hand on the passwords and then a compromise can happen. So it's always the best practice to move away from multiple password systems. Move on to a single sign-on system. Or move on to a system that has single sign-on and single password. Or single sign-on or a multi-factor authentication or a two-factor based authentication. system.

Compromises, as I said, will also happen at the application level. Before I go into the application level, I would like to talk about something. As I mentioned previously, OS X is a secure system. It is secure out of the box. And there are quite a few examples. And the two things that I'd like to bring here is that OS X has a real good separation between user accounts and administrative accounts. The root account is disabled by default.

And especially there is, and there are file Unix level permissions that separate you between administrative and user accounts. And with Tiger, you're going to have all the ACLs and all the great features. And in terms of network ports, OS X, Client has zero ports open. An out-of-the-box OS X client does not have any ports open. A server, of course, has six ports open, and two of which are security softwares, like SSHD on 22 and then the Kerberos port. And four of them are administrative ports.

Now we're going to look at some tools that enhance security. The reason that we are looking at these tools, these tools can help you to enhance security. These tools can provide you with authentication, can provide you with access, can also provide you with encryption, can provide you data integrity, and so on and so forth. So what we're going to do is we're going to look at some configuration and some hardening techniques by using these tools.

The first tool we're going to talk about is OpenSSL. It's ship default with the OS X. It is an open source tool. It's an open source implementation of the SSL protocol. It's a great tool to do certificate management. You can manage a certificate throughout its lifecycle. Using this tool, you can also manage a private key throughout its lifecycle.

You can use this tool to do client server-based authentication, and you can also do encryption using these tools. It has all these different encryption utilities embedded in this tool. Especially what you could do is you could actually create or generate a certificate by using OpenSSL, and then later on you can use that certificate to do both client and server authentication.

Especially when you hit an HTTPS website, your client browser encounters a server certificate. Then by looking at the installed CA in the client, it actually verifies the server certificate, and the reverse also could be done. Basically, this tool allows you to produce certificates that can be later on used to do authentication and encryption and so on and so forth.

However, at Apple, we do ship the CDSA frameworks. The CDSA frameworks are much more secure. It provides certificate management functions. It provides security services. It provides encryption services. It provides a lot of the things that OpenSSL does. And there are numerous advantages by using the CDSA frameworks. Because if you use the CDSA frameworks, you can do export control paperwork really easily. And then you can have so many other different features as far as handling private keys, public keys, and so on and so forth. And it's optimized too.

So at Apple, we strongly recommend you to use the CDSA frameworks. And if you have an old application that uses OpenSSL, that links directly to some OpenSSL libraries, it's okay to use OpenSSL. But if you are trying to build some cryptographic application or some kind of public key-based application, it's always recommended that you use the CDSA frameworks.

What we see here are some of the functions that Open SSL can do. First, generating keys. Open SSL can be used to generate private keys. It can also be used to view keys, view your private keys and also view your certificates. It can be used to create certificate signing requests.

So you basically give the private key in and then tell Open Source to create a CSR signing request, and it will give you a bunch of questions in which you need to give answers, and then it'll eventually create your signing request. You can create a CRL. In the case of verification, when the server verifies, when the client or the server verifies a certificate, it'll actually look, check across a CRL, and then you can create CRLs by using OpenSSL. And you can actually do the signing process itself by using OpenSSL, provided you are the CA or the signing or the administrator.

You can also do certificate format changing and formatting. For example, certificates are in multiple formats. You can turn them from PEM formats to DER format and so on and so forth. And then finally, you can verify. You can actually tell what role you want OpenSSL to play, and it actually will go through the different depths that you specify, to verify your certificate.

And what we have here is a typical example. In the case of web authentication, if a website wants to authenticate a client, what would the web server do? It would actually have some kind of a password username, some kind of a basic or a digest-based mechanism to authenticate the client. We could also use a certificate from the client side to really authenticate the server. So in order to do that, we actually, in this example, we modified the http.d.conf and added some configurations to it to do such an authentication.

What we did first is that we added this entry, which basically tells you which is the CA certificate to verify the client certificate with. The name of the CA certificate that will verify the client certificate with. And this section tells you the directory that you want to protect, and these are some of the SSL options that will allow you, where you tell SSL to do certain functionality for you to protect your website.

The next tool that we're going to look at is OpenSSH. OpenSSH is the open source implementation of the SSH protocol. OpenSSH is shipped default in OS X. It's a great tool. It provides you with encryption, data integrity and secure communication. It actually encrypts both your data channel as well as your command channel. So in OS X, the remote shell is actually OpenSSH. So it provides you file transfer services, it provides you secure shell services, it provides you secure copy services, it replaces all the R utilities. So we recommend you to use OpenSSH. It's a great tool.

And OpenSSH has the client as well as the server side. The client is basically the SSH or the SSH server. The client is basically the SSH server. The client is basically the SSH server. So let's look at some hardening techniques that you can use at the SSH D daemon to increase security.

The file in question here is sshd.config. And some of the changes that we're going to make here are basically we could filter connections that are incoming into the SSHD based on IP. And we could give access for incoming connections. And then something else we could do is we could also do filtering based on users.

We could only allow certain users to connect to the system. Another important thing I'd like to highlight here is that previously I mentioned to move away from password systems. So you could use some kind of a public key-based system to authenticate to SSHD, or you could even move into a system like Kerberos.

Having said that, let's move into the next section. It's IP firewalls. We said that OS X is a very secure platform out of the box. As soon as you start using all the different services, eventually you're gonna open up a lot of ports. You're gonna open up different ports and you're gonna install all your different servers. So they are gonna have a lot of ports too. So the best way, when you are in a public network, to protect yourself is by using an IP firewall. And OS X, by default, has a firewall built into it.

And if you go to the client, if you have the IP FW firewall interface in the client, this is the system preferences sharing panel. And in the server, you have it in the server admin panel. So you can enable your firewalls and protect yourself from all the attack that can happen in the public internet.

And if you are a command line kind of guy, you could actually use the IPFW utility and build your firewalls and then centrally push firewalls and do all kinds of different activities. So the IPFW utility goes like this. The IPFW, the command, Add commands or list or zero, all those things. Then the action, the protocol, the addresses, and also the externals and the source, destination, and so on and so forth. And what you see below is a list of commands that has been installed into the IPFW.

The next interesting tool that I would like to talk about is Kerberos. Previously, I mean, in the slides that came before, I was talking about, the tools that I was talking about are primarily both public key and shared key based mechanism. Now we're going to talk about Kerberos. Kerberos is primarily a shared key based mechanism. It actually gives security. It provides you with authentication and single sign-on. And Kerberos is shipped default with the OS X.

It's MIT's, to be technically correct, it's MIT's three-party key agreement protocol. So basically what it does is that it gives us single sign-on. It gives us authentication. So how does it give us single sign-on? So to understand how Kerberos gives single sign-on, we need to understand how it gives us single sign-on. There are three components in the system.

The client, the application or the application server, and the KDC. So the real problem here is that the server needs to authenticate the client. So how can the server authenticate the client? The server can authenticate the client by some sort of a trust credential provided by a trusted entity. And that trusted entity is the key distribution center, or the KDC in Kerberos. The KDC will have all the different user accounts.

And what happens is the clients and the application servers will actually have Kerberos libraries installed in them. So when somebody wants to log into Kerberos, he will log into the client Kerberos library. And as soon as a login happens, a ticket-granting ticket is given to the client. So what happens is this ticket-granting ticket is stored into the client cache.

And as long as you have a ticket-granting ticket, you can actually participate in all the other different authentication sections. For example, if you want to use an application, the user will go and click an application and the application opens up. And the application sees, okay, there's a ticket-granting ticket, because the application is sensitive of Kerberos. So it sees that there's a ticket-granting ticket, and it takes the ticket-granting ticket, presents it to the KDC, and it'll get a service ticket for that session.

As soon as you get a service ticket, the application will take a one-time token from the service ticket and present that through its custom protocol. It could also use Kerberos, but in most applications, they use their own protocol to take that token from the service ticket. It can be a GSS token, or if you're familiar with the APIs, it can be a GSS or a KRB token. And it takes the token, it presents it to the application server, and the application server verifies and gives access. And as long as you have a TGT, all the different applications can participate.

So using one TGT, using multiple different service tickets, the applications can participate in a single sign-on. The beauty here is that when a user logs in, the password never travels across the wire. And the TGT and the service tickets are actually time limited, so it increases the security.

And what we have here is the Kerberos configuration file. In OS X, it's in library preferences. It's called edu.mit.kerberos. And if you are using some sort of a directory mechanism, like if you enable Active Directory plugin, or if you enable an LDAP-based plugin, and you want to use Kerberos along with it, this file would be automatically created for you.

And if you are connecting to a different Kerberos server, like a Solaris server or something, you could create this file. So let me quickly go through this file. So each KDC belongs to a realm or a domain, just like your system, it belongs to a domain. So it belongs to a realm.

And what you see here are the realm configurations. And what you see here is the entry that tells your client Kerberos libraries where your KDC is. It'll give you the domain name of the KDC, as well as the ports of the KDC. And you can have multiple KDC entries down there. And in case of a failure, in case of the first KDC fails, it would naturally fail over to the second KDC, and so on and so forth.

In our Apple IT group, we did have the exact same problem. We had a number of applications, we had tons of them, and then we had tons of passwords to remember. So what we did is we moved on from our password scheme to a single sign-on base scheme. How did we do that? We actually used the framework that was deployed in the Western platform, the Kerberos framework, and we built a login application on top of that.

And we also added some more features on top of this application. So what did we actually add? The things that we added was we added extension based on activity. If a user is sitting actively on his terminal and having some kind of keystrokes or mouse movements, then the tickets will be renewed. The TGT that's obtained will be renewed. The TGT eventually will be taken for a shorter time and will keep on renewing it according to activity. And something else we added was selective participation. There are certain mission-critical applications.

There are certain applications which do not want to participate in single sign-on. So these applications can centrally be disabled from participating in single sign-on. Or the user can decide whether his application to participate in single sign-on or not, and so on and so forth. We also added another nice feature. It's called login slash logout hooks.

Especially if somebody is logged into the single sign-on system, and when somebody goes into the Kerberos window and signs off, it would naturally, the hooks would tell each application, will call back each application, and say, hey, I'm going to log out of this application. And they would say, look, this guy has already logged out. And the applications could take their own actions. And the vice versa is true, too. You could actually install a hook. When people log out of applications, the central login system would know about.

One of the most interesting things we did is that we added pluggable authentication to our single sign-on system. So we basically added Kerberos hardware authentication, a SAM based security authentication, module based authentication. So we could do Kerberos authentication, we could bootstrap the authentication by using a smart card.

And that was a very cool thing that we did. And what we are going to see here is a tiny demo. It's going to be actually a video demo. So what you see here is a Kerberos window. And we don't have any tickets right now. So we are going to the central application that we created. And then we are logging into the system. Oops, the caps is on. Okay, let me go back, re-tap everything.

That's a long password. So let me sign in. I'm signing into the system, and I'm also automatically signed into Kerberos. So it shows my TGT. - And I can see my TGT there, and it's time limited. It's taken for an hour. And now let me go back to, since I have the TGT, I can go back to the application and sign using the applications.

So now I'm signed in. So if I go back to Kerberos, I should see... I'm actually moving, dragging the application away. If I go back to Kerberos, I will also see my service ticket for that application. And now I'm wiping off my service ticket, and it automatically logged me off the application. If I try to sign in again, it'll actually prompt me my login window.

So you also can actually use the existing Kerberos framework and start building single sign-on systems. It's really easy to do, and it's real powerful, and it's really good. And having said that, let's move on to the next section. It's the keychains. Well, in the OS X, the keychain is the default central repository for all passwords and all secrets.

So you could store passwords as well as certificates and all these different things in the keychain. And especially if you want OS X native applications like Safari and the CF framework and all these different components to really recognize your certificates, you need to install them into the keychains. You have to install them into the anchors file.

So we have seen all the basic tools. Now let's see what else can be done. So I'm going to toss it on to Damien to lead us from here. Damien, here you go. Thank you, Brian. My name's Damien Weiss. I work for the Apple Enterprise Consulting Group, dealing with deployment and integration issues. And I spend most of my time, most of my focus on security issues.

Going to talk about what else can be done. We're gonna talk about password policies, scanning, file system changes and network intrusion detection. Let's talk about password policies. You know, passwords are the main gate into your machine. They are the easiest way in and, if you make them so, the hardest way in.

I have a friend of mine who aspires to be a screenwriter and he loves to say all the time, he loves to say, you know, if you had a thousand monkeys and a thousand typewriters typing for a thousand years, they'd eventually turn out the screenplay for The Godfather. He also likes to say that if they give him a day, they would turn out the screenplay for Titanic and the monkeys would have enough time to smoke a couple of cigarettes afterwards.

And that aside, I see a lot of folks when I go on site, I see a lot of folks who have the Titanic of passwords. Their password policies are very lax and indeed I'll ask them, I'll say, well, you know, what's your password or, you know, what's this user's password? And they'll tell me and generally it's the username plus a number, which is the first thing, of course, people scan for. You know, what do we do at Apple? We're not here to help you guys out.

by actually implementing it into Open Directory. And there's a mistake up here on the screen, where it says work group manager. That's supposed to say server admin. So if you go to server admin, then to the Open Directory tab, you'll actually see there, you can set a number of things. You can set password policies, such as whether or not the user can have a password, with their name in it, or whether or not they have to have numbers, or anything along those lines.

Also, password generators are great to use. There's hundreds of them out there. If you go to Google and search for simply password generator, at least 100 will pop up. My two favorite, personally, are those that go ahead and generate passwords that are not in the dictionary, but nevertheless sound like normal English words. Indeed, what you find is that they're words that sound like words that you would use every day, but grossly misspelled.

Also, are those password generators that generate passwords, that are easy to type, but are just an amalgam of letters, and numbers, and punctuation marks? Finally, administrator password policies. You know, I remember the first time as a system administrator I was actually working at the defense department at DISA. And the administrator, the root password for 35 Next Step machines was simply DISA and then the name of that computer.

And that's what it was when I first arrived. And needless to say, about 15 years later, things don't seem to change at clients. Part of the problem is too many machines to remember the root password, administrator password for. I would strongly suggest that each password be unique. Don't try to go ahead and make the mistake of setting up the administrator password based on the company name or your manager's name or anything along those lines. Because you really need to protect yourself, especially on the admin password, from both external attacks but also internal attacks. The guy three cubes down knows what your manager's name is. We're going to talk about network scanning and monitoring, and we're going to talk about these tools.

But first, you know, these tools really generate a lot of output and the real goal is to go ahead and essentially break into your network and find the weaknesses for you. And a lot of folks for some reason seem to think a good idea is just to leave the results of this on the hard drive just somewhere unencrypted or world readable. Please secure them. My favorite technique is to actually use one of those USB,

Folks have an easy way of plugging in a computer and then hiding it from you in order to listen to all the traffic on the network.

Let's talk about Nessus. Nessus is a great utility. It goes ahead and does more than obviously Nmap. It goes ahead and performs scans. It looks and actively sweeps the network based on plugins that you've given it. So, for instance, database plugins or plugins There we go, sorry about that.

It goes ahead and has plug-ins for a number of operating systems and a number of protocols and services, allows you to go ahead and specify exactly what it is that you're scanning for. And those results are very good. You can go ahead and rescan over and over and over again. I have a client who actually runs Nessus day and night, specifically just looking for new stuff and new vulnerabilities out there on the network.

OSM really straddles the line between scanning and monitoring and intrusion detection, which we're going to get to later on here. But I really wanted to stick it here in the scanning and monitoring. It really is sort of the overlord, if you want to think of it that way, of security utilities.

It gathers information from everywhere, from log files, from scans, from anything and everything that it can possibly find. And its goal is to bring that all together in one place. But more importantly, to bring it together in one place so it gets a better read on the network, so as to eliminate any false positives, excuse me, any false negatives of intrusion detection on your network.

What else can you do? Well, you can also scan the file system. What I mean by that is scanning the file system is simply going The first step is to look at each file and save it. It allows you to know when changes have been made. Why do you want to do that? When a break-in happens, the evidence of the break-in and the attempt at a break-in is generally found somewhere on the file system.

Also, after a break-in has happened, any back doors that are left on the machine are definitely found somewhere within that file system. Knowing about a break-in after it happens, very soon after it happens, helps to prevent further break-ins. You can see that the first machine to go is generally the beachhead, and then from there, because all the machines are generally trusting of each other on some level or another, or in the case of most machines, you know, all the administrator passwords are the same, it allows the ease of breaking into further machines. So you really want to stop that as quickly as possible.

I'm going to talk about a couple of tools that allow you to scan, Tripwire and Radmine. First is Tripwire. Tripwire is great for locking down one machine, even if it's not on the network. It goes ahead and just like I said, it does a checksum on every single file on your network, excuse me, on that one machine.

And it goes ahead and detects any changes. So you run it every night at 1:00 in the morning or whenever, and it will go ahead and tell you what files have been changed. There's a lot of files that change every day, obviously log files, those kind of things, UTEM, WTEM files, those things change normally. But what you're looking for obviously changes in files and in directories that shouldn't be changing at all.

A good thing to look here is SUID bits. SUID bits that have been changed or added to files. An old popular way of backdoor, an old popular backdoor was to go ahead and find an SUID file or actually create an SUID file depending on what kind of access the cracker had to the machine and copy in shell, seashell, any shell file into that container of a file and thus granting you an SUID shell file.

Radmine. You know, Radmine won one of the design awards for last year's WWDC. It's a great utility. If you guys haven't looked at it, I encourage you strongly to take a look. It's really a client-server tripwire is the best way I know to describe it. The first thing that you would do is you'd first configure your Radmine server to take the load sets, which are those checksum files, and go ahead then and go to each one of the clients or use ARD, for that matter, to run the assistant to go ahead and create those load sets. At that point, you can go ahead and automatically check for any changes and even possibly roll back any changes.

I'm going to talk about network intrusion detection and why you want to do that. Well, as the slide says, very simply, another pair of eyes never hurts. And in this case, multiple sets of eyes never hurt. And also, machines never sleep. And I have noticed that it seems that crackers seem to work best or at the very least most frequently from about 10 o'clock to about 4 o'clock in the morning. And that's generally the time when I am dead asleep.

Snort, you know, it is a big mouthful. I've been practicing this slide over the last week and every time I get to the sentence I'm always just blown away. Snort uses user defined preprocessors and rulesets to detect suspicious packets. And what that means is, sounds like someone applauded for that.

I didn't know that people were in doubt of my literacy, but who knew? No, I'm sorry. It uses rulesets to detect suspicious packets. And what that means is there's a number of rulesets that run within Snort. And what it does is it uses

Written like this. First you have an action, which in this case is alert, I have in this example. And the next one is the protocol, which will be TCP.

The source address is any and the port address is any. Now what I've gone ahead and done is I'm going to set up this rule for detecting any Mount D access from anywhere to my local network. So I've got my destination address which is the 192.168 with a net mask of 24.

Port number 111, which is the mountd port, and the actual specific content, which is within that packet, which is saying, hey, look, this is a mountd packet. And it will actually go ahead and what actually needs to happen, well, we're going to go ahead and message to Snort Log that mountd access has happened.

Pre-processors. Pre-processors run before the rule sets. They allow for packet modification analysis before handing it off to that detection engine or those rule sets. And so what that means is that, you know, it's those things, the pre-processors run before the rule sets. If you have certain packets that you don't want to be detected or if you're getting a lot of false negatives on specific type of packets or from one specific machine, the place to go ahead and exempt those packets is there in the pre-processors. Go ahead and specify them in the configuration file just like we have up here.

The output modules, you know, the output modules are simply just telling SnoRT where to send the rule set and preprocessor information. So, you know, as a packet comes in, goes through the rule sets, where does SnoRT, or where is SnoRT supposed to write that information to? And that's where the output modules come into play. I know some clients like to go ahead and specify all the output, just go into one huge hunking file. And others like to go ahead and break it up very, very small.

We've talked about what else you should do, and now I'm going to talk about what you shouldn't do. Please don't enable the R utilities. R Shell, R Copy, etc. I have been guilty of doing this in the past. However, the models have changed now. We actually have alternatives to each one of these utilities. While the utilities themselves specifically are not secure, in order to go ahead and get them up and running, you have to go ahead and open up security holes. Telnet, there's a great alternative Brian went ahead and talked about, Secure Shell. And Finger.

I've noticed, the first time I was introduced to Unix, the first thing I was actually introduced to was Finger. And I thought this was earth shattering, that you could go ahead and actually stick your status in somewhere and people could actually read it. This was the greatest thing since sliced bread. Obviously, all the functionality of Finger has now been replaced by AIM or by personal web pages. Also, try not to use non-SSL mail protocols.

I love to go to client sites, set up my PowerBook, let it scan for an hour, and then show the clients all the mail passwords and usernames that I've gone ahead and harvested just by listening to their network. It usually brings a little bit of unease, but then they realize, "Hey, we need to do something about this." And that's what I enjoy, is actually fixing those problems. FTP, use SFTP or Secure Shell.

While limited use of TFTP isn't inherently insecure, you see a lot of times folks trying to extend TFTP beyond what it was designed to do and thus making it insecure. And finally, non-open directory based authentication. There's a lot of problems that we see outside of open directory and I would encourage you not to enable it. So with that, I'm going to go ahead and invite Brian back on up here and he'll talk to you about writing your own tools. Goodbye.

Thanks, Damien. That was wonderful. We saw a great list of all these different open source tools and how you can take advantage of them to do scanning, intuition detection, correlation and all these different things. Especially as an administrator, one of the things that you really need to know is when you use all these tools, what is inside these tools? And to get a general awareness, you have to know what are the components of these tools. So I'm going to talk to you about some of the network components or some of the libraries these tools are constructed with.

And most of them are open source libraries. And the first library that I'm going to talk about is libpcap. libpcap is default in OS X. It's a packet capturing library. It listens on the wire and it can capture both Ethernet, TCP, IP and all these different types of packets.

And any sort of application like tcpdump would actually use libpcap. And a lot of the different tools actually use libpcap. All the different open source tools, they actually use libpcap to do the packet capturing. Later on, I'm going to show you a program that I've written using libpcap.

It's a great library. The next library is libnet. Libnet is a packet injection/packet creation library. So you can use libnet to create weird TCP packets, I would say. Or packets with different types of packets. Or packets with different headers and all this different stuff. So it's a great utility and a lot of the intrusion detection tools and even SNORT uses libnet. Libnet is actually a low level tool. If you are building all these different open source libraries, you have to build libnet first in order to build all the other libraries.

Libdnet is an abstraction library which provides you abstracted data, abstracted kernel data, like the interface information, like the ARP cache and also the routing table. So you can have direct access to the routing table by using the Libdnet. And a lot of the security tools and applications does, in fact, use Libdnet. And the next tool is, the next library, I keep on saying tool for libraries.

The next library is LibSF. LibSF is an OS fingerprinting library. So by using LibSF, you can detect what your destination OS is, what OS you are pinging on. So basically LibSF can work on active as well as passive modes. And what it does is it has a database on how the kernel responds to certain packets.

And depending on the feedback it receives, it can also send you a message that says, hey, I'm using Libdnet. And it actually gives scores. And the system that gets the highest score is most likely to be the system that's in the destination. So it's a great library you can use in your tools. And the next library is LibNIDS. LibNIDS is a TCP fragmentation and assembly detection library. Most of the intrusion detection tools actually use LibNIDS.

Tools like LNIDS and NIDS and I guess DSNIF, all these tools are used in LibNIDS. But you can actually register a callback function into LibNIDS. When LibNIDS encounters a fragmented IP packet, it will actually call you back. So it has great functionality. The reason, as I said before, why am I talking about all these different libraries? I'm talking about these different libraries because it gives you a general awareness of what your tools are made of.

Second, it gives you, if you are a developer, it gives you the ability to code and write up a tiny tool. Because most of the time, you're not going to be able to code. So most of the security tools that we have, they do a specific purpose. They are for a specific purpose. And if you might have a purpose that's different from the tool's purpose, so you can actually quickly write up some tool of your own by using some of these libraries.

And having said that... Let's move on to see how you can write your tool. I, in fact, wrote up a small program, 100 lines of code within less than an hour. It's very easy. I call it the Browse Program, and there are actually programs like this in the open source arena.

What this does is actually it uses libpcap, listens on your wire, captures IP packets, and then it strips off Mac addresses from the packets, and if it finds a new Mac address, it stores it in an array, and then it resolves the Mac address to a vendor name. So basically it browses the network and finds out all these devices and which vendor it belongs to. You could actually easily extend this program, put libsf in it, and you could actually do fingerprinting.

So it's a very tiny program, and what you see here is the output of the program. You see I ran it in my home network, and you see the Mac addresses, the IPs, and the vendor names. So these tools will really allow you to write up these libraries. The knowledge of these libraries will allow you to write up tools and increase security in your network. Now in conclusion... Take advantage of all the tools that we showed you.

They are great tools and also use OS X as an administrative platform to run all these tools and secure your network. And here, what you see are some of the different URLs for these tools. Tools like Nessus, Nmap, Radmind and the Libnet libraries. Some of the tools, the rest of them, they actually come in the OS X.