 Okay, it's probably time to get started. Can everybody hear me okay? No, okay. Okay, my name is Michael Rash. I'm the CTO of a network security company called Celerix. So this talk is going to concentrate on the concept of running single packet authorization over the Tor network and why that might be an interesting thing for you to look at for providing an additional layer of security for services such as SSH. By the way, please interrupt me at any time if you have any questions. I don't mind being interrupted, so fire away. So I'm gonna start with a brief overview of Tor. I'm sure nearly all of you are familiar with it. We'll move from there into talking about default drop packet filters and single packet authorization, why that provides an important mechanism for protecting long running services such as SSH or OpenVPN. Talk a little bit about SBA over Tor that will comprise the bulk of the presentation. And I'm leasing a new version of FWNOP at this conference. FWNOP stands for the firewall knock operator. I introduced that software two years ago for the first time at this conference. It was the first port knocking implementation that combined encrypted port knocking with Passivo as fingerprinting. However, port knocking is an outdated protocol next to single packet authorization. The default mechanism for passive authorization is now single packet authorization in FWNOP. So 0.9.7 is available for free on my website, release term of the GPL, which is cyfordine.org. And I'm gonna end up with a live demonstration and hopefully leave time for questions. So Tor, Tor is a really interesting project. It is a network of onion routers that makes it very difficult to perform traffic analysis of TCP based traffic. It constructs a cloud of routers across the internet with the unique characteristic that no individual router in that cloud knows the full path of a virtual circuit that's created for each individual TCP connection. So each individual router only knows its immediate upstream hop and its immediate downstream hop. So anyone who is actually trying to know where traffic is destined for or comes from is not really able to determine that. There are attacks wherever if someone is able to watch every single entry and exit router out of this network, based on some timing attacks you could get some information. However, in general, the strength of the Tor router cloud is increased by the number of nodes that are running on the internet that are running Tor. And at last count, I think it's in the several thousand. Somebody can correct me on that, but it's getting more popular all the time. It's compatible with any application that can speak with SOC support. It uses the TCP protocol for transport and traffic of course is encrypted between individual router nodes within the Tor network. So visually, Alice wishes to talk to a server that Bob is running. Alice will make a connection to an entry router into the Tor network. And once the connection goes into the established state and only after the entry point connection goes into the established state will a virtual circuit actually be constructed. That established characteristic is important for the remainder of the talk and we'll talk about that a little bit more later. But the links between Alice and the entry router are unencrypted from there. The rest of the traffic is completely encrypted as it's bounced around through the router cloud. And finally it hits an exit router which is randomly selected. And then traffic is unencrypted for eventual communication to the actual server that Bob is running. Nice concept. So single packet authorization, what is it? It is a mechanism by which default drop packet filters are used to minimize execution paths that an attacker can permute. So if I'm running a default drop packet filter so that nobody can even connect to SSH say running on a system then they are fundamentally unable to interact with any of the user land functions in that daemon that may potentially contain vulnerabilities. Every function has a certain non-zero probability of containing some vulnerability. Of course SSH being written by some of the best computer security programmers around has been very good about not having vulnerabilities in general, however they do happen. And I for one, do not let arbitrary IP addresses connect to my SSH daemon for that reason. I personally have had a system hacked via SSH once and I vowed never to let that happen again. Authentication and authorization data that's sent by single packet authorization is monitored passively, completely by libpcap. Although FWNOP also supports the ulogdpcap writer if you prefer getting a little bit more esoteric with net filters capabilities. I should mention that single packet authorization is a little bit of a misnomer. It includes both authentication and authorization capabilities which are different. Authentication has to do with trying to verify whether or not an entity is who it claims to be whereas authorization tries to determine whether or not an entity is allowed to perform an action. There is no traditional server in the FWNOP architecture in the Berkeley socket since. All the communication is done or the packet data is collected passively on the server side. So it kind of is interesting that if you might ask, well how do you really secure a system? And assuming that you're not running a wireless device driver and you're being monitored or attacked by Dave Manor or Johnny Cash who's a really interesting talk at Black Hat. I personally, by the way, I'm running a kernel that does not have even the driver compiled for my wireless device driver, my wireless card. But what's the closest we can get to Marcus Random's perfect firewall? I mean sure you can cut the ethernet cable to your computer but then it's not very functional on the network either, right? So the next best thing is a default drop packet filter. Intercepting packets within the kernel is pretty much the lowest level that you can possibly restrict an attacker's ability to communicate with a user land demon. So let's try to find a build a security mechanism that uses a default drop packet filter fundamentally to make it difficult to detect that a service is even running. So some quick characteristics of single packet authorization. Up to the minimum MTU of data can be sent between the knock, or I should say the SBA client and the SBA server. That makes it possible to use encryption algorithms such as the El Gamal Cypher in GNU PG which has, I mean, you can have relatively large key sizes compared to symmetric algorithms. I use a 2048 bit GPG key. That is fundamentally incompatible with transmission over a port knocking scheme because the data transmission rate is so error prone and slow. An additional consequence of the larger payload is that replay attacks can be elegantly thwarted. If someone is able to monitor the SBA packet from the SBA client to the server, it does them absolutely no good. At least that is, they can of course try try crypt analysis of that packet but then you're on pretty solid ground because a lot of research has gone into making sure that encryption algorithms are implemented well and resist that kind of analysis. The point is that every SBA packet includes 16 bytes worth of random data. And on the server side, if the server side tracks all the MD5 sums of the valid encrypted packets, if a new packet is seen that has the same MD5 sum as any of the previous packets that have been seen, then no action is taken whatsoever and an alert is sent. By default, SBA uses UDP for transport. You will note that's a little bit different from the tour requirement of using TCP but if you are using SBA without using tour, you can spoof the packets because they're only a single packet is sent. That's kind of a nice consequence. So, just to drive the point home, SBA and port knocking are similar in the sense that they both use default drop packet filters and they can also use timeouts on accept rules that are added to your net filter policy but allow TCP connections to remain established by using a state tracking mechanism. But that's where the difference is pretty much end. From there, SBA solves the replay problem whereas there are mechanisms to attempt to do this in port knocking schemes but they generally require either successive iterations of a hashing function as an S-key style authentication or time synchronization, things of that type but they require keeping state on both the client and the server side and that is generally not all that scalable. SBA is compatible with asymmetric ciphers. It cannot be busted or broken by trivial sequence busting attacks. If I'm an attacker and I can monitor a port knocking sequence in route to a port knocking server, I can simply just spoof a packet to the same port as the previous packet was sent and thereby bust the sequence because now there's an additional port in there that breaks any encryption scheme. Encryption schemes don't like it when there's bogus data injected inside. They don't decrypt very well in that case. And of course, port knocking implementations look like port scans when they're sent over the wire and an intermediate IDS has no way to be able to tell that this sequence of connections to ports is not actually a port scan. So in the SBA architecture, we will see how this gets changed when we run the packets over the Tor network but essentially who can sniff what? We have an SBA clients here at the upper left who wishes to authenticate to the SBA server that's running here on this brick wall, this firewall, this is net filter in FWNOP's case. And it is possible because we are just sending a single packet across the wire that we could send the packet to this dummy target IP but as long as the FWNOP sniffer that's running here which is essentially an authenticating ethernet sniffer can monitor that packet in route, the firewall ruleset can be changed here to allow the actual connection to come from the SBA client. An attacker of course can monitor any of these communications but as I said before, replay attacks are not useful in the SBA case. Okay, so this sort of concludes the SBA portion that is before we get into talking about Tor but I wanted to mention something. There seems to be some confusion out there. Some people think that SBA may be sort of along the lines of security through obscurity. Well, I would say that SBA is no more security through obscurity than using passwords, shared keys, or GPG private keys. SBA is additive, it's not as though we're using SBA as the complete security mechanism for protocol such as SSH. It is just an additional layer to make it so that if somebody is using in-map out there and trying to detect that SSH is running on a system, they are fundamentally unable to tell that SSH is actually running. It is not the complete mechanism, it's just an additional mechanism to raise the bar just a little bit. JBL wrote a good paper on why security through obscurity is not what many people might think. If you're interested in reading that, I highly recommend it, it's at the link below. Okay, so single-packed authorization over tour. Well, why not always just run SSH connections over tour? You can do this, of course, and that provides an additional layer of protection in the sense that a traffic analysis is now difficult to do. You can't detect that you're, as an attacker, that you're able to see where an SSH connection is going or where it's coming from. However, an attacker can also make connections over the tour network as well. We still need to have a method of restricting arbitrary connections to SSH with a default drop packet filter, and that implies that you still want SBA. So what we wanna try to do is make SBA compatible with the tour network in some way. Does anyone have any questions so far? Oh, okay. Okay, so tour uses TCP for transport. This has some implications. We cannot fundamentally influence how TCP stacks communicate over the network. Tour is written on top of TCP, and a consequence of that is that we can passively fingerprint operating system stacks that are actually running tour, and we'll have a slide on this a little bit later. Another consequence is that if you use in-map to try to connect, to send a scan over the tour network, what do you get? Well, if you're running as root, the default in-map scanning method is a SIN scan or a half-open scan, and if you try to send that over a SOCAT proxy that is interfaced with tour, you will notice that a SIN scan by itself never actually gets a virtual circuit set up through tour at all. The virtual circuit is only established after the connection to the entry point router goes into the established state. You can get a virtual circuit to be set up if you use the normal TCP connect method, or dash S capital T, but presumably if you're running a port knocking implementation, you're not actually going to have a whole bunch of servers listening for all the ports that you're actually connecting to. You're just passively transmitting this data across, and that is passively monitoring it, and the consequence is that when each of those virtual circuits tries to connect to that port that you're trying to scan, nothing will respond. In other words, a reset will not be sent because there's no accessible server there, and so tour will retry and set up a new virtual circuit with a new exit router, which means that your port knock sequence will look as though it's coming across from essentially arbitrarily, as many different exit routers as you're sending, as you're setting up virtual connections to. That is not very good for trying to guarantee that you're able to send a port knock sequence from a single IP address. Okay, so tour using TCP for transport means that we must have bidirectional communication for data to be transmitted across the network. So that means that technically this is incompatible fundamentally with the idea of single packet authorization. There are going to be at least, you have three packets for the TCP three-way handshake followed by a packet to send the actual data followed by the fin to close down the TCP session. And we can't also just simply include SBA data within a SIN packet and send it across the network. Recall that we can't permute how the TCP stacks on any of those operating systems are actually functioning. Tour is built completely on top of TCP. We have no control over how each of the individual tour routers are actually sending packet data across the wire. So the fundamental consequence is that we must have a real TCP server to which to connect on the FWNOP daemon side. So default drop can't apply to that server clearly. We must allow connections to some TCP server so that we can actually get the SBA data across the tour network. So if you'll allow me the, I guess the indiscretion sort of the leeway to say that we're sending single packet authorization data over tour and it's gonna involve multiple packets then we can proceed. So how can we do this in a way that enhances security? So in the 0.9.7 release of FWNOP there's a new mode that allows a TCP server to be instantiated by FWNOP with the following characteristics. It listens on a high port, specifically 62201 which is the same port that the UDP communication normally takes place over. It runs with nobody, it does a bind, a listen and then it loops over successive accept and receive calls with no other code. So the consequence is that this server has a lot less complexity than a more complex server such as SSH. So I feel more comfortable and at least allowing people to connect to this server instead of seeing that SSH is actually running. The data acquired on the FWNOP demon side is still acquired passively via LIPP cap. It doesn't actually listen on the demon side doesn't actually look for the packet data over that established TCP connection to 62201 via a receive. It actually still monitors the packet data passively. So it's compatible with also sending the SPA data over UDP port 62201 as long as you don't also filter that port out of your PCAP filtering statement. So Taurus is designed to make the exit router hard to predict. So that has implications also for how SPA is going to work. Normally in many cases people will use FWNOP with the dash cap lowercase s argument just to say to the FWNOP demon wherever whatever IP address happened to communicate this SPA packet two is going to be the one that I'm going to allow to connect through to SSH and the one that I'm going to reconfigure my net filter policy for. That unless map address is used within the Tor network presents a problem because once the SSH connection is made over the open internet then that the IP address from which it originates is going to be different than the exit router IP address that the SPA packet was sent from via Tor. So just to drive this point home let's if we look at a SIN scan over a SOCAT proxy with Tor you will see that this first command here is where we're setting up to listen on local host over port 62201 but we're interfacing with the SOX port. And so if I send an in map scan against local host looking for whether or not port 62201 is actually open of course in map returns the fact that it is open because we're running SOCAT and it's waiting for a connection to go to the established state and thereby send it on through the Tor network where it will set up the virtual circuit. But if you do a TCP dump on the server side and actually look for a circuit connection to be established over port 62201 which is where we're actually mapping it to appear you will see that no traffic comes across whatsoever because the in map scan never actually went into the established state it only sent a SIN packet across via a raw SOCAT and the corresponding three way handshake never actually occurred. If we use a connect scan however against local host again the port is open because yes we're listening on port 62201 and if we do a TCP dump on the server side this comes out of the Tor network now we see that we do actually see traffic over port 62201 but take a look at these three packets. In this case I was using net filter to filter all the incoming connection attempt to this port. So Tor continually retries to set up the virtual circuit and is unable to because there's no data coming back whatsoever there's no reset packet that comes back. So we can see that the TCP options portion of the TCP header is a little bit different for each of these successive connections. So the first one here is the 6474207.50 address. It begins with a maximum segment size of 1460 it follows by selective acknowledgement is okay, etc. Well when it doesn't get a reply a new connection is attempted. It comes across from this 82.224 address maximum segment size is 1460 but now there are two knob instructions before the selective acknowledgement is okay. Clearly this is a different TCP stack and even if the IP address didn't tell you that. And finally yet another TCP stack down here maximum segment size 1460 two knob instructions selective acknowledgement okay and then a bunch of other stuff that neither of the other two operating systems actually had. So you can fingerprint these things just to see what kinds of operating systems are actually out there they're running tour. FW knob D includes a passive OS fingerprinting mode. It's a complete re-implementation of POP but it only requires net filter logging messages in order to do this. So if you add the log TCP options argument to your logging rule and net filter you can get FW knob to tell you what operating systems are constructing those SIN packets as they come across the wire. So here we have one that's running Linux. There's also a free BSD one in there and an open BSD one in there too. Okay so over the tour network what do we see? Single-backed authorization gets sent across this established TCP connection so traffic analysis where an attacker is able to sniff traffic between the client and the entry router. So you can see that once the SBA packet actually makes it into the tour network it's not really all that useful because you don't know where it's coming from or where it's going to. All you see is a TCP connection that contains this seemingly strange looking data. It's about say a thousand bytes worth of encrypted data that doesn't repeat ever and it gets sent across to the minimal TCP server that's running on the FW knob demon side and then the SSH connection does not go through the tour network and that is totally, there's no way to relate the two communications together. So in FW knob 0.9.7 the features that are released are the FW knob serve minimal TCP server that we talked about. You can enable that with the enable TCP server argument in FWNOP.conf. This next bullet is kind of interesting. If you use FWNOP against multiple hosts but because the FWNOP command line is a little bit complicated and you don't want to have to always remember exactly which GPG key you're actually using for which host you can use this last host argument to specify which command line arguments you would want it to run. It keeps state with respect to those arguments for each host that you run it against. I ported the open SSH patch to SSH, open SSH 4.3 P2. I'll give a demonstration of this a little bit later. There was a vulnerability in the Crips CBC module where the initialization vectors would result in weak encrypted data. So I needed to update that. Updated also not to advertise the FWNOP client to whatismyp.com. We will see that we're able to use automatic resolution against whatismyp.com in order to tell what the external address may be that you're going through if you're behind in that. Okay, live demonstration. Can anyone see this? Yes? Okay. What's that? The lights, these lights? Whoa. Okay, can you see that? All right. Okay, so tour is up and running. I'm gonna run our SOCAP proxy so that I can connect to a local host and have it sent across. This is the IP address that I'm actually going to. In case anybody would like to know that. So right now I'm running in-map in a watch window so that I can tell exactly when SSH is filtered and when it isn't filtered from the NAT that I'm going out here from the DEF CON network. I'm sorry? Okay. Is that good? Okay. Is the one on the left okay? Okay, that's gotta be okay, right? Okay. Okay, so you can see that SSH is currently filtered on this IP. So I'm gonna use that last command line argument that I told you about. The host name is spot horror. And what's happening here is, excuse me, no, it's local host. Okay. So what's happening here is I'm using a new TCP command line argument. I should say to FWNOP to tell it to send the SBA connection over an established TCP socket. That's this TCP SOC command line argument here. We're gonna say that we want access to TCP port 22, which is where SSH is living. We're using GPG authentication, which I highly recommend by the way, because if you type your password in incorrectly, you don't have to worry about whether or not the packet that gets sent was actually sent or ever received by the target. It tells you before, just as a return value of GPG, whether or not the password was valid before you have to get into that strange, you don't know what's happening scenario. So the recipient's key is identified by the host name spot or here. The signing key is one that I have in my laptop, is it called Isengard. If this dash W argument says that I want it to resolve what my external address is via whatismyp.com, by default, the user agent that it sends is a Firefox user agent, so there's nothing to actually identify the fact that you're running FWNOP as a client. And we're gonna send this in verbose mode against local host. If I type this password in correctly. Okay, now everything worked. Yes. You can see that up here, the port is currently open. Of course now you all have access for its limited amount of time as you're going over the same network, but it's now back to filtered. So you have a little window of time, you can tell what's running there if you're on the same local network. However, you can see that if I try to make a new connection, of course the port is filtered. Also, if I take this original packet data and replay it, because somebody might have snifted in route before I do that, I wanted to point out something here. These messages are coming across from FWNOP D. What you can see here is that FWNOP received a valid GPG encrypted packet signed with this GPG here that we require. And it received it from this particular IP address, which is a TorExit router. So it added an input accept rule for this IP though, however, which is not the same thing. That's what we received from whatismyp.com. And so it was able to extract what IP address to actually allow access to from the encrypted packet data itself. That's never exposed in the clear text. And finally, after a 10 second timeout, which is configurable via how you set up your access.conf file, the netfilter input accept rule was removed. Okay, so I saw my packet data there. If I do the same thing and send that packet data across, the wire, the port is still filtered. Should be something coming up here. So attempted message replay from this IP because the MD5SOM matched. So that concludes the demo. Can you give me lights please? And finally, if you're looking for updated versions of these slides, they're a little bit different from what's on the con CD. Oh, is that not showing up there? Let's see. Okay, you can find them at this link down here. Anyone have any questions? Yes. Right, so the question was if I actually wanted to send the SSH connection also over Tor, how would I know what my exit IP is? And that would, what you'd need to do to be able to make that work is use the map address functionality in Tor to get that to work. That has some interesting implications, actually doing it that way by that would, what that would mean is that traffic analysis with respect to your SSH connection as well would be thwarted, which is a good idea. It's just, I didn't have time to actually put the map address stuff in here. So, any other questions? Yes. Am I on? Yeah. So it was the benefit of sending this over Tor just that if somebody's sniffing the traffic going to the server, it's a little bit more difficult for them to tell that the packet that came from some random IP address just before your SSH connection was what was allowing the connection to go through. Right, so I'm applying traffic analysis, I'm making it difficult for traffic analysis to work against the SPA itself. So, someone, say for example here on this internal network that was able to see that there were, if I was not running it over Tor, they could see that there is a, by default, if a packet goes over port 6201 UDP and they're looking for that, they might know that SPA is actually running and have an idea therefore that some packet filter may get modified as a result. But running it over the Tor network makes that just a little bit harder to do because you can't tell that you're actually, to where you're sending it to. So, it's designed to help harden the SPA protocol itself. If you also then also use the map address functionality in Tor and run both connections over Tor, then you get traffic, it's hard to do traffic analysis on both connections. Had another question Ben, it's getting hard to hear you, so I'll probably just go up there. Okay, any other questions? Thank you very much.