 My name is Fyodor from Insecure.org and the M-Map project. I'd like to thank you all for coming and of course DEF CON for inviting me. I'm a big supporter of community conferences like DEF CON where people can go if they have a passion for the technology, amateur hobbyists who might really love this stuff but don't have a company that will pay thousands of dollars for a ticket. For example, the DEF CON admissions forum has a question saying, hey, is your willingness to speak contingent on whether Black Hat accepts you? And I was like, hell no. This talk was prepared for DEF CON and if anything the contingencies are the other way around. So, thanks. Anyway, I'm very glad to be here and I first want to warn all of you that this talk is not about cross-site scripting attacks on social networks, or hijacking Twitter feeds, or anything like that. It's about port scanning and more port scanning. And if you don't like port scanning, the next 50 minutes are going to be your worst nightmare. Because for me to talk about something else would be sort of like Dan Kaminski doing a talk which doesn't involve DNS in some way. I mean, sure, I may throw in some OS detection or NMAP scripting engine action, just as Dan may take his DNS and use it to tunnel YouTube in order to rickroll some poor schmuck. But in both cases, we're just expanding on our core topics. And my topic, as you can see from the title slide, is about internet scanning. I spent a lot of time this summer scanning tens of millions of hosts on the internet collecting data. And when I tell people that, they're often like, why? And to me, I think scanning is its own reward and you don't really need any particular reason. But in this case, I did have some concrete goals for the project. One of them is collecting empirical data that I can use to enhance NMAP and add cool new features. And I'm going to talk about some of those features in this presentation. Second is I want to show how you can use that data for knowledgeable people to make your scans more effective. Basically, there are a lot of people who make assumptions on how networks are structured and populated and use those to decide what sort of scans are going to work best. But these assumptions are often based on, hey, how would I set it up? And they're not always reflective of other networks. So when you can find empirical data that meets what you need, then that often works best. And if you can't find the data, a goal of this talk is to help show you how you can do scans like this and potentially collect it. I also wanted to detect and resolve NMAP bugs and performance issues. The idea is that when you scan tens of millions of hosts, you're basically putting NMAP through a lot of different situations. It's pretty much any networking situation you can imagine and see how NMAP reacts to it. And I fixed a crash bug. I fixed a deadlock bug. There were a number of cases where I was like, this is going too slow. There's got to be a way to speed it up. And so then I looked through and try and figure out why it's slow and improve that. I also want to demonstrate techniques that can be good for routine scans, as well as the wide-scale scanning that you may do. The idea is that if a scan works well for 25 million hosts, then surely it'll probably work well for you for just a 25,000 or whatever you might be doing. Now let's look at the challenges to launching such a scan. First of all, I want to mention that instead of doing one humongous scan, I did a lot of smaller but still large targeted scans, each of which were designed to collect a certain piece of data which would be useful. And the question is, how should you figure out what IPs to scan? I have a lot of options. You could take BGP and look at what networks are routable and use those DNS zone files, registry allocations like ARIN and RIPE. But in the end I decided to use NMAP's own random IP generation script feature. Here we take NMAP, we say generate 25,200,000 IPs, and in this case I did the extra 200,000 because of potential duplicates. We say do a list scan, so don't actually scan the machines, just list them out for me, because I'll scan them later. Don't do reverse DNS because that would take a long time and we don't need the data. I use grep and awk to grab the IPs. I sort them, remove the duplicates, grab the first 25 million, and then I have a 25 million IP list that I can use for the scans. So that's sort of the type of way I generated the random numbers. But once you have what targets you want to scan, the next question is what sort of source you're going to use. And here I had a lot of ideas, some crazier than others. The first one was P2P scanning. I was going to distribute a client which would be called NMAPster, and people would download it and it would scan for them and let them know and upload the results for collection. But I decided that a key goal of this was to make NMAP faster and more efficient for people's normal day-to-day scans. And so I decided it was better to focus on just using NMAP itself rather than building custom software for this project that may get around performance issues and the like. Another big concern was a legal one. I knew that when you're scanning this many hosts, it's going to raise a few eyebrows. And I certainly don't want to get kicked off my ISP again. And being arrested would be much worse. So I thought, how can I do this but not collect too much heat? And so the solution I decided on was to go through my neighbor's open wireless access point. No, I'm just kidding about that. I decided it would be completely unethical and inappropriate and she didn't have enough bandwidth to make it reliable. So I decided to use an ISP I used for co-location and do the scans from there. I thought maybe it'd go under the radar. But it didn't. Within like 15 minutes of the first scan, they were contacting me frantically saying, what the hell are you up to? They thought maybe I was infected by one of the most virulent internet worms they'd ever seen. They said, your machine is going crazy. It's probing thousands of machines per second all over the internet. They were talking about shutting me down. And I was like, oh no, this is no good. But then I said, hey, you know, don't worry, I'm not affected. I'm doing this on purpose. And that didn't help either, in my case at all. Basically, they figured I must be some sort of spammer or worse if that's even possible. So then I was like, uh-oh, I'm totally busted. I'm going to have to cancel the project, stop the scans, write a whole new talk on the cross-site scripting vulnerabilities, and give that instead. Fortunately, though, it turned out that they were end-map users. So I said, hey, the scan is to make end-map more efficient and effective. And they're like, oh then, carry on. So I was real happy about that. I had to slow it down quite a bit so it didn't melt their switches anymore. But other than that, they were cool. Unfortunately, the US Department of Defense was not quite so accommodating. They didn't like my scans at all. They said, hey, you're scanning sensitive military installations. This has got to stop. And I thought, hey, I'd be happy to use end-maps exclude file option to skip those networks. But they wouldn't even give me the networks because that's sensitive military information too. So whatever. The next issue, I mean, it has been making me a little nervous now. They are the military when planes fly overhead. But nothing too bad so far. The next issue were firewalls. For many of these scans, just pure internet results was all I needed. But for other ones, it would be nice to get a view behind companies firewalls because they often have different ports open. The network looks a lot different behind there. And I'm happy to say that I was able to get through a number of these firewalls, not through some sort of advanced fragmentation attack. But I used a technique known as asking them for the data, which works pretty well, at least with some of them. But there are a lot of big companies who scan their networks every day with NMAP. And we're happy to contribute some data to make it work better. Another challenge is performance and accuracy. And this was different than many other types of the challenges because I wasn't trying to find a quick hack workaround type of thing. Instead, this was a key goal, was to improve NMAP's performance. And so I took this as a challenge to see where I could improve. But even so, it could be disheartening at times. Like, I did a UDP scan with the 65,000 ports, and I told it to scan 2048 hosts in a group. And you can see here, it's taken four days. It's on the first 2048, and I have negative 688 hours remaining. When your time estimate leads to integer overflow and goes negative, that's never an encouraging sign. This particular scan is still running right now, and maybe for a while. DEF CON 2009, I'll let you know how that one's going. But fortunately, some of our other scans finished a lot earlier. So that's sort of the introduction to the different scans we were doing and why. So now let's get to some more practical advice that can be concrete details and let you know how you can use this to help your scans. And the good first place to start is host discovery. Because the first thing you want to do in network reconnaissance generally is host discovery, where you scan the network and try and figure out which hosts are actually available on the network so that you don't waste a huge amount of time scanning IPs that have no host listening on them at all. But a challenge there is deciding what methods to use for discovery. There was a time when pretty much all the hosts would respond to an ICMP echo request or ping packet. Unfortunately, that time was a decade ago. So now a lot more companies block those ping packets and you need something more effective. Now NMAP by default will also send an ACK packet to port 80 which helps in eliciting responses. But even with that, I don't think it's comprehensive enough if you're scanning the internet or even some sorts of internal scans. So let's look at some of the different methods that you can use. TCP, we have two types of probes. We have the SYN probe and we have the ACK probe and they're both useful against different types of firewalls. The SYN probe is likely to get through stateful firewalls when they're configured to allow incoming connections because they'll say, hey, this is a SYN packet, it's initiating the connection, let it through. But those same firewalls, if you send an ACK packet, they say, hey, this doesn't correspond to any existing connection. It's not acknowledging any legitimate data, so they'll just drop it and it'll be ineffective. However, against stateless firewalls, you have the opposite problem. They may try to block incoming packets to certain ports and they look at the SYN flag to detect that it's an incoming packet and they'll drop it. However, you send the ACK packet against those ones and they have no way to know. They have no state to say whether there's an established connection there or not, so they have to let it through. So I have a quick example we can do. Basically, let's say we're going to do Nmap, do a ping scan. We're going to do a SYN probe to port 80, no reverse DNS, and this time we'll just use sun.com. And it responds pretty quickly and says the host is up, so we got a SYN ACK or a reset back. Now we'll do the same one with an ACK probe against the same host and it takes a bit longer and eventually it times out and says no response was received. And so you want to think to yourself, hey, is their firewall a stateful firewall or is it a stateless firewall? And if you think about it for a minute, you'll hopefully come to the conclusion that it's a stateful firewall because it allowed the SYN packet in, but the ACK packet, it was able to detect, hey, that's bogus, I'm going to block that sucker. So now let's say we've seen the SYN probes and the ACK probes and the question is which one do you want to use because the SYN probes worked against some hosts with the stateful firewalls but the ACK worked against others. And the answer is that, hey, this is not an either or situation. You should use both probes against various ports to have a maximum chance that at least one of them will get through and generate a response that proves that the host is online. So then the next question is what ports should I use? You have 65,000 options there and you often don't know which ones are going to work best. So here I did some of that empirical data stuff and I scanned hundreds of thousands of machines and I detected the ones that had a heavy firewall, the ones that blocked the vast majority of the ports, because the ones without a firewall, those don't matter because you're going to be able to detect those anyway with a decent discovery. It's the ones that block all but a few ports that are hard to find. And so out of those, I looked at the most commonly responsive ports. They don't have to be open. They can be closed and send a reset and that works just as well. And you see here many of the normal suspects, ACP, SMTP, SSH. Some people look at this list and say, hey, where are the windows ports? 135, 139, those are really common. But remember that I was only doing this based on heavily firewalled hosts. And if you go through the trouble of setting up a firewall, you better darn well block the windows ports. So what I would advise is use some of these with SIN probes and then some of the other ones with ACS. Next we have UDP host discovery. And that one's simpler. Your strategy there is you want to find closed ports because an open UDP port normally won't even respond to the probe. It'll just be like, well, I just got a blank packet, don't know what to do with it, just ignore it. Whereas closed ports will generally send a port unreachable packet, which discloses that the host is live. So I pick a high numbered closed port usually and then sometimes I'll do 53 as well because DNS is so popular with UDP that sometimes people allow it into their whole parts of their network and so that can be effective as well. There's also ICMP host discovery methods offered by NMAP. And here the thing is some administrators, like say Google.com, will say we're going to explicitly allow echo requests because we don't consider ping packets a threat, but only hackers use netmask request and timestamp request so we're going to block those. However, you also have administrators who kind of do the opposite. They say, oh, I don't want those evil hackers to be able to ping me, so they'll block the ping requests, but then they'll forget that you can do the same thing with these other two. So my suggestion is usually do an echo request plus one of these other two. Normally works pretty well. We also have a new feature relatively called protocol ping, which basically sends IP packets with various protocol headers and tries to expect a protocol unreachable message if the host is live. And that can be useful. I haven't actually done the test to see which protocols are most commonly useful for this particular type of probe, but by default we do ICMP, IGMP, and IP tunneled in IP. So now I've talked about a lot of different discovery techniques and which ones you might want to use, but your question might be, really, how valuable is this? It's going to take longer to scan if you add a bunch of discovery techniques. And so you have a legitimate question in how much of a difference will it really make. And again, instead of just guessing or making assumptions, a good thing to do is test. In this example, I generate 50,000 IPs, and then you can see I use the default ping scan, and it chugs along, and it finds 3,348 hosts up in about 1,600 seconds, which is about 27 minutes. And so that's a lot of machines, and it looks pretty successful. But then I take that exact same list of 50,000 hosts, and I add a bunch more discovery techniques. We do the echo request, the timestamp, SIN probes to a bunch of ports, ACP probes to a bunch of ports. We set the source port to 53 in order to masquerade as DNS, and it goes through, and this time it finds 4,473 hosts up, but it does take a bit longer. So you have to ask yourself, you know, look at the data. Here it took almost three times as long, but we found 34% more hosts. And I think in most cases, if you want a comprehensive scan, you're going to find that to be worthwhile. So now I just have a plea, basically, about upgrading your end map. And part of it is I'm sick of bug reports, but it's like, yes, we fixed that in 2003. There are a lot of people who just don't seem to upgrade all that often, and then they complain, or they'll say, hey, the problem with end map is it's obsolete. It tells you what port numbers are open, but you don't know what services are behind them, and nowadays everyone has, they'll tunnel everything over HTTP in order to get through firewalls or whatnot, and it's like, hey, we added version detection in 2003, you know, just upgrade. In addition, I made a number of improvements to the performance of the system recently, which you'll find valuable if you upgrade. And then the question is, what version should you upgrade to? Version 4.68 is the latest release on our download page. If you want to get even newer, we have our subversion source code repository releases, and you can find information at this URL or just go to the web page and you can track it down. But for all the goods in this presentation, you'll want to use the BHDC08, Black Hat DEF CON release, which you can find at this location, and that contains the top ports feature and some of the other ones that I'm going to be talking about. So speaking of top ports, this was another one of my big scans, and here I wanted to determine the most commonly open TCP and UDP ports. And again, I got some data also contributed from organizations to look at representation of internal networks. And then I took that data and I augmented the Nmap Services file, which lists all the services known by Nmap, and that enabled me to add a number of cool features. First, let's talk about the default scan ports. In Nmap 4.68, Nmap would scan all the ports up to 1,024, plus it would scan all the ones it has a name for. But the issue is that the IANA gave names to a bunch of ports many, many, many years ago, many of which aren't even used really anymore. And at the same time, there are some ports that you see open more often that turned out to not have names. So with the new Nmap, since it now has this frequency data, it's able to just scan the top 1,000 ports for each protocol. So you get better results in many cases since it has all these ports that the old one didn't have and it doesn't waste time scanning these ports that don't actually respond generally. And at the same time, it's a lot faster because it's only scanning a little more than half the ports. So you'll find a little increase in your scan times from that. But what it really makes a difference is the fast scan. That's the traditional hyphen capital F option of Nmap, which used to just say scan all the ports with a name. But the major problem with that is, hey, by default, we had 1,700 TCP ports. With fast scan, we had 1,200. You know, that's not really fast. That's kind of a small difference, but nothing dramatic. But that's all Nmap could do because it didn't really know what ports were common. It only knew which ones it had a name for. With the new services file, Nmap just scans the top 100 ports for each protocol. And so you get usually an order of magnitude, an increase in speed, which is helpful for TCP, but it's even more helpful in many cases for UDP because I've seen a lot of people who basically don't even do their UDP scanning because they say, oh, it takes too long and it's hard to disambiguate the filtered versus the open ports and so they just pretend it doesn't exist. But the attackers aren't going to pretend it doesn't exist. And so it's really important to figure out what's going on with this protocol. And now let's look at an example of the difference that this makes. Here I'm doing a scan. I say SU for UDP scan, V to do the version detection, and that's important for UDP scans because of that open versus filtered problem. Normally when Nmap gets no response, it doesn't know if the port's filtered or open. And in the case of scanme.nmap.org, that's the case with all of the ports. So it's like, great, I got a report that said all the ports are either open or filtered. That's no good. And so with version detection, Nmap has a database of probes that you can send to each port and hopefully get a response which proves without a doubt that the port is open. I say do a fast scan, use aggressive timing against this machine that I maintain for people to scan. And with 4.68, that took an hour and two minutes. It did find the right data, but that's still a long time to wait. With the Black Hat DefCon release, that same command took six minutes and 29 seconds because it was only scanning the most important ports and it knew what those were and it did find the open port. Then I optimized a bit more. I said also add the version intensity zero flag, which says only send these UDP probes for protocols that you know commonly listen on a certain port. So for 53, it'll only try DNS for 161, only SNMP. And with that, that reduced the time to 13 seconds. So the moral of the story is hey, if you know what you're doing, know what data you really need, you can optimize your scan a bit and make it a lot faster. In this case, we got exactly the same data, but instead of waiting an hour, we waited 13 seconds, which helps a lot. Two features which are kind of derivative of those is the top ports feature, which says hey, you don't want to just have to choose between the default of a thousand ports or a fast scan of 100. You can specify arbitrarily how many ports you want to scan. And that leads you to the question of what will work best to the top ports option. And so I used empirical data again to say out of all these big scans, how many of the open ports would I have found with different top ports values? So if you just scan the top 10 ports, which just goes really, really lightning fast, you get almost half the TCP ports. With 100, which is the fast scan, you get 73% of them. Whereas with a thousand, which is the default, you get 93%. So that's pretty good to get 93% of the ports, but you're only scanning less than 2% of the total 65,000 port space. So what I think a lot of pen testers will do is say hey, I'm starting this engagement, but I need some data to start with, so they'll start a fast scan to scan the top 100 ports really quickly and get that data and start working on it. And while they're working on the initial data, they'll have their super comprehensive all ports, no ping scan going. And then at the end of the scan of the big one, they can just diff the results and see if there were any new ports that the initial quick scan missed. Just in case you're interested, these are the top 10 open TCP ports I found. This differs from the previous chart because that was just responsive ports that could be open or closed. 80 is the top, no surprise. As a security guy, it's kind of depressing to see Telnet open more often than SSH. A lot of that switches in routers and various devices. And here, of course, you do get the Microsoft ports because we're looking at open. Similarly, I have the data for UDP. Microsoft kind of dominates this chart, although you see some of the other normal suspects like SNMP and NTP. And here's the UDP effectiveness of the different top ports values. With UDP, you get even a greater percentage open with a smaller value. So here, you get 90% with the top 100 ports, whereas before, we only got 73 with TCP. Here's another feature that we've added recently that I have to admit I have mixed feelings about. I'm kind of proud of NMAP's congestion control and other technologies to try and figure out what scan speed will work best. But there are a lot of people who say, hey, I just want to specify a certain rate and have you scan at that speed. And don't worry about if there are any packet drops or latency issues or whatnot. Just go at the speed I say so that I know exactly when it'll finish. And it was basically for that one reason that a lot of people used scan-rand and unicorn scan and that type of scanner. So finally, I broke down and was like, hey, it's an easy feature to add and even I found it to be pretty useful at times. And in fact, I used it during most of my internet scanning. And then a feature that's even more new came about when the ISP call came saying I was melting their switches. And so that's a maximum rate to say NMAP don't scan more than 300 packets per second or whatever you specify. And so that made the ISP guys a bit happy. So here's an example of putting it all together. Looking at kind of a typical type of the scans that I was doing and what options I was using. I would say NMAP. I would give it the source IP address that I wanted to use for that particular scan. I would specify debugging mode. Although really I found I used the runtime interaction feature more often. When NMAP is running, some people don't know you can press D and the debugging level will increase and press it a few times and you'll really be scrolling the screen but you'll see exactly what NMAP's doing right at that time. Then you can press capital D to turn it down say hey, I'm done looking at this. I don't want to fill up my log files. Turn it off for now. I specified a low max scan delay because I didn't want to wait a long time for hosts that were rate limiting. I did the log file feature with the new feature that says use strf time of values so that it automatically puts the time and date in there. I give it the name of the file I want to read from. I say don't do more than one retry for this case since I really want to do a big scan and make it go fast. Randomize the hosts in the scan group. Do all the ports. Here's the host discovery options. I specified a reasonably big max host group because that's more efficient for large scans. Here I'm saying scan at at least 175 packets per second but don't scan at more than 300. So that's sort of an example of a command that I sort of changed and improved over time until I found one that worked pretty well. So now with the time I have left I saved some to talk about some NMAP news because some of these are features that are new and cool that may not reflect exactly relate to the large-scale scanning but they're actually too cool to leave out. So there are a few new features in NMAP that I really wanted to talk about. One is the NMAP scripting engine which is a thing that modularizes NMAP and lets you say hey I want to write a little script that interrogates ports in a certain way. In this case we do the HTML title for the websites it finds and there are now more than 50 scripts shipped with NMAP. Everything from like who is data to brute forcing, POP3, passwords. There are all sorts of crazy things you can do with it. I do have a quick demo of the NMAP scripting engine. Let me see if I can find it. It's a long command so I kind of cheated and put the actual command here saying NMAP-V in verbose mode don't ping, do a UDP probe for port 53 aggressive timing and we're going to do three scripts which I thought were kind of timely because they relate to Dan's DNS bug that he'll be talking about on Sunday. And so one of them just checks if a DNS server allows recursion. The second one checks if it randomizes its source port numbers and the third one checks if it has a transaction ID that's randomized. So those are the bugs that people want to fix in order to reduce the cache poisoning issues. And in this case I'm going to run it against one of Black Hat's authoritative name servers and also one of the authoritative name servers for Shmoo.com, the guys who put on the great ShmooCon conference. And so it does the port scan then it does the NMAP scripting engine it takes it a little while but then it gives you your results right next to the port number. It says that the Black Hat one basically refused recursion in both cases so it wasn't able to interrogate them further. The ShmooCon, it was recursive but I'm happy to report that it was great in source port randomization and it was great in transaction ID randomization. Now I was going to show one of the many examples that fail miserably and maybe have a little challenge game to see who can poison the cache first but decided maybe that wouldn't be the most responsible thing. Plus I've got a lot more good stuff to cover. One of the things I'm excited about is the new ZNMAP GUI and a lot of people give me crap like what I don't need no GUI I've been using NMAP 10 years and I know all of its 113 options by heart and I have to admit they have a point when you look at the old NMAP FE which frankly kind of sucked it basically just displayed your NMAP output and instead of typing SS you press the button for SIN scan whereas ZNMAP is a much more powerful interface and I'll give a quick demo of that basically just like NMAP FE it could show you your normal output it also has a tab that can say hey show me what each host has opened or look at the service level and say show me the ones with HTTP or SSH and then it has a new experimental feature that we're adding and we only have in the subversion right now which basically says hey if you're going to call the dangToolNMAP network mapper it ought to at least draw you a map yeah thank you this is certainly the best feature for an eye candy perspective and it can be pretty neat it basically takes the scan that you did and it puts it in the center, the source host and then in concentric circles around the center it shows each hop on the network and the machines that you've scanned and you can take one and say hey show me what more data on this particular scan show me the ports that are open you can scan new machines and they'll get added to the graph and in terms of the biggest eye candy aspect it's if you want to re-center the graph on a certain host that maybe makes it easier to read yes so maybe once in a while that'll convince people to actual open the GUI and try it out it also has a side benefit for me which is there are a lot of Windows users out there who have no idea how to do a command line scan or what command line even means there's so many males saying hey I double clicked on nmap.exe and it put this strange black box on the screen which then disappeared obviously nmap's totally broken so maybe this will help them but on the other hand maybe those people shouldn't be using nmap at all we have a second generation OS detection system which basically took all the things I learned with the first seven years of OS detection and improved it and we're now up to 1500 signatures with the new system so I'm hoping that'll help in terms of granularity you know it nmap users basically can find every device you can possibly imagine so sure you've got your normal Windows and Linux versions and the like but they find game consoles and PBXs and network power devices and all sorts of crazy things so let's get on to go through the submissions and see what people have version detection a lot of people like I said still don't know about it but hopefully the people who go to DEFCON do a feature that is sometimes not known as well as it could be is the reason feature basically if nmap tells you say a state is filtered you don't necessarily know is that because it sent me an ICMP host unreachable packet is that because it got no response well the way to figure out what nmap's doing more is use hyphen hyphen reason and then you can see hey this one's open because we got a SINAC this one's closed because we got a reset and that's a real good way to help understand what nmap's really doing and when that doesn't give you enough information there's the packet trace option so say in this previous scan I wasn't sure whether port 25 mail and 113 is it the destination host that's sending those reset packets and I'm actually reaching it or is it a firewall sending some of them in between or is it a different case for each well by looking at the packet trace option from a quick scan of just those two ports so you don't flood your screen too much you can look at things like the sequence number and windows number what options they use IPID and that can often help figure out if it's the same host in both cases sending the packet it's useful when you're trying to understand the firewalls and filtering systems in place advanced trace route it's trace route which isn't all that exciting but at least it does it better because nmap already knows what sorts of probes are likely to get through and it's also faster because nmap can do it in parallel I made a number of performance and accuracy improvements there's a whole section on the man page showing all the different options you can use to figure out what might help TCP and IP header options let's you specify things like source routing the record route option and some of you might be saying source routing maybe that worked 15 years ago but come on there's no way that would ever work nowadays but that's actually proved untrue in a number of cases I was talking to a guy recently who was doing a test of a network and he was on a separate VLAN that could only contact a series of servers on their network but he couldn't contact all the client machines for the company just basically a little DMZ they enabled that they allowed access to from the conference room so he basically took one of those servers and said I want to lose source route through that server to the destination machine and he was able to get around that restriction that way which I thought was pretty cool another neat feature is called Ncat and I shouldn't call it a feature because it's actually a whole new tool that I hope to ship with Nmap and it's basically a modern interpretation of the Ncat that we all know and love it basically supports virtually all of Ncat's 1.10 features except the port scanner because I have another tool I like to use for that but it also suggests supports a lot of other cool new things like SSL both for communicating between Ncat instances and to SSL ACP servers it supports IPv6 it works on macOS 10 on Windows on Linux on Unix it does connection brokering so if you set up a Ncat listener in brokering mode then all of your machines behind Nats that want to connect to that Ncat can do so through the broker they can connect to that port and then talk to each other for command and control or whatever port redirection there are a lot of different tools for doing that now if you look around and get a specific tool but it's something I want to do often enough that I wanted to have it built in it can do proxying either as a client and do your stuff through a series of proxies or it can act as a proxy once you get onto the machine start it up as a proxy and then you can proxy through it to other machines shell execution access control because you don't want anyone else connecting to your your Ncat and it's something I've wanted for a long time and has been in development since 2005 right now it's currently dev lead is Chris Catterjohn one of the summer of code students and I think he may be here are you here Chris hey let's give a hand to Chris Chris has also added a lot of the other features I demoed particularly the IP option Ping discovery mode that was his idea and he put that in we have Ndiff which is a simple tool but it does something that a lot of people have wanted for a long time which is taking two scans and diffing them so say I run a company network I scan every day all the hosts in my cron tab I can then call Ndiff and say mail me the changes since yesterday so any new ports became open any new machines on the network any machines went down this will let you know and we have a python proof of concept right now in RSVN and we're rewriting it in C since it proved to be useful and people want it the C version will work even better another thing is my map book which I've been working on for years so long that people have been comparing it to Duke Nukem forever in the like greatest paperware so I was like dang it I'm not going to go to Def Con and Black Hat empty handed again especially after last year telling people oh it's almost done so I work pretty hard to get it ready and I'm happy to say that I finally have it now and did a pre-release here thanks I hope it does a good job at not just telling you what options there are for Nmap but also how to use them effectively to scan your networks and so I last minute printed 170 copies and brought them here so I could tell people about them in my talk and they could go pick them up but I'm afraid they were sold like after an hour this morning and so they're all gone now but I hope as soon as I can I'm going to get it on Amazon and the like and also half of it is already available online for free at nmap.org and that's also where I'll be putting the details of the launch of the book and you can also join the nmap hackers list if you're not a member it's a pretty low volume list I think I've sent three messages this year as opposed to nmap dev which gets thousands of them but nmap hackers you can join and I'll send you the latest news when it's ready I also wanted to do a slide because sometimes I get way more credit than I deserve for nmap just because I created it way back but it's actually a project that's very fortunate to have tons and tons of contributors and I couldn't do it without them this is an example of just the people who've contributed significantly since version 4.50 which was nine months ago so you can see that the nmap project is really lucky to have a lot of volunteers who help out greatly now with that out of the way I think I have time for maybe two or three questions before we'll go to the question room if anyone has more so who's got a question for me yeah I don't feel very good about Germany and the UK and other countries that have put laws which tend to people suggest may ban tools like nmap that can be used for good things even though attackers might use them as well and I think that's really dangerous I mean the typical analogy is banning a hammer you know by blocking it you ensure that the good guys aren't able to use it to improve their networks and personally since I like to give talks in places like Germany and England that can be a potential issue because I hate to get busted in Germany and these laws say things like what's it designed for what's the motivation and so how do I convince a judge that my motivation was good when you know I can't even read the law so those are definitely a scary issue and things that I'm glad that groups are trying to fight even though we've had some losses there do I have another question I can hardly see because of a giant bright light shining at me oh good point the reason option we sort of always have that field there so it won't have any performance impact at all to add that so in many cases just like hyphen v hyphen t4 it becomes one of the things I almost always use alright so if anyone has any other questions I'm going to be in room 103 which is just across the hall and I'd be happy to answer them there thank you very much