 Hello, everyone. And first off, I want to thank you for coming out this early on Sunday morning, especially since many of you have been engaged in quite a bit of drinking here today and many days here prior at DEF CON. So thank you for coming out, making it out this early. A little louder. Is that better? Okay. All right, so today's talk is port scanning without sending packets. My name is Gregory Pickett with Hellfire Security. This is a short overview of the talk today. We'll start with how this all got started or how I ran across this, followed by it's really not a magic trick. It is actually pretty straightforward. Next is loose slips, sink ships, because ultimately it is what is advertised on the network that allows us to do what we're going to do today. And that next is catch me if you can. And finally we're going to go back to the future or how to ultimately mitigate this risk in an enterprise. Okay. So we'll start with suppose you have this guy on your network. You really don't know what you're going to get, right? And this guy is involved in some suspicious, possibly malicious activity on your network. How do you identify him? As an intrusion analyst, I have a three-step process in approaching events, characterizing the activity, profiling the hosts involved and using that to make a determination as well as to select next steps. When profiling, it is important for me to be able to identify my source and that often begins with a host name. Names are one way to quickly categorize a host as an asset or an intruder and can often lead to an easy identification of the source. For the most part, Windows hosts are rather easy. I just run NBT stat against the host and utilize, you know, the NB, or the name service to get a host name. But what about Linux? And what about Apple computers? And there are a whole lot more out there, different types of hosts like printers and a whole variety of different networking appliances. So this is the problem that I had as an analyst and the question that I was looking to answer. Okay. Now, when I began to look for my answer, as an intrusion analyst, I'm looking at the network quite a bit and I was examining the traffic that was flowing to my interface and I saw quite a bit of multicast that I was not familiar with. Now, the interesting thing about this multicast was that there was a tremendous amount of name information and I was very excited, of course, because this was something that looked like it might be an answer to the problem that I was having. So I went ahead and did a little research on this multicast and this is what I found. It was multicast DNS. And the purpose of multicast DNS is peer-to-peer name resolution. It does have a history. Multicast DNS is the successor to Apple Talk name binding protocol and it was eventually added to Apple's zero configuration networking initiative. Now, in addition to multicast DNS being part of this initiative, there was also an addition by Apple of DNS SD via multicast or DNS service discovery via multicast to the initiative to allow for peer-to-peer service discovery in addition to the name resolution. So you can begin to see how this is going to look. The features, well, it is DNS just running over multicast. Each host participating in multicast DNS maintains its own local domain and queries and responses are sent to the multicast address over UDP port 5353 so that all participating hosts can answer queries sent and all participating hosts can update their DNS cache with the responses that are returned. Everyone is aware of the resolution that other ones are making. They are able to update their cache so that they don't have to duplicate that sort of activity. So you see a lot of flow of information, a lot of questions being asked and answered over the multicast. Now, there are a few basic operations that these hosts engage in and this is important when we take a look a little bit about how this information flows over the network later on. First off, there's the probe. The probe basically is a situation in which there is a record that this host is going to contain and it wants to establish this as a unique record. So it goes ahead and probes the network very much like a Eucratiotus ARP to make sure that this host, this record is actually going to be unique. Followed up by an announcement to let everyone on the local community, those participating in the multicast DNS community that these are the records that I'm going to be holding and these are going to be the unique records as well as any shared records. Shared records are very special. They are something we're going to be looking at a little bit more later on and what we do rely on. So once it's done this announcement, it then engages in the querying and responding to queries. There's some information there. You take a look at that later. These are basically specific properties about that activity to identify these sorts of operations. And finally, there is a goodbye. In the multicast DNS, there are unique as well as shared records. With unique records, not unlike traditional DNS, there is a time to live so that if it's a unique record and the time to live expires, everyone realizes this is no longer valid and they dump the record. However, if you have a community where multiple hosts are sharing or all have this record contained on their host, would it expire if one member decides to no longer participate? Well, it would not because you have a lot of other hosts that are maintaining that record, that shared record. So you want to make sure you say goodbye so that the hosts out there know that you will no longer be responding for this record, no longer be responding to queries for this record. So it's been a way to drop out when you are sharing records with others. All right. I want to take a look quickly at some implementations of multicast DNS and this is important. Let me look at some things later on. First off, it was all started by Apple, of course. People who are with RFC are from Apple, but it was picked up by Avahi and you find this service available as developed by Avahi in a great number of Linux distributions now. And then more surprising than that is actually there are a tremendous amount of implementations on networking appliances. I believe even TiVo is running this. So TiVo, you have network attached storage cameras, any number of multimedia devices, printers, everything seems to be loaded with this now. Okay. Now, these are just a little example of, I'm not going to talk about this really, but just looking at the records that are utilized, are being on these hosts, these are names for the hosts, and also, you know, services, service records, service records to be utilized in the DNS service discovery. Okay. Also, in addition, there is text record, unlike traditional DNS, a service record in multicast DNS is paired with a text record to give some information about how that service is configured for any host that wishes to utilize that service. They can look at that record and know exactly what they'll be dealing with. And then there is the HINFO record, also utilized in multicast DNS. Okay. Now, before I move on, it is important to provide some additional information regarding DNS service discovery, as it is very important to what I'm about to show you. Hosts participating in multicast DNS are often participating in DNS service discovery as well. And this is a little bit about what these hosts are doing and what we'll take advantage of later on. First off, DNS service discovery is not unique to multicast DNS. It works over standard and multicast DNS. However, when it operates over multicast DNS, it is fully compliant. It is involved in continuous querying because if a user wants to utilize or a piece of software wants to utilize one of the services available out there, it wants to make sure that the list that it has to select from is fresh and is valid. So it's always going to constantly be querying and collecting responses in order to make sure that that list is valid. Now, it's important to keep in mind when you're dealing with multicast DNS of shared records. Because shared records in DNS service discovery are basically you have a situation in which, let's say you have a community of hosts participating in multicast DNS and also DNS service discovery. And of those, let's say you have five that offer FTP services. Those five will actually share the pointer record for the FTP service. So when this pointer record, when someone actually queries the community for that point record, these hosts, these five hosts will return a response to that query with a pointer pointing back, though, not, you know, the shared record pointing back, though, in each instance to their own deployment of it. So each host will point back to their particular instance so that the software or the user making the selection can then, you know, have the records available or can go get the records available to utilize any particular service that they decide that they want to use out of the ones that return a response. Okay. So these pointer records will share among those five point back to unique service and text records that each host will then have to make available so that you figure out about that service and utilize it. Okay. All right. So when I saw this, I was pretty excited. You know, I had an additional way to profile my host quickly, like I was able to do with Windows hosts. And so I created a tool called MDNUS host name, the parameter there. It does a reverse lookup of the IPv4 address. I did repurpose some code that was designed for traditional or conventional DNS. So it basically just does packages the same message but sends it to UDP port 5353. So operate using a basically unicast legacy query to UDP port 5353 of the target. In addition, while I was looking through these records that I was seeing over, you know, being advertised or multicast, I saw a lot of other information types of records. And I began to identify some unique things about these hosts that were responding and, you know, delivering these records over the local network. So I said, well, let's go ahead and make a tool to take a look at those records so I can maybe, once I get the host name, I can go ahead and find out a little bit more about those, continue the profiling. So I made a MDNUS lookup. There's the parameters there. Now it's important to realize that it submits the question as given. If you fat finger it or screw it up, you're out of luck. So if you don't get an answer, especially in situations when you were expecting an answer, go ahead and re-evaluate that to make sure that your question is correct. And it also operates using unicast legacy query to UDP port 5353 of the target. I'm going to go ahead and do a demonstration of that real quick. I have a host here. Oops. That was weird. All right. So I'm going to start off by asking this host. Let's say this is one of the suspicious hosts that I'm investigating. I'm going to ask it its name. And there it goes. Return the name pretty quickly. And apparently its name is Ubuntu. I'm guessing you know what operating system that is. There's a lot of information in the name. So let's go ahead and take a look at the host. Let's say that you, okay, you may suspect it's a Linux box, but maybe you don't. Maybe it's some kind of generic name like Bob's computer. All right. So you want to maybe explore all the records that this will respond to to get a better idea of what you're dealing with. The same target. I'm going to go ahead and ask it if it's running the workstation service using the pointer record or that service. And I'm going to make sure that it knows that I want the pointer. Okay. There we go. You return the pointer record. It also returns several other records. Multicast DNS is very well conserved bandwidth. And when it's packaged a couple of additional records in there that it may, that it thinks that I may want later. So why is it given to me now in the same packet? It's giving me most likely the service and the text records to go along with it so that once I point to that unique instance, you know, I might ask for those records. It's going to get ahead and giving them to me now. The blank one is most likely NSEC. And that's because I didn't write any code to parse NSEC. So if it's blank, it's probably NSEC. And then finally it went ahead and gave me the A record as well. So I can follow up and then, you know, directly address the service on that port. Okay. So quickly, you know, we went over this and I was, of course, when I did all of this, I was very excited because Windows Boxes, of course, is a lot out there, but there's a lot that are not Windows. And so this allowed me to address a gap that I had. Okay. But I had a question for myself here. I said, isn't this just flowing my interface on its own? I never joined any groups. I never sent any packets on anybody saying, you know, add me to this group, the local router, add me to this group. So I said, okay, you know, I could really, you know, do some cool things with this, all this information flowing to me. All right. But what could I do? I also have a background as a penetration tester. So for me, this was great information gathering. All right. If there is a host advertised in any sort of information, speaking at all on this multi-cance address, I immediately knew that, of course, it was live. Okay. And if there were any hosts out there that were responding to queries for services, I could pretty much write down, okay, that host says he has FTP. I'm going to take him at his word. Got FTP. This guy says he's got FTP. Great. So I can take all this information and I can pretty much record it. And in essence, do a port scan. And that's what we'll be doing in just a minute. All right. But there are some requirements. You must have active responders. Someone has to be offering out there. Someone's going to have services available. You also must be connected to the same switch as other resolvers. Someone's got the author asking. But if you must, you can join the group. And of course, it works best on a busy network because you need hosts out there asking a lot of questions so that you can collect the most answers. Okay. So first cool thing. Host discovery. I'm all excited. I want to use this on the network. I want to see what's out there. What's advertising. So the other parameters. And like any good discovery tool, you are able to give this utility a range that you're interested in. It reports on any host communicating to the multicast address for multicast DNS. It does not join the group, but it does have the option. So let's do a quick demonstration of that. I believe my traffic is still playing. I started some traffic at the beginning. Originally I had some traffic that I recorded from a very large enterprise network to the fortune groups there. I want to say which group. But so I recorded that. But then I went ahead and listened on the hotels wired network with my tools and lit them up. So I went ahead and recorded, well a crap load of, I can say that, of packets off that network. And I'm going to replay that. I actually have been replaying that. So let's go ahead and run this first tool, MDNS discovery. There you go. Now this is being played back. So the rate of discovery is artificial. You do not have control when you're actually using it live on who's asking questions, when they ask questions and who responds. So it can be very erratic, very irregular flow. But you can see there are a lot of hosts out there, weren't there? At this hotel. Advertising, here I am, you know, here I am, come get me. Is the sound still good? Okay. The end result, of course, is completely silent passive host discovery. And the network guy is very unhappy. Very unhappy. Okay. But wait. There is more. Second cool thing. Port scanning. Okay. The gym host performing, in essence, port scans, or actually you're asking one question for one service, it's more like a service discovery, with one packet. Couldn't I perform a port scan with no packets? Just listening. And that's right. So multicast DNS, also running DNS service discovery is two products. Two products in one. Is it magic? Nope. It's Apple's zero configuration networking. Thank you, Apple. So let's do this. DNS service discovery occurs continuously over the network. You want to make sure for the user or for the software itself wants to make sure that that list is fresh. So it's continually discovering this information out there, making sure that this is fresh for the software for the user. So listen for it. Over multicast DNS, you know, the DNS service discovery traffic, don't rely on known service records. It's a very long list. It's too limiting. When a host responds to a discovery request, report all of the SRV or service record ports in its replies as ports open on that host. Okay. So I'm still excited. And coding late into the night can create a DNS scan like any good port scanning tool. It allows you to select a range that you're interested in, as well as any particular service ports that you're interested in. Currently over 22 services, I shouldn't say currently 22 services over 18 ports have been identified using this method. Many more possible, as I said, based on that exhaustive list that they have for DNS service discovery. There's one of the links that I have that on refers you to that list of all the different services out there that are supposedly available somewhere. And findable, using DNS service discovery. Now this tool does not join the group either. Let's do a quick demonstration. And our good friend is the hotel here. I'm going to go ahead and leave it open. There we go. This is, once again, an artificial flow rate. But you can see that there's quite a bit out there. Okay. Now I'm going to go ahead and show you one more. I'm going to stop this real quick. And show you a demonstration that I recorded. Because traditionally when you talk about penetration testing, you're talking about hacking in general, this is not the progression. I should say there is a certain progression you take in that process. And so I decided to go ahead and take these tools and utilize them in that process. So I utilize them basically in a typical penetration testing scenario. So I decided to go ahead and leave it open there, run mdns discovery to see what hosts are out there. Basically just to get an idea of what I have to work with. Who is advertising out there? Once again, come get me. And you can take a look at that list. And there's not a lot of information, but I think that ultimately what you want to do is find out who is the most active. Because it's very likely that they have the most services out there. Okay. So you go through that list and when you come across one that interests you, either you're just randomly picking it out or because it's just got a lot of communication flowing over the multicast address, which hopefully translates or means there's a lot of services available. You can go ahead and stop that and stop that right here. And now that's a real flow there. So you saw live how quickly these hosts are communicating and advertising and how much they're advertising to you. So I'm going to go into a scan and I'm going to target that host, but leave open the ports. Because I kind of want to know all what's available. And this takes a little bit of time though. Because I'm once again relying on someone to be asking the question out there so I can hear the answer. There we go. Nope. Not yet. I'm actually going to be stopping this halfway through because I'm able to actually compromise a host. Realizing these tools. Very ninja. You know, go in there very quickly. And since there was no active flows from me, I was able to get in there pretty quickly and take the host. And actually, at a certain point, there is a lot of information revealed. That pretty much opens up the rest of the network for me. And I want to stop the demo before you guys see that. All right, so we've got FTP, HTTP. Ooh, one of my favorites, Telnet. We'll let it keep going there. Because maybe we can get a better idea of what type of host it is by the ports that are open. Waiting. There we go. 631, I believe is IPP. Could be wrong. I always get those mixed up. So it's possibly a printer then. 515, LPR, I believe. I'm looking a lot more like a printer. Did anyone here see the presentation on using the multi-function printers to own the network? Yeah. This is beginning to look a lot like that. 9100, PDL data stream. Pretty sure this is a printer. So I'm going to go and try some of those services to see if I'm able to get in. And I'm pretty cheeky. So I'm going to actually use root with the hell. Let's draw it out there and see if I'm able to get in. Ooh, what do you know? I'm able to get in with no password. Someone has not set the password on this. Printer. Wasn't telling that open? It was. Wow. And what it tells me. It kind of already knew it was not set the password. But there it is. And it gives you a couple of things to start with there. The commands and then of course, what do you know? Dump the config. You probably didn't see that. It was rather fast. I'm going to go and stop that right now. And that is because after I saw all the commands, just to get an idea of what I could do with the box. I like to play with these things. Then I would end up the config. And what I ended up seeing was the SNMP community strings. Read and write. So one host as it does in many compromises gave me hundreds based on the advertising that I was seeing and some other observation that I was doing earlier. And this is why many compromises, many compromises, no matter how minor it can ultimately be devastating. How one host let unsecured because no one really cared much about it and thought it was insignificant can lead to a host that is significant. Okay? Very important. All right. Let's go ahead and continue here. Demonstration. And I wanted quickly to take a look at comparing the inactive scan versus this type of passive scan. This is what our sensors see in a typical active scan. It's our end map user there. It lights the IPS up like a Christmas tree. This is not even all of the signatures that fired. And what do our network sensors see? There's me there. During this passive scan. They see absolutely nothing. Okay? So what does this mean? Completely silent passive board scans. They're a security guy. They are still very unhappy. Okay? Now the reason why of course that this is not picked up is because any traffic flowing from your host would be very customary and wouldn't set you apart from others on the network. Assuming you're not doing anything else. You know, that would send anything off if you're just doing typical web browsing. Which is of course ultimately just a DNS query and you know, some HTTP traffic. So it wouldn't appear suspicious or malicious in any way. And you know, if you're not exhibiting any sort of attack behavior, then of course it would not trigger any alarms. All right? And this does not do that. Now this does not get everything out there. All right? But we'll get you some of the most vulnerable hosts. Because if they did not take the time to turn off or very least sanitize multicast DNS and the service discovery happening over it using DNS SD, then probably they didn't take the time to harden them. And we actually saw an example right there. And I'll have you know that I was able to repeat the example over and over and over again. You know, without of course those SNMP community strings. All right? Okay. So as I said to myself, there was a lot more goodies, weren't there? All right. So what else could I do? Well, first off we know from before that there are unique implementations. All right? If you look a little bit more at what's being advertised, you realize there are unique records. Meaning that different device categories contain different records that are unique to that particular device type. Printers would have those printer records. All right? Dealing or dealing with, you know, printer services 515, 631 and 9100. But if you look even further, you realize there are unique sets. So that not only are you going to find a unique type of record on a device type, you are going to find actually a particular set that you will find only on a particular device type made by a particular manufacturer. So could this be used to fingerprint the host? Yes. Yes, it could. If you have services, DNS, SD, UDP local and you have workstation TCP local and in particular the service record, then you're pretty much done with a Linux box. If you have the services, DNS, SD, UDP local, AFP over TCP, TCP local and that's the service and text record, you know, on that host. And as well as device info, TCP local, text record. And guess what? You probably have an Apple host. Printers. Printers will have IPP, printer and one of the three. And I find in particular that HP, those HP direct cards, have all three. Now if you have Black Armor 4D info, the UDP local, Black Armor 4D config, TCP local, service and text records, you're not only dealing with a network attached storage or NAS, but you're also dealing with one specifically from Seagate. IP cameras. If you have a host with the excess video, TCP local service record on it, you're pretty much done with an IP camera and you're dealing with an excess IP camera. They're very specific in that name. All right. But there's actually a little bit more because we talked a little bit about DNS service discovery earlier. And in DNS service discovery, there is that service record, which is, you know, not unique to multicast DNS and DNS service discovery over or via multicast DNS. There's also the text record, which always accompanies it. And that's very particular to multicast DNS service discovery. So not only do unique record sets allow you to fingerprint participating hosts, but information in these record sets, specifically the text records, deliver configuration information to you. And here are some examples. We have a Linux box there in the text record for the workstation service. You have some information there, not a lot, but it does confirm that we're dealing with an avahi implementation of multicast DNS on the Apple computer there in the device info text record. There is, if you look right down in the, what says model right there, it tells me exactly what model of Apple this is. This is a MacBook Pro 6.2. In the text record for those printer, sorry the text record for any of those printer services, it gives you the engine, it gives you the make model and version of the printer, it gives you the admin URL. They were nice enough to also give me the building it was in and the user was next to. Can anyone say social engineering? All right, so that's the printer. And then for the Black Armor 40 info records, the text record that goes with that particular service record you get not only the device model and the vendor, what we already knew was C8 from their unique record set offered, but it confirms it here. You also get the web UI protocol and the web UI port. Thank you very much. So, some day I wanted to create an mdns fingerprint, build a database of identifying record sets, collect all information records and organize by host. Match against the database and then extract the configuration information so that can return the identity and configuration information for each host to the user of that tool. Okay. But there are some limitations. Multicast, routers between the recipient and the source must be multicast enabled. Not such a big limitation after all because this is most effective on your local network. You're not really looking to go too far. You're looking to basically burn and pillage your neighbors there. You're not real worried about the router getting in the way. Mdns has some limitations as well. If you're talking about just querying, if you're just trying to get that name, you're just trying to ask what records it has or see if it has a particular record, you are only going to get link local responses and that's actually something that's designed into the protocol itself. And if you're talking about listening, which is where the real fun is at, you are limited by the layer two boundaries, the broadcast domain as well as the layer two broadcast domain as well as any view then containment that they've implemented. Our next step of course is to take a look at controls that are out there already and what they see. Can they handle this? Can they cope with this? First off, we already know that intrusion detection prevention systems don't do anything in this particular case. They don't see anything. Either ape is not going to really, well it won't do anything for you because there are no sinks. There is no single host where all the traffic is flowing through to show up on that graph that either shows for you or gives you. And of course there are no unusual flows to be picked up by NetFlow or StealthWatch. There's no surge in traffic to your host. There's no unusual amount of traffic to your host. There is no traditional type of worm activity where one host scans a whole bunch of them and then one of those hosts there are no unusual flows. Your flows look like everyone else's flow out there, so it's not going to help you any. So ultimately, do they detect anything? No. They do not. I've tried this of course. I wanted to make sure I did it before I came here because if I was wrong, I'm sure one of you out there would tell me right away. So let's take a look next at some defenses. Okay, so maybe we can't see it. Can we really stop it? Can it be stopped or will it be stopped? Well, we'll talk about the hosts first. Antivirus, antispirer, antispam. Well, the threat is really not on the host. So there's nothing there for it to see. The firewall and port blocking. There is some option there. You can port block on the host 5353. But the thing is there are a lot of hosts out there that are unmanaged. All right, I know. You wish they all were, but they're not. People bring machines in. Either they're machines that the company's purchased, but no one's decided to inventory. No one's decided to add to the system. They just cook them up there. We're only going to use it for a little while, right? And it's there for three years. And then of course there are a lot of devices out there that don't have any user protection. So, you know, you have that gap there. So while it can limit your exposure a little bit, it's just not a good choice. And then you really ultimately don't know what you're going to break when you start implementing this sort of things. And of course the intrusion prevention system doesn't help you any. And application control, device control and others aren't really just relevant in this case. All right. So do these help any? No, they do not help. All right. So we then look at, you know, what is tradition thought of, you know, your defense on the network here. Well, we're talking about listening on your your local network and firewalls separate zones of trust. I'm operating within a zone of trust. So they would not be involved, really, you know. Network access control, well, traditionally the first gen network access control is going to make sure that I'm patched and that I have an antivirus before I do all this to you, to them, which is nice of it. It's very interested in my well-being. But it's not going to help you any here. Access control list, there's a possibility there. There is a good possibility there. But I think that access control is probably not the best solution for this. But if you have nothing else, you can do that. But you do have to keep in mind what do you break out there. And of course VLANs. VLANs are great. You can see the problem a little bit by walling off your servers from your end-user community. But a lot of what is advertising out there is devices in the end-user community. So you really don't really solve the problem. You do limit it somewhat. The damage somewhat. But you really don't fully address it. So how about these? Not really. Not really. Some coverage there, but really not enough. What can we do then? Well, first off, we want to work with IGNP. Implement IGNP snooping. Make me join the group. Make me notify myself or announce myself in some way out there that make me announce that I'm going to be listening and I'm participating. And if you can, authenticate group membership using IGNP if it is available. So that only valid or authorized listeners are out there participating and of course are resolvers. And also if you can track members. This is actually a lot harder to do. I looked for some management applications out there that maybe would be able to help report on the memberships in these groups. But there wasn't really anything I saw that was very easy. You had to basically go out to the routers and get a manual list there, maybe run a script something like that to retrieve it. But track the members so that you do know who's participating and you're aware of what you have out there. And now as far as multicast DNS is concerned, the first one was basically to deal with people listening out there on the network. But how do you deal with people who are advertising? I think it's important to take the tools that I've developed, because I know that's what I've been doing, to locate the NBNS responders out there. If you can, and if you can't, harden the box in particular the services that are offered to make sure if you can also sanitize those records. Now we know, of course, that the enterprise is full we do the best we can full of very soft, tender, easy targets. And it's very difficult to get people to stay on top of hardening the host make sure they're hardened properly. But at least if you are able to locate the ones that are advertising, you can prioritize your efforts, okay? Because they do present a much higher degree of risk because they're not just vulnerable but they're telling everyone around them hey, here come get me, again, once again. All right. So ultimately the plan of attack is hunt down NBNS responders with these tools. Remove them or harden them and then implement any controls you have for multicast in your environment. The IGNP snooping as for IPv4, MLDv2 and those environments that have implemented IPv6 implement, of course, IGAP if you have it or any IPv6 multicast authentication mechanisms available and, of course, monitor. Find out who is out there participating. Okay. Before I go today, I'm going to mention a couple other protocols. The simple service discovery protocol for SSTP and link local multicast name resolution. These are Microsoft's answer. Doesn't always have an alternate answer. For zero configuration networking or the zero configuration networking that Apple came out with. Both less developed but still in use. I still see advertisements out there from SSTP. Host utilizing SSTP. Okay. But my final thoughts are hosts are now actively advertising their available tech services to anyone listening on the network. It's great for passive information gathering, but it can be controlled to limit your exposure. But ultimately, this sort of activity is not for the enterprise. The authors of the protocol say this in the RFC, they say this is for the home. This is for the small business. This is not for the enterprise. Unfortunately, as it is mostly in the vendor space, they're all competing. They're all trying to pile on and add on the most features they can. So they are doing this. They are putting these protocols and turning them on by default. They're putting these on their products. And I don't think people are aware of this. So they're putting them these devices in the network and they're advertising. So this is ultimately not for the enterprise. So you need to track this down Okay. This actually is the conclusion of my talk. Thank you for coming today. There are a couple of slides. There are a couple of slides here. The MD5 hashes of the tools as well as the site to get the updates. I don't think that the updated tools are on the DVD. Because I updated the tools and looked for a download and there was none. So make sure you go out to that site. I'll put them up probably tomorrow. Go out to that site. Give them the most up-to-date version. Some links. If you're interested in reading more about it. So once again, this is the end of my talk. Thank you for coming.