[00:32.960 --> 00:34.480]  It's kind of crooked.
[00:35.140 --> 00:36.760]  Is it crooked?
[00:37.300 --> 00:39.020]  Like, incredibly so.
[00:44.560 --> 00:47.420]  Move it back.
[00:51.670 --> 00:53.050]  It went from bad to worse.
[01:40.840 --> 01:43.560]  It was, it was, I think it was lined up yesterday.
[01:44.320 --> 01:45.040]  What are you saying?
[01:45.040 --> 01:45.840]  Was it?
[01:46.300 --> 01:48.320]  I've been, I've been cheering it like this.
[01:49.280 --> 01:50.540]  I guess I've been too late.
[01:50.900 --> 01:52.820]  I've been trying to hear that all.
[02:20.130 --> 02:22.330]  Okay, so, hello everyone.
[02:22.490 --> 02:23.470]  My name is Michael Radish.
[02:23.610 --> 02:26.170]  I'm a security architect of the Terrasys Networks.
[02:27.350 --> 02:33.110]  Today I'm going to talk about my open source work, in particular the FWNOP project, which is open source.
[02:33.270 --> 02:34.930]  You can download it at Cyberdym.org.
[02:37.490 --> 02:40.770]  And generally, I'm trying to get pretty technical talks.
[02:41.330 --> 02:44.290]  If you have any questions though throughout, please interrupt me.
[02:44.430 --> 02:46.210]  I don't mind taking pressure all the time.
[02:47.110 --> 02:50.690]  And I'd like to just, to be a little bit more interactive if you would like.
[02:50.890 --> 02:54.570]  So, why then talk about port knocking and SBA?
[02:55.050 --> 03:02.710]  I think that there's not really very much consensus yet in the security community about whether or not this technology is actually useful.
[03:02.710 --> 03:06.990]  And I think that trying to get the message out is always a good thing.
[03:07.310 --> 03:14.290]  And I also look forward to feedback from the community about whether or not this technology is used by you folks out there or not.
[03:15.850 --> 03:18.350]  We're going to talk about some practical security trade-offs.
[03:18.450 --> 03:33.790]  If you've seen any of my previous talks, you'll find that I've emphasized previously the advantages of SBA over port knocking because of some built-in characteristics that port knocking has with respect to limitations in a protocol.
[03:34.770 --> 03:39.610]  There is one good advantage, however, of port knocking over SBA.
[03:39.870 --> 03:44.690]  And that is that port knocking can be implemented via less complex mechanisms.
[03:45.190 --> 03:51.210]  And because complexity breeds insecurity, I think that there's still going to be a place for port knocking as well.
[03:51.470 --> 03:59.370]  This talk is to try to educate you about, if you don't already know, what it is about some of the real differences between the two mechanisms.
[04:00.110 --> 04:07.070]  Also, people tend to concentrate on detecting port knocking or SBA in use on network.
[04:07.490 --> 04:14.730]  And they don't also offer a lot of mechanisms for breaking either of the two mechanisms.
[04:15.050 --> 04:20.930]  That is, it's easier to break port knocking both from a DOS and a replay perspective usually.
[04:20.930 --> 04:23.930]  It's harder to do the same for SBA.
[04:23.930 --> 04:29.590]  And in this talk, I'm going to release FW1.9.6, which is up on my website now.
[04:29.690 --> 04:30.430]  You can download it.
[04:31.530 --> 04:41.730]  And previous to this release, it's possible to write SNORT rules to automate the detection of SBA packets to a pretty good degree.
[04:41.730 --> 04:47.290]  And you'll see that the 1.9.6 release is now designed to make even that a lot more difficult.
[04:50.580 --> 04:55.120]  We'll talk about some real-world deployment scenarios for SSH and even HTTP.
[04:56.360 --> 04:59.820]  And we'll have, hopefully, a live demo at the end here if I can get that to work.
[05:00.440 --> 05:03.780]  But please, again, interrupt me with questions if you'd like at any time.
[05:05.440 --> 05:11.680]  So, I'd like to just review it just a little bit about what the difference is between, or what port knocking and SBA really are.
[05:11.680 --> 05:19.200]  Of course, port knocking is the encoding of authentication information across packet headers.
[05:19.520 --> 05:29.160]  And typically, it requires multiple packets being sent to a system that's monitoring those packets passively via a Fireball log file, typically.
[05:29.160 --> 05:36.360]  But you can also implement port knocking on the server side by sniffing the wire directly if you'd like.
[05:36.780 --> 05:40.040]  And I use server in sort of a loose sense here.
[05:40.120 --> 05:45.520]  We're not talking about a traditional server that you would connect to, such as a TCP server.
[05:45.620 --> 05:47.360]  We're talking about a much more passive mechanism.
[05:48.020 --> 05:56.620]  But the key is that you combine this passive mechanism with an active denial of all connections to a server that you want to detect.
[05:56.620 --> 05:58.800]  And typically, this is SSH.
[05:59.120 --> 06:02.400]  So, you protect SSH behind a default drop packet filter.
[06:02.820 --> 06:15.400]  And the only TCP stacks, the only remote SSH clients that can access this SSH server through this packet filter are those that can produce a valid...
[06:18.140 --> 06:21.580]  Those that can produce a valid port knock or SBA sequence.
[06:21.820 --> 06:24.240]  I should say a port knock sequence or an SBA packet.
[06:24.240 --> 06:29.420]  SBA, by contrast, transmits authentication information in packet payloads instead of just in packet headers.
[06:30.820 --> 06:37.000]  And the goal here, of course, is to make Nmap ineffective at detecting a service that's protected in this way.
[06:37.140 --> 06:49.740]  I think the security community probably would agree with me that protecting a service with a kernel-level filtering mechanism, such as IP tables in the Linux kernel, or IPFW in the BSD kernels, or PF, et cetera, in OpenBSD.
[06:50.280 --> 06:57.500]  It's probably a good way to protect against any user space vulnerabilities that may exist in a user space application like SSHD.
[06:57.920 --> 07:00.660]  That's not to say that firewalls themselves are a perfect software.
[07:00.780 --> 07:01.420]  They're certainly not.
[07:01.540 --> 07:03.280]  There have been vulnerabilities from time to time.
[07:03.280 --> 07:17.880]  But at least we can minimize the vulnerabilities that could potentially be exploited by an arbitrary source that's just happily scanning for SSH that is advertised to the world via TCP socket.
[07:19.360 --> 07:30.100]  So some people rely on software such as deny host and fail to ban to look for password guessing attempts in their SSH logs, logged via syslog.
[07:30.640 --> 07:37.620]  That's a good strategy, at least for trying to convince you that having a good password is a good idea.
[07:37.860 --> 07:42.260]  But many attacks don't rely on brute forcing a password.
[07:42.380 --> 07:52.520]  Neither the Zaleski integer overflow exploits, the older exploits against OpenSSH, for example, there's no password in sight and yet you're still able to compromise SSHD.
[07:52.880 --> 07:59.180]  The recent Debian OpenSSL vulnerability was also a good example where passwords, again, nowhere in sight.
[07:59.320 --> 08:03.880]  You have reduced entropy in the generation of keys and that affected SSH as well.
[08:05.020 --> 08:07.420]  So there's also the second bullet point.
[08:07.540 --> 08:25.880]  There was kind of an interesting article posted on the register that talked about a new strategy for where a coordinated attack against brute forcing passwords and SSH demons would be done via distributed systems that have all been compromised by an attacker or a set of attackers.
[08:26.140 --> 08:32.460]  And only three attempts would come from an individual system in order to try to brute force a password.
[08:32.620 --> 08:36.360]  And once three attempts have been made, the next set of attempts would come from a different IP address.
[08:36.360 --> 08:46.720]  It's sort of the same classic technique where you would try to slip beneath an IDS port scan threshold by reducing the number of ports that you scanned or scanning over a longer period of time, that kind of thing.
[08:46.840 --> 08:50.100]  So they now apply this as well to SSH password guessing attempts.
[08:50.500 --> 08:55.700]  So that reduces the effectiveness of trying to threshold those failed login attempts.
[08:57.540 --> 09:03.520]  So personally, I'm a lot more concerned about a much more damaging exploit in SSHD.
[09:03.780 --> 09:09.920]  And so I don't allow anyone to connect through SSH until they've generated a valid SBA packet.
[09:11.340 --> 09:12.780]  So is it useful?
[09:14.500 --> 09:18.080]  I would say yes, and we'll talk about some trends in a second.
[09:18.380 --> 09:19.740]  There are many competing implementations.
[09:20.220 --> 09:23.260]  If you look at portknocking.org, there's about 30 of them in total.
[09:24.960 --> 09:29.500]  There's about five implementations that implement SPA-style authentication.
[09:29.780 --> 09:32.720]  And there's about, you know, another 25 portknocking implementations.
[09:33.020 --> 09:37.200]  Those five SPA implementations do it a little bit differently from project to project.
[09:37.300 --> 09:47.960]  The Tumblr project uses a hash payload, for example, whereas there's a netfilter module that does SPA specifically with, particularly within the Linux kernel itself.
[09:47.960 --> 09:51.540]  So there's no userland component running on the server side.
[09:54.860 --> 09:58.060]  And so let's talk about some trends.
[09:58.220 --> 10:03.400]  You know, it's kind of hard to quantify who is running portknocking or SPA.
[10:03.460 --> 10:07.200]  I can't go download in-map and scan for your portknocking instances.
[10:07.460 --> 10:09.620]  I mean, it's designed specifically to make that impossible.
[10:11.400 --> 10:13.320]  So what can we rely on?
[10:13.440 --> 10:16.620]  Well, I have some download statistics from my web server, cypherdyne.org.
[10:20.680 --> 10:23.800]  In 2006, got about nearly 3,000 downloads.
[10:24.040 --> 10:25.660]  2007, that more than doubled.
[10:26.620 --> 10:30.000]  And so far this year, it's nearly 10,000.
[10:30.080 --> 10:31.440]  And this year is only about half over.
[10:31.440 --> 10:32.920]  So I think the trend is up.
[10:33.440 --> 10:36.920]  And we can also look at trends from search engines.
[10:37.360 --> 10:40.510]  So, last month I released a tool I called Gootrude.
[10:41.260 --> 10:44.380]  You can, of course, download this at the link at the end of the slide.
[10:45.520 --> 10:57.020]  Which, what it does is once per day, it sends a set of search terms into Google and takes the number of hits in Google and trends those numbers over time.
[10:57.220 --> 11:03.260]  And so it generates GNUplot graphs of that search, the search results data.
[11:05.220 --> 11:09.320]  So, I wrote the first version of Gootrude about a year ago.
[11:09.540 --> 11:11.460]  I didn't release it because I wanted to collect some data.
[11:11.760 --> 11:18.980]  And so, if I graph the term single-packet authentication, not authorization, but authentication in this case.
[11:21.080 --> 11:29.820]  Starting from July of last year going through July of this year, it's gone from about 200 search results in Google up to over 1,600.
[11:33.960 --> 11:38.060]  Single-packet authorization, which is a term that FWNOP uses specifically.
[11:38.420 --> 11:44.420]  FWNOP does, of course, both authentication and authorization, which are not the same thing.
[11:46.420 --> 11:51.880]  And the trend back in July of 2007, maybe 1,000.
[11:52.280 --> 11:53.880]  Kind of hard to even see the red on that graph.
[11:54.020 --> 11:58.460]  But then you get this strange sort of oscillation effect coming from Google.
[11:58.540 --> 12:07.880]  That's probably more an artifact of how Google builds its index versus, you know, say here in late June, a spike of 60,000 websites referenced single-packet authorization.
[12:07.880 --> 12:15.220]  And then within the next two days, all those, you know, 50,000 of those websites went away in Google's index, right?
[12:15.480 --> 12:18.660]  So, kind of interesting how Google built its index.
[12:19.220 --> 12:25.560]  I wish I had had Goutrude when I first released FWNOP, but I didn't until a year ago.
[12:25.880 --> 12:29.540]  But here's the graph of what the FWNOP term looks like.
[12:29.540 --> 12:38.640]  Of course, if you're involved in any open source projects or thinking of starting one, it's good to pick a unique string so you can do this kind of analysis via search engines.
[12:38.860 --> 12:41.180]  It's very, you know, FWNOP is pretty unique.
[12:41.420 --> 12:47.960]  So, it's easy to get a sense of what search engines really see it as, instead of having lots of other overlapping data.
[12:49.910 --> 12:57.040]  So, I'd say SBA usage is probably up, but long or widespread deployment probably has a long way to go, too.
[12:57.670 --> 13:05.100]  If any of you have some good statistics that you would like to discuss or share with me, I'd be really interested.
[13:08.820 --> 13:14.480]  Support within Linux distributions or other platforms is, I think, going to be a driver for this technology.
[13:15.780 --> 13:19.000]  FWNOP supports IP tables and IPFW, like I mentioned.
[13:19.160 --> 13:29.600]  There's also a Windows client, and there are plans to integrate it with things like the OpenWRT Linux distribution by rewriting FWNOP in C, making it much more lightweight.
[13:29.840 --> 13:30.660]  It's currently in Perl.
[13:33.220 --> 13:40.840]  And there's, I think, a really interesting open question, which is, you know, to what extent are these technologies used by the Black Hat community?
[13:41.440 --> 13:42.800]  Do botnets use them?
[13:42.800 --> 13:49.810]  There's been some anecdotal evidence that seems to indicate that port knocking is used, or has been used from time to time, but it's kind of sketchy.
[13:50.720 --> 13:52.100]  There isn't a lot of data there.
[13:52.180 --> 13:54.180]  I think this would make a great topic for a research paper.
[13:57.550 --> 13:57.910]  Okay.
[13:57.990 --> 13:59.090]  So, let's switch gears a little bit.
[13:59.170 --> 13:59.930]  Any questions so far?
[14:03.240 --> 14:03.600]  Yes.
[14:11.180 --> 14:11.540]  Oh,
[14:15.340 --> 14:15.460]  okay.
[14:15.500 --> 14:19.130]  So, the question was, any plans to integrate with packet filter, meaning the PF firewall and OpenBSD?
[14:19.580 --> 14:21.360]  Yes, that's on the to-do list specifically.
[14:21.580 --> 14:22.220]  That will be done.
[14:23.670 --> 14:26.360]  And also, plans to integrate it within the iPhone?
[14:26.480 --> 14:26.940]  Was that the question?
[14:27.320 --> 14:32.840]  I don't know much about what capabilities the iPhone has for packet filtering.
[14:33.000 --> 14:38.540]  Presumably, it has IPFW in the kernel because it's running on Mac OS X.
[14:38.540 --> 14:41.240]  But I don't actually have one yet.
[14:41.460 --> 14:45.580]  So, if you'd like to provide a development platform, I'd love to contribute.
[14:47.940 --> 14:51.320]  Oh, as a client.
[14:51.800 --> 14:52.800]  Yeah, you...
[14:52.800 --> 14:53.440]  If anyone...
[14:53.440 --> 14:55.120]  Does anyone know if Perl runs on the iPhone?
[14:55.380 --> 14:55.640]  Yes.
[14:56.180 --> 14:56.440]  Okay.
[14:56.640 --> 14:59.560]  Well, in that case, it probably would work right now.
[15:01.230 --> 15:01.560]  The...
[15:02.090 --> 15:05.420]  FWNOP comes bundled with all the necessary Perl modules to get it to work.
[15:05.580 --> 15:07.240]  There is a dependency on...
[15:08.970 --> 15:11.980]  Actually, there's a lot more dependencies on the server side than there are on the client side.
[15:12.140 --> 15:14.700]  So, I would anticipate that you could probably get that to work today.
[15:15.280 --> 15:21.080]  In fact, if you would like to try that and send me an email, I'd love to, you know, make a blog post about it and reference your website or whatever.
[15:21.600 --> 15:22.840]  That's a great question.
[15:22.840 --> 15:23.700]  I just have...
[15:23.700 --> 15:26.780]  I don't have anyone tell me so far that it definitely does work.
[15:26.940 --> 15:28.620]  But if you're the first, I'd love to know about it.
[15:31.080 --> 15:31.560]  Okay.
[15:31.780 --> 15:39.060]  So, let's just do a little basic comparisons here and try to highlight the real differences between port knocking and SPA.
[15:41.380 --> 15:45.980]  So, let's take the most simple possible port knock sequence.
[15:45.980 --> 15:58.040]  And that is, we're going to say that if a TCP send packet is received on port 12345, then we'll grant access to, let's just say, SSH from the source IP that generated that packet.
[15:58.500 --> 16:03.200]  And this is a shared sequence between the server side and the client side.
[16:03.280 --> 16:04.700]  And it has a few advantages.
[16:05.300 --> 16:11.380]  The first, the foremost being that this can be implemented in the simplest possible way on the server side.
[16:11.380 --> 16:16.600]  Only 16 bits of incoming information is really significant and has to be processed by the server.
[16:16.860 --> 16:20.300]  Pretty hard to put an overflow exploit in 16 bits of information, probably.
[16:22.500 --> 16:24.220]  LibPCAP is also, of course, not required.
[16:24.360 --> 16:25.920]  We can just parse a firewall log file.
[16:26.100 --> 16:29.040]  That's not typically a dangerous operation.
[16:29.920 --> 16:33.520]  And any web browser, even, could be your port knocking client.
[16:33.640 --> 16:38.060]  You don't have to have any specific, special software on the client side to generate such a sequence.
[16:38.800 --> 17:00.240]  And also, an attack... and a pretty effective attack against port knock sequences in general is the fact that since it's a sequence, typically, you... if an attacker can eavesdrop on your traffic, they can spoof a packet to a... to the last port they just saw in the sequence and they can thereby convince the server side that they... that the client doesn't really know the valid sequence and
[17:00.240 --> 17:03.020]  therefore deny access to the real client.
[17:03.760 --> 17:06.440]  So you can't do that when only a single packet is involved.
[17:06.940 --> 17:07.920]  So, disadvantages?
[17:09.200 --> 17:09.660]  Well...
[17:10.470 --> 17:14.540]  Nmap now becomes my... as an attacker, my port knock client.
[17:14.680 --> 17:15.960]  I'll just Nmap the target twice.
[17:16.800 --> 17:20.660]  From the first... of course, Nmap doesn't scan every single port by default, but...
[17:21.140 --> 17:22.840]  I can certainly make it do that if I like.
[17:23.380 --> 17:28.620]  Scan every port, and then scan the target again, and see what... what server ports are now open to me.
[17:30.380 --> 17:33.500]  I don't really want to make Nmap my port knock client.
[17:37.240 --> 17:40.280]  So, this still has some measure of security, of course.
[17:40.460 --> 17:44.240]  I mean, sort of analogous to running SSH on a different port, that kind of thing.
[17:44.540 --> 17:55.940]  If you've got any sort of automated attack out there against SSH that doesn't combine such a port scan, this... you know, it's probably not going to pick up that it has to scan this particular port before gaining access.
[17:57.100 --> 17:58.720]  So, let's step it up a little bit.
[17:59.380 --> 18:06.260]  The first version of FWNOP combined port knocking and passive OS fingerprinting, and it did this across IP tables log messages.
[18:07.780 --> 18:25.180]  But, the basic concept is to have multiple packets that can involve multiple protocols, and also fingerprint the packets... the send packets coming in in the same way that POF does, to only grant access to particular networking stacks that have been fingerprinted.
[18:25.180 --> 18:27.520]  So, like, for example, the Linux 2.6 kernel.
[18:30.140 --> 18:30.700]  Disadvantages.
[18:32.360 --> 18:33.380]  Well, I'm sorry.
[18:33.480 --> 18:34.000]  Advantages.
[18:34.260 --> 18:37.420]  Breaking the knock sequence typically requires eavesdropping.
[18:37.840 --> 18:49.300]  You're probably not going to get Nmap to generate this particular sequence of packets that even involve ICMP as well, and let's say an orphan packet in this particular sequence.
[18:49.400 --> 18:50.860]  That's fairly unusual.
[18:50.860 --> 19:01.380]  But, I should note, of course, and probably everyone here does, that it's not a good idea to assume that your packets are not being monitored.
[19:02.300 --> 19:03.840]  I always assume that.
[19:04.000 --> 19:06.220]  I try to, even though I can't always protect against everything.
[19:07.920 --> 19:11.200]  And, just as an example here, you know, I say plus POF.
[19:11.480 --> 19:28.580]  If you look at the IP tables log message down here at the bottom of the screen, the log TCP options command line argument to IP tables will have it log the options portion of the TCP header, and combine that with the fact that POF really only needs a few things that include the TTL value and the TCP window size and the options fields,
[19:28.580 --> 19:34.820]  you can now completely do everything that POF does, but just use IP tables logging messages to do it.
[19:34.940 --> 19:36.300]  Its source of data is the same.
[19:40.650 --> 19:45.610]  So, well, disadvantages, and this applies also to encrypted port knock sequences.
[19:46.010 --> 19:57.810]  Any sequence that involves multiple packets like this to different ports looks like a common, malicious activity known as a port scan to any intermediate IDS that may be watching the packets from the client to the server.
[19:59.290 --> 20:05.290]  Also, sequence replay is trivially possible whenever eavesdropping is involved.
[20:05.450 --> 20:12.650]  There have been some strategies to try to mitigate or make replay attacks across port knocking implementations a little bit more difficult.
[20:12.830 --> 20:21.870]  For example, S-key style iteration of a hashing function, but they're not really that scalable, I'd say, and sort of difficult to apply to lots of users.
[20:23.670 --> 20:26.670]  So, you know, it's difficult.
[20:26.890 --> 20:31.190]  It's hard to get port knock sequences to not be vulnerable to replay attacks.
[20:33.550 --> 20:35.730]  And also, this is strictly a shared sequence, of course.
[20:35.830 --> 20:38.110]  We're not talking about using any encryption yet.
[20:38.670 --> 20:38.810]  Okay.
[20:39.030 --> 20:40.410]  So, next iteration.
[20:40.670 --> 20:46.030]  You can, however, encrypt port knock sequences and combine those with POF at the same time.
[20:46.030 --> 20:51.090]  And this probably represents the height of port knocking.
[20:51.610 --> 20:56.830]  You've got encrypted data as well as stack fingerprinting involved.
[20:59.590 --> 21:03.090]  And, again, this can be implemented within firewall logs.
[21:03.250 --> 21:10.850]  So, your complexity is lower, generally, than something that must sniff a network directly with libpcap, for example.
[21:13.430 --> 21:21.930]  But, block sizes and Rijndael and things now require you to have a certain minimal length to your port knock sequence.
[21:22.490 --> 21:26.790]  And that makes it really look like a port scan to an IDS.
[21:27.150 --> 21:31.250]  So, I don't typically like trying to set off IDS alarm bells.
[21:31.330 --> 21:37.050]  And I'm really only just trying to gain access via this passive mechanism on the server side.
[21:37.050 --> 21:42.870]  I personally know someone who was working at a company I worked for once upon a time.
[21:43.090 --> 21:47.390]  And he used to like to scan his remote systems from work.
[21:48.390 --> 21:55.290]  Because he wanted to try to verify that his firewall was currently working and that the system wasn't responding to ports that it shouldn't be.
[21:55.670 --> 22:00.430]  And he was fired because of the local security policy at my company, unfortunately.
[22:03.370 --> 22:06.310]  And if he were using port knocking, he wasn't...
[22:06.310 --> 22:10.270]  I mean, the intent of what he was doing would not have even been to scan his system.
[22:10.290 --> 22:13.430]  But it would look indistinguishable to the security team.
[22:13.430 --> 22:17.510]  Because it would really look like... there's no difference between a port knock sequence and a scan.
[22:17.630 --> 22:18.710]  It really does look like a scan.
[22:19.090 --> 22:23.950]  He would have had a hard time, I think, convincing the security team that that's what he was really doing.
[22:27.190 --> 22:34.930]  Okay, so... single packet authorization, in contrast, it's fast.
[22:35.130 --> 22:39.870]  You don't have to build in any time delays between successive packets because there's only one packet involved.
[22:40.210 --> 22:42.570]  It has a minimal network footprint.
[22:42.970 --> 22:44.770]  It doesn't look like a port scan.
[22:47.010 --> 22:52.690]  You have access to use a lot more data, given MTU sizes on networks.
[22:52.910 --> 22:56.070]  So you can encode a lot more information, including full commands.
[22:56.230 --> 22:57.290]  FWNOP supports that.
[22:58.490 --> 23:05.810]  And at this point, you really, really require eavesdropping in order to break SBA authentication.
[23:06.170 --> 23:18.030]  And by breaking it, what I really mean is that you have the capability of cryptanalyzing packets that are encrypted with Reindal or with GNUPG, which is not an easy thing to do, of course.
[23:19.490 --> 23:23.110]  And no two SBA packets are the same.
[23:23.290 --> 23:29.290]  Replay attacks are elegantly made infeasible in SBA implementations.
[23:34.600 --> 23:38.380]  However, the code complexity to accomplish that is higher.
[23:40.060 --> 23:44.420]  And therefore, I think that there is some room for port knocking implementations still.
[23:44.420 --> 23:47.520]  It really depends on where you draw the line.
[23:47.760 --> 23:54.360]  Do you consider that passive sniffing is the most important thing to be concerned about?
[23:54.560 --> 23:58.420]  Do you consider that replay attacks are the most important thing to be concerned about or not?
[24:02.040 --> 24:06.380]  The...so even...I should note, however, that we're still talking about a passive mechanism.
[24:06.540 --> 24:08.800]  It's not as though you can scan for your SBA server.
[24:08.800 --> 24:17.240]  And indeed, with the 1.9.6 release, it's even harder to even detect that SBA is actually in use on a particular network.
[24:17.240 --> 24:20.240]  Even if you're monitoring all the data, all the traffic.
[24:20.740 --> 24:21.820]  We'll see that in a minute.
[24:24.900 --> 24:28.140]  So...with GNUPG, we can even extend things further.
[24:28.540 --> 24:32.620]  Typically, I use a 2048-bit GNUPG key for my SBA packets.
[24:33.620 --> 24:37.940]  And you can use important GNUPG keys, GPG keys.
[24:38.740 --> 24:41.620]  It's just used for message signing on the client side.
[24:41.620 --> 24:44.920]  So you don't need to generate a new key on the client side.
[24:44.940 --> 24:50.020]  Although you should generate an unimportant server side key for this.
[24:50.280 --> 24:52.900]  Because FWNOP needs access to the password.
[24:52.900 --> 24:56.820]  So it can decrypt on the server side the incoming data.
[25:01.530 --> 25:04.550]  In this one, code complexity is probably the highest.
[25:04.910 --> 25:07.850]  We have in-pearl implementations of Rijndael.
[25:08.770 --> 25:18.250]  In the case of FWNOP, it actually requires a functioning installation of GPG on the server side if you want to do SBA packets encrypted with GPG.
[25:20.870 --> 25:23.410]  So I kind of like to think about it like this.
[25:23.990 --> 25:27.270]  This isn't exactly a scientific graph, whatever.
[25:27.270 --> 25:38.330]  But if you think of protocol limitations versus complexity, I would say that SBA with GNUPG is probably the most complex.
[25:38.330 --> 25:43.170]  But it also has the most benefits in terms of limiting the limitations in the actual protocol itself.
[25:44.570 --> 25:53.670]  And I like to draw the arrow sort of at the lower left there really, really low in the sense that I assume that packets are being sniffed all the time.
[25:54.750 --> 25:59.750]  And off to the right-hand side, protocol limitations are the greatest as we've seen.
[26:00.730 --> 26:06.230]  Detection by IDS is ability to DOS the FWNOP or the port knocking server.
[26:07.290 --> 26:11.150]  And replay attacks are the chief ones probably.
[26:13.390 --> 26:15.070]  So any questions on that?
[26:16.250 --> 26:16.810]  Yes?
[26:22.440 --> 26:27.080]  Would it be possible to basically use the actual .
[26:30.040 --> 26:33.380]  Basically using all the fields that you want to?
[26:37.710 --> 26:41.870]  You could have a smaller amount of data that you could get out of it, but you could have some .
[26:45.390 --> 26:45.950]  Yeah,
[26:49.070 --> 26:51.930]  so I think it's Jake, right?
[26:53.170 --> 26:58.510]  He's pointing out that you've got a lot of information, a lot of bits in the TCP header that you can play with.
[27:00.710 --> 27:12.630]  And given that all that information is logged via IP tables, he's pointing out that you could probably use that as a covert channel and not therefore require some more complex application layer information correct.
[27:12.630 --> 27:13.470]  Okay.
[27:13.950 --> 27:14.070]  Yeah.
[27:14.570 --> 27:21.230]  The question becomes though, how many bits do you really need in order to thwart a replay attack?
[27:21.470 --> 27:22.170]  I would say.
[27:22.470 --> 27:28.070]  And so the initial implementations of FWNOP included...
[27:28.070 --> 27:31.730]  Actually, they all include 16 bytes worth of random information.
[27:32.170 --> 27:34.490]  Do I require 16 bytes to make everything random?
[27:34.650 --> 27:35.090]  No.
[27:35.350 --> 27:47.070]  But as soon as I start things, you know, if I reduce the number of bits that are necessary there, I start to make it a little bit more easy to conduct a replay attack.
[27:47.190 --> 27:55.130]  Although, you know, probably some experimental verification would need to be made or a theoretical argument would need to be made to see how practical that really would be.
[27:55.330 --> 27:56.030]  I mean, I agree with you.
[27:56.110 --> 27:59.350]  There's lots of bits of information that TCP headers allow.
[28:02.690 --> 28:15.120]  So, the thing is you're also starting to say, well, if I need to actually change bits in the TCP header, I'm probably not at that point going to just be able to use the TCP stack on the local system.
[28:15.540 --> 28:29.160]  So, if I require changing something in the options portion of the header that the local stack doesn't allow me to change, I can't use just a simple user space, you know, applications such as a web browser to construct that packet.
[28:29.160 --> 28:33.800]  You know, I probably need a raw socket with access to the options portion.
[28:33.920 --> 28:34.940]  I have to craft that myself.
[28:35.720 --> 28:37.980]  You know, do you have user access controls at that point?
[28:38.060 --> 28:38.860]  Do I need root, et cetera?
[28:39.320 --> 28:52.860]  So, I would say you could certainly come up with an implementation that would conduct a covert channel over just raw TCP header information.
[28:52.860 --> 29:00.700]  But, how much information you're going to be able to include in that, and stop replay attacks, and introduce encryption if you like.
[29:01.280 --> 29:06.940]  I think, at that point, you might need to have more information than what the TCP header allows.
[29:07.240 --> 29:08.080]  That's my gut feeling.
[29:10.380 --> 29:12.240]  Okay, so, switching gears a little bit.
[29:12.540 --> 29:13.840]  Detecting SPA traffic.
[29:19.470 --> 29:27.550]  So, FWNOP sends UDP packets by default for SPA communications over port 62201.
[29:28.390 --> 29:34.950]  Any SPA packet is typically going to be at least 150 bytes long, in its encrypted Base64 encoded form.
[29:35.470 --> 29:52.590]  So, a SNORT rule, such as you see at the top here, looking for any UDP packet to destination port 62201, at least 150 bytes long, and contains the following PCRE that's looking for trailing equals characters at the end of the packet.
[29:53.390 --> 29:58.830]  Those trailing equals characters are produced as an artifact of Base64 encoding.
[29:59.170 --> 30:18.390]  So, Base64 encoding works by taking raw data, encoding it into plain ASCII, a set of plain ASCII characters, and if the resulting encoding is not a multiple of four bytes, then it will pad that data with equals characters to make it a multiple of four bytes.
[30:18.550 --> 30:25.550]  So, you can end up with anywhere from one to three equal signs, or zero if the encoded data is already a multiple of four bytes.
[30:25.870 --> 30:32.130]  So, I've just chosen to look for two equals characters at the end of this UDP packet.
[30:33.330 --> 30:36.490]  Incidentally, you might say, well, why use a PCRE for this?
[30:36.570 --> 30:38.870]  Because PCRE is kind of expensive, and that's, of course, true.
[30:40.310 --> 30:44.610]  But, unfortunately, ByteDumpJump does not work at the transport layer header.
[30:44.750 --> 30:51.010]  So, I can't make it take the length field of the UDP header and use that as an operator to get to the end of the packet data.
[30:51.230 --> 31:00.530]  So, using this equals... this PCRE expression with this dollar sign allows me to do the same thing, but it's a slightly more expensive operation just because I have to appeal to the PCRE library.
[31:00.530 --> 31:13.210]  If somebody knows how to get snort... write a snort signature to look for the last byte, and test that byte for a particular value, but not require looking at the header at the same time, you know, please let me know.
[31:13.930 --> 31:14.890]  Maybe there's a way to do it.
[31:16.390 --> 31:16.790]  Okay.
[31:17.030 --> 31:18.010]  So, that's the first thing.
[31:18.170 --> 31:22.570]  So, Base64 encoding is used by all FW0 packets sent by the client.
[31:24.090 --> 31:25.690]  But, we can do a little bit better than that.
[31:25.690 --> 31:33.130]  An artifact of the CryptCVC module is that it tries to maintain parity with the OpenSS...
[31:33.130 --> 31:35.410]  how OpenSSL encrypts data.
[31:35.630 --> 31:45.130]  So, there's this static string, salted underscore underscore, that's typically used in the encrypted data.
[31:45.310 --> 31:48.910]  And when that's Base64 encoded, it shows up with this...
[31:48.910 --> 31:52.690]  as this nice 10-character string, UTF, SD, etc.
[31:53.590 --> 31:59.050]  And so, as I was looking at a bunch of SVA packets, I saw, wow, this is sort of invariant section right at the beginning.
[31:59.170 --> 31:59.990]  You know, what the heck is that?
[32:00.330 --> 32:06.410]  I wasn't expecting that, considering that every single SVA packet includes 16 bytes of random data right at the beginning.
[32:07.410 --> 32:11.530]  But, that was being generated, you know, by the encryption algorithm itself.
[32:12.390 --> 32:22.250]  And so, looking for that, for any pre-1.9.6 version of FWNOP, you can write a snort rule that would have a good chance of detecting SVA traffic this way.
[32:24.170 --> 32:30.670]  So, here's an example of the raw encrypted data for an SVA packet.
[32:30.810 --> 32:32.830]  You can see that salted string right there at the beginning.
[32:35.370 --> 32:42.990]  And here's the Base64 encoded version of that packet with that string in the Base64 encoded form of it.
[32:43.370 --> 32:49.710]  There's no trailing equals characters in this particular case because the encoded information was exactly a multiple of four.
[32:49.970 --> 32:50.950]  So, it didn't need it.
[32:53.840 --> 32:57.720]  So, we can also do a similar technique for GNUPG encrypted data.
[32:57.860 --> 33:11.740]  If you look at the magic database used by the file command, you'll see that it infers that any file that begins with hex 8502 corresponds to data that's been encrypted with GNUPG.
[33:12.160 --> 33:16.100]  And the Base64 encoded version of that is this nice HQ string.
[33:16.560 --> 33:29.240]  I've also included a D size requirement of greater than a thousand bytes because once you start to use GNUPG keys, the SVA packets typically are a little bit larger.
[33:29.500 --> 33:31.200]  So, they're usually over about a thousand bytes.
[33:31.200 --> 33:32.740]  I use a 2048 bit key myself.
[33:34.320 --> 33:40.700]  And here is a sort of abbreviated version of what that packet looks like.
[33:40.800 --> 33:41.640]  It begins with HQ.
[33:41.940 --> 33:52.240]  And in this case, ends also with the trailing equals sign because the original data was 1,043 bytes long, but it had to make it 1,044 bytes long to be a multiple of four.
[33:53.720 --> 33:54.280]  Okay.
[33:54.580 --> 34:02.260]  So, it turns out that it's easy to sort of stop this, remove these invariant sections.
[34:02.540 --> 34:03.060]  Yes, question?
[34:03.380 --> 34:03.800]  Yes.
[34:09.030 --> 34:15.810]  So, the question was, would there be any MTU size problems with having such a large application layer payload?
[34:18.370 --> 34:25.880]  I've done a lot of traveling and so far I have yet to encounter a network that does not handle that well.
[34:26.730 --> 34:30.390]  I mean, your typical MTU size underneath that network is not going to be a problem.
[34:30.390 --> 34:40.010]  You know, there are other network, you know, data link layer protocols too that could become involved, but I have yet to see that become a problem.
[34:40.390 --> 34:41.790]  So, typically no.
[34:46.850 --> 34:55.910]  So, the 1.9.6 version of VWNOP takes these invariant sections, it strips them out completely before sending the packet data out on the wire.
[34:55.910 --> 35:04.090]  The server side then says, okay, I've got this now totally random looking blob of hex or ASCII data.
[35:04.390 --> 35:17.890]  And it adds back, it adds those invariant sections back in before attempting to do as basic for decoding or decrypting for Rijndael packets or GNUPG packets.
[35:19.850 --> 35:25.890]  And therefore, those start rules now become ineffective against this latest release of FWNOP.
[35:27.950 --> 35:34.170]  Also, there are sort of, I would say, comprehensive port randomization features now with an FWNOP.
[35:34.590 --> 35:44.550]  And this applies both to the destination port of the SBA packet itself, as well as the port that you choose to make your SSH connection over.
[35:44.650 --> 35:53.650]  So, if you want FWNOP to create a randomly designated port that's port forwarded to your SSH server, you can do that as well.
[35:53.810 --> 36:02.290]  And that applies both to local connections to the local system, as well as forwarded connections to internal SSH servers that are not otherwise accessible.
[36:02.970 --> 36:06.070]  And if I can get this demo to work, I should show you an example of that.
[36:07.290 --> 36:09.730]  So, just a slide on what I mean here.
[36:11.490 --> 36:14.690]  Here's the top command line that you should use with FWNOP.
[36:14.690 --> 36:18.350]  I want access... let's assume I'm on a routable network somewhere.
[36:18.590 --> 36:22.770]  I want access to this internal 192.168.10.22 server.
[36:23.030 --> 36:25.310]  In particular, I want access to SSH on that server.
[36:25.550 --> 36:35.570]  But I'm going to randomize both the destination port for the SBA packet, as well as the port that I want to connect to SSH over.
[36:35.690 --> 36:42.570]  In this case, FWNOP assigns me port 3394, which I will use on the SSH command line to make the connection.
[36:43.350 --> 36:49.190]  So, not that port randomization really makes things difficult to analyze.
[36:49.470 --> 36:53.210]  It's just an additional... it raises the bar just a little bit more.
[36:53.350 --> 36:59.710]  I can't always assume that my connections are going to go over TCP port 22 for SSH.
[37:00.310 --> 37:02.370]  FWNOP can make that unpredictable.
[37:05.670 --> 37:09.030]  Okay, so let's talk about an attack against SBA.
[37:09.810 --> 37:12.450]  This one, I think, was particularly elegant.
[37:13.230 --> 37:15.210]  It came out two years ago, 2006.
[37:15.410 --> 37:18.350]  It's featured in a master's degree written by Sebastian Jean-Quier.
[37:18.470 --> 37:20.090]  I'm sorry if I'm mispronouncing your name.
[37:22.110 --> 37:30.150]  And basically, the FWNOP daemon had no notion of maintaining a time stamp on incoming SBA packets.
[37:30.150 --> 37:39.510]  So, an attacker that possessed an inline device to an SBA packet could intercept one, store it off on disk somewhere, let's say.
[37:40.330 --> 37:46.850]  And the client side, well, it sent this SBA packet across, but, of course, SBA is never acknowledged.
[37:46.850 --> 37:50.790]  So, when the follow-on SSH connection was attempted, it wasn't allowed.
[37:50.790 --> 37:56.490]  Well, the client probably just realized, oh, well, maybe my packet got lost somewhere or whatever.
[37:56.790 --> 38:01.110]  So, the client sends a new SBA packet, which is now different.
[38:01.430 --> 38:03.910]  The attacker says, oh, that's okay, I'll let this one through.
[38:04.390 --> 38:14.190]  And then the server side would open up port 22, and the client would have no way to know that the original SBA packet that was seen was intercepted.
[38:14.190 --> 38:19.750]  And the daemon side, the FWNOP daemon side, was unable to see that original SBA packet.
[38:19.870 --> 38:26.170]  So, there's no way it could do a SHA-256 comparison against a new SBA packet to detect a replay attack.
[38:26.410 --> 38:48.470]  Which means that if, at the same time, the client used dash S on the command line to force the FWNOP daemon to trust the source IP in the IP header, the attacker could retransmit that SBA packet payload from a different source IP and gain the same level of access as the original attempt.
[38:49.410 --> 38:52.450]  Elegant attack, FWNOP is no longer vulnerable.
[38:53.950 --> 39:04.630]  It encodes the source address that you want access to within the encrypted data itself, and it maintains a timestamp for all incoming SBA packets.
[39:05.610 --> 39:13.670]  But, if you know of another exploit against the SBA architecture, you know, I'd love to have some feedback from the community about the architecture.
[39:13.870 --> 39:14.870]  So, please let me know.
[39:18.380 --> 39:19.980]  Let's see, running short on time here.
[39:20.160 --> 39:22.520]  So, this is the 1.9.6 release.
[39:22.680 --> 39:23.660]  There are a few additional things.
[39:24.600 --> 39:33.700]  In trying to write both client-side and server-side software like this, I've come to realize that a test suite is really, really important.
[39:35.400 --> 39:40.120]  And there is now a test suite support for port-knocking mode as well as SBA mode, of course.
[39:40.380 --> 39:42.800]  There's about... I think there's about 180 tests in there or something like that.
[39:42.920 --> 39:44.280]  But, anyway...
[39:45.360 --> 39:46.100]  Was there a question?
[39:47.320 --> 39:47.680]  Okay.
[39:51.480 --> 39:54.660]  Upcoming developments, I mentioned before, it's being rewritten in C.
[39:55.900 --> 39:59.080]  I was hoping to try to get that done by this conference, but just couldn't quite finish it.
[40:00.180 --> 40:05.200]  But, it will be ported to OpenWrt as well as Packet Protector and other embedded distributions.
[40:06.180 --> 40:08.540]  It would be nice to have some additional UI support in Java.
[40:10.240 --> 40:12.940]  This next to the last one here is, I think, kind of interesting.
[40:13.100 --> 40:22.860]  Now that FWNOP supports the interface to building port forwarding and NAT rules, I'm also going to add support for SBA proxying.
[40:22.860 --> 40:28.020]  So, you can essentially build up chains of NAT rules to a deeply buried SSH server somewhere.
[40:28.880 --> 40:32.520]  And, you know, with FWNOP instances at each hop.
[40:32.940 --> 40:38.860]  And it will build those rules automatically so that you can access, you know, from any routable network, you know, all the way down in.
[40:39.020 --> 40:39.640]  Yes, question?
[40:39.640 --> 40:46.760]  Yeah, that new proxy utility that you have, is that going to be leg by leg as you nest inside to an internal network?
[40:47.000 --> 40:51.020]  Or are you going to have internal information encoded in the original SBA?
[40:52.180 --> 40:59.940]  Yes, the question is, in that new proxy mode support, is it, is the information encoded leg by leg?
[41:00.100 --> 41:03.300]  Or is there, or is the original packet sent all the way through to the internal system?
[41:03.300 --> 41:09.640]  Yeah, so, this is, I'm still a little bit in the design phase for this particular feature.
[41:11.100 --> 41:13.000]  But, a couple things are clear.
[41:13.500 --> 41:24.300]  Each hop in the SBA path has to be able to, to, to, so if I send the original SBA packet all the way through, that's fine.
[41:24.460 --> 41:29.820]  But each hop also has to have a necessary key information to verify that it's, that it's a valid packet.
[41:30.580 --> 41:40.580]  I mean, I, at each hop, I could generate a new SBA packet with the same original information, with the exception of, let's say, the random number that's, that's included in the, in the, in the data.
[41:43.520 --> 41:45.600]  That's, it's still being worked out a little bit.
[41:45.820 --> 41:49.680]  I mean, there's, there's some details there that, that, that we can talk about offline, if you'd like.
[41:49.880 --> 41:50.460]  Thanks for the question.
[41:53.100 --> 41:53.460]  Okay.
[41:55.580 --> 41:58.320]  Okay, demo time, or keep going through some examples.
[41:59.580 --> 41:59.940]  Demo.
[41:59.940 --> 42:00.620]  What do you guys want?
[42:00.820 --> 42:01.180]  Demo.
[42:01.300 --> 42:01.440]  Okay.
[42:05.570 --> 42:08.810]  This may take me a little bit to set up here, because I wanted to show some specific information.
[42:15.690 --> 42:16.050]  Eh.
[42:17.110 --> 42:17.470]  Resolution.
[42:18.370 --> 42:18.730]  A
[42:21.780 --> 42:23.440]  lot of the stuff won't work for a stateful firewall.
[42:25.180 --> 42:27.720]  The question was, a lot of the stuff won't work for a stateful firewall.
[42:27.960 --> 42:28.920]  Um, it actually depends.
[42:29.700 --> 42:36.300]  And, of course, a stateful firewall is, is, is the, the most, sort of, nice way of using this, because it keeps your connection live.
[42:36.300 --> 42:38.560]  Well, we're, we're, we're, we're shutting the original accept rule down.
[42:39.080 --> 42:40.120]  Uh, but you, but you.
[42:40.120 --> 42:40.220]  But you.
[42:40.220 --> 42:40.280]  But you.
[42:40.600 --> 42:42.040]  It supports client-derived timeouts.
[42:42.440 --> 42:50.560]  So, if you want, um, if, if you, if you, if you want the firewall to, to accept your SSH connection for five days, you can do that.
[42:50.560 --> 42:52.860]  Uh, if you configure the server to allow that.
[42:53.060 --> 42:56.780]  But it just works through a stateful firewall, because if I have a PICS or a NETS or a NETS or a
[43:02.120 --> 43:03.300]  NETS?
[43:03.300 --> 43:07.920]  Yeah, the question was, um, it won't work for something like a Cisco or a PICS or, you know, getting packets through.
[43:08.400 --> 43:19.500]  Um, there, the basic requirement is that a UDP packet, uh, to the, whatever destination port the client, uh, designates, is sent through, at some point, and monitored by an FWNOP instance.
[43:19.500 --> 43:24.500]  So, and, you know, there's some, there's some details there, but it, it should work, typically.
[43:25.900 --> 43:26.730]  Just another observation.
[43:27.380 --> 43:39.680]  It seems that the, um, facilities with the latest release are in place to, um, to, uh, supporting a UDP hole-punching method behind, to authorize...
[43:40.920 --> 43:49.480]  Uh, the description was, uh, the support in the, in the, in the, in the new, uh, FWNOP 1.9.6 release, uh, was designed to use a UDP hole-punching method.
[43:49.500 --> 43:52.040]  In conjunction with TCP connections?
[43:52.320 --> 43:53.220]  Or, I'm not quite sure I...
[43:55.660 --> 44:14.120]  Yeah, um, the, the, um, the access, so, so once the UDP packet is sent by FWNOP, actually, you can send it over to TCP or ICMP2, but, but, if it's a UDP packet, FWNOP daemon monitors that packet, the access that's, that is requested, whether that is a TCP port access or UDP port access,
[44:14.280 --> 44:16.960]  it doesn't, it's, that's encoded in the packet itself by the client.
[44:19.660 --> 44:23.800]  So, I'm gonna try to, uh, demo this.
[44:31.140 --> 44:31.700]  What's that?
[44:32.020 --> 44:33.200]  Oh, make this bigger.
[44:33.200 --> 44:34.760]  Oh, make this bigger, okay.
[44:35.300 --> 44:38.740]  Um, actually, here.
[44:41.000 --> 44:41.700]  Is that better?
[44:41.900 --> 44:42.700]  Can you see that?
[44:47.300 --> 44:50.480]  Okay, so, just a quick mention of the, of the architecture here.
[44:50.480 --> 44:51.140]  Um,
[44:56.420 --> 44:59.100]  there are, there are two systems involved here.
[44:59.260 --> 45:02.300]  The two separate systems down here, where I have the cursor, uh, down here.
[45:02.400 --> 45:05.200]  This is a, this is a FreeBSD system running under, underneath VMware.
[45:05.480 --> 45:06.860]  It's running the FWNOP client.
[45:07.180 --> 45:11.380]  Um, I have an Ubuntu Linux system that's running, uh, that's on these two windows up here.
[45:11.380 --> 45:13.000]  That's running the FWNOP server.
[45:24.250 --> 45:25.050]  And, jeez.
[45:35.850 --> 45:37.010]  Oh, hold on a second.
[45:46.270 --> 45:47.950]  I don't think I'm going to be able to.
[45:48.870 --> 45:53.730]  This, this, um, I have some trouble with the mouse here.
[45:54.450 --> 46:01.430]  Okay, just, uh, just, in the bottom window, what I've shown here is just that I'm, the IP tables is filtering my incoming connection to port 22, okay?
[46:01.950 --> 46:06.490]  So, the input chain is not allowing the connection from the BSD system to the Ubuntu Linux system.
[46:07.190 --> 46:08.630]  So, FWNOP is running over here.
[46:09.050 --> 46:28.890]  Now, what I'm going to do is, I'm going to, I'm going to use FWNOP in, in, in NAT mode here, to create an, uh, a DNAT rule for a randomly assigned port over which SSH will be accepted from the FWNOP client system, the FreeBSD system.
[46:33.290 --> 46:37.330]  So, as you can see down here, it's just assigned me a, a new port.
[46:38.250 --> 46:40.690]  So, 41194.
[46:43.170 --> 46:44.210]  MBR, Isengard.
[46:45.430 --> 46:47.090]  And so now I can log in.
[46:47.830 --> 46:50.910]  Host name Isengard, which is my Ubuntu Linux system.
[46:51.370 --> 47:07.810]  And as you can see over in this window, these are the syslog messages output by the FWNOP server, that you can see a DNAT rule for this particular, uh, 4194 TCP port to be NATed locally to port 22 for 40 seconds.
[47:08.870 --> 47:14.010]  I'm also interfacing, of course, with the, the IP table state tracking mechanism to keep my connection open.
[47:14.570 --> 47:24.130]  And after 40 seconds, FWNOPD has removed this input accept rule, so now any new connection that I attempt to make from the FreeBSD system will not be allowed.
[47:24.130 --> 47:27.670]  But, as you can see here, my, my session is still open.
[47:29.790 --> 47:35.510]  That illustrates, um, the advantage of using a stateful firewall for, for doing this kind of thing.
[47:35.510 --> 47:43.370]  So, if I quit, if I exit out, and I just test whether I have access to port 22, of course, I don't.
[47:46.600 --> 47:49.940]  And in this window, you know, what do you see?
[47:55.510 --> 47:59.790]  So, this is, this is the SBA packet.
[47:59.950 --> 48:03.230]  As you can see, the destination port was randomized to this value.
[48:03.490 --> 48:07.690]  If I were to dive into this packet, you would see that those invariant sections are also stripped up.
[48:07.690 --> 48:08.870]  I don't think I have time to show that.
[48:09.470 --> 48:12.410]  And then you can see the follow-on connection, which is actually SSH.
[48:13.830 --> 48:17.290]  But it's going over TCP port 41194.
[48:18.250 --> 48:19.230]  So, that's the demo.
[48:19.890 --> 48:21.550]  And, uh, any questions?
[48:24.230 --> 48:24.630]  Yes?
[48:24.850 --> 48:26.050]  Is that first packet UDP?
[48:27.190 --> 48:28.570]  Is the first packet UDP?
[48:28.710 --> 48:29.790]  Do you mean this one?
[48:29.990 --> 48:30.190]  Yes.
[48:30.470 --> 48:31.550]  Yes, that is UDP.
[48:32.010 --> 48:34.270]  Are all UDP, by definition, that first packet?
[48:34.870 --> 48:35.510]  I'm sorry, what?
[48:35.510 --> 48:38.630]  Are they all UDP, by definition, the first-time packet?
[48:38.670 --> 48:44.490]  The, the first, the SPA packet itself is, it's usually UDP by default.
[48:44.610 --> 48:50.250]  But you can use command line arguments to send, you can even send an SPA packet over to establish TCP connection, if you like.
[48:50.470 --> 48:52.070]  That's required to get it to work over Tor.
[48:52.970 --> 48:54.710]  But you can send it also over ICMP.
[48:54.870 --> 48:55.790]  It's not necessarily UDP.
[48:56.330 --> 48:57.510]  So, any other questions?
[48:57.750 --> 48:58.190]  Yes?
[48:58.510 --> 49:00.090]  Have you audited the parsers there?
[49:00.430 --> 49:01.650]  I'm sorry, I can't, I can't hear you.
[49:01.830 --> 49:04.330]  Have you audited any of the parsers that you're using?
[49:04.330 --> 49:07.070]  His question is, have I audited any of the parsers that I'm using?
[49:07.610 --> 49:09.010]  That's a, that's a great question.
[49:09.390 --> 49:16.090]  So, you're probably referring to NetPacket, for example, and the, the NetPCAP extension in Perl, and that kind of thing.
[49:16.930 --> 49:18.230]  I've looked at them a little bit.
[49:18.630 --> 49:19.990]  Would I say that they're secure?
[49:20.130 --> 49:21.130]  I'd say probably not.
[49:21.330 --> 49:31.590]  I mean, I, I'd say that's an area where rewriting in C, I think, is important to make sure that, you know, things are, are really well tested.
[49:31.730 --> 49:34.350]  I think using Valgrind against this code is going to be really important.
[49:34.950 --> 49:38.850]  Um, sort of not in the context of the OpenSSL problem.
[49:38.930 --> 49:41.530]  But anyway, um, that's, that's a great question.
[49:41.730 --> 49:44.470]  And that, that is a, a chink in the armor.
[49:44.770 --> 49:53.090]  There's nothing to say that there is not a vulnerability in either libpcap itself or in the parsers that this code is using.
[49:53.090 --> 50:01.130]  The, the main application is to make it, make the target identification phase of using Nmap, make that piece hard as possible.
[50:01.350 --> 50:02.190]  As hard as possible.
[50:02.690 --> 50:12.590]  Um, there could be an exploit waiting to happen in the FWNOP server side by virtue of the fact that it uses Perl modules that are also have C code in the back end, et cetera.
[50:12.730 --> 50:13.510]  That's certainly possible.
[50:14.230 --> 50:14.710]  Yes.
[50:14.870 --> 50:15.430]  Any other questions?
[50:17.210 --> 50:17.690]  Yes.
[50:31.420 --> 50:37.200]  Any solutions to, to audit a, a, a virtual system for a single packet authorization?
[50:37.340 --> 50:38.380]  I'm not quite, is that the question?
[50:38.440 --> 50:41.940]  Any guess where you can mess with the kernel and run the firewall?
[50:42.820 --> 50:49.720]  Yeah, um, so, there have been vulnerabilities in, in firewalls from time to time.
[50:50.020 --> 50:56.540]  Um, you know, met, there are integration points that you could, you could use within, within kernels.
[50:56.540 --> 51:04.440]  That are, they're running in, in a sort of, you know, virtual environment just because you've got access to IP tables and IPFW and things just like in, in running underneath VMware.
[51:05.080 --> 51:08.260]  But, um, I, I probably need to take your question offline because I'm not quite sure I got it.
[51:08.340 --> 51:09.640]  But anyway, I think I'm running out of time.
[51:09.900 --> 51:10.980]  But, uh, thank you very much.
[51:11.340 --> 51:11.920]  Thank you very much.