[00:00.000 --> 00:02.660]  You know, service that's discoverable by IMAP.
[00:02.760 --> 00:07.040]  And this is precisely what port knocking and SBA both are designed to limit.
[00:07.700 --> 00:15.560]  But they are not designed to do that at the expense of or in a way that adds to insecurity of software.
[00:18.400 --> 00:25.900]  So, fundamentally, I would say that both strategies fundamentally change the server-side exploit model.
[00:27.400 --> 00:35.620]  The typical workflow is usually people deploy this technology for the protection of SSH.
[00:35.840 --> 00:38.600]  But I've seen it deployed for all sorts of different services.
[00:38.920 --> 00:44.120]  You know, the various SMTP-related services, POP3, IMAP, et cetera.
[00:44.720 --> 00:48.100]  Anything that relies on a relatively long-running connection.
[00:48.280 --> 00:53.240]  And this can even apply to HTTP these days as HTTP moves to more persistent connections.
[00:54.440 --> 00:58.460]  But the typical workflow is they've got the service they want to protect.
[00:58.940 --> 01:07.500]  They have the ability to interact with a firewall to maintain a default drop stance for any connections to that service.
[01:07.700 --> 01:20.800]  But they will also deploy this port knocking or SBA mechanism in conjunction with the firewall to passively monitor either port lock sequences as they come in or single packet authorization packets.
[01:21.260 --> 01:28.500]  And then once they validate that incoming data stream, they will then reconfigure the firewall for temporary access.
[01:30.580 --> 01:35.940]  Neither port knocking nor SBA are designed to ever acknowledge anything.
[01:35.940 --> 01:41.040]  So, you as the user, you send off this packet into the ether essentially.
[01:41.660 --> 01:52.140]  And if it is not lost in route, if it's received and it's appropriately constructed, then you will then be able to connect to SSHD.
[01:52.840 --> 01:56.200]  But, you know, the original packets that you sent are never acknowledged.
[01:56.400 --> 01:57.520]  So, they're just silently dropped.
[01:58.820 --> 02:04.300]  And, you know, while most people use this to protect SSHD, I do this myself.
[02:04.580 --> 02:06.620]  You can certainly think beyond SSHD.
[02:06.740 --> 02:09.240]  There's no reason why it has to be limited just to that.
[02:11.480 --> 02:16.520]  This is where the similarities between port knocking and SBA systems essentially ends.
[02:21.220 --> 02:30.560]  So, there is a website, portknocking.org, that is kind of a listing of the current port knocking and SBA implementations.
[02:31.560 --> 02:34.620]  It's about 40 of them, I would say, in various levels of support.
[02:36.260 --> 02:42.960]  And, it's usually interesting just to go through and see, you know, what has been done in the past and where things might be going in the future.
[02:45.020 --> 02:46.980]  So, let's turn to FWNOP specifically.
[02:48.460 --> 02:51.740]  These are some of the design goals that FWNOP has had.
[02:51.900 --> 02:59.460]  So, the first three, the first two actually, this is something that you would see within port knocking systems as well.
[03:01.260 --> 03:05.280]  FWNOP also supports both symmetric and asymmetric ciphers.
[03:05.360 --> 03:09.660]  So, it supports Rijndael, if you choose, if you like the symmetric cipher route.
[03:09.760 --> 03:11.220]  And, it also supports GPG.
[03:11.400 --> 03:16.040]  So, you can have signed and encrypted GPG data that's sent across.
[03:16.220 --> 03:20.660]  And, you can take advantage of the security properties of GPG versus Rijndael if you prefer that.
[03:23.780 --> 03:27.980]  SBA packets are encrypted and they're non-replayable.
[03:28.200 --> 03:34.760]  And, so, the non-replayable part is one of the chief difficulties that port knocking has.
[03:35.460 --> 03:45.560]  It's relatively difficult to make port knocking sequences non-replayable because you need some aspect of cryptography in order to get to that property.
[03:45.560 --> 03:57.840]  And, port knocking by itself, which typically transmits data within packet headers, doesn't, you know, isn't usually able to achieve that property by itself.
[03:58.480 --> 04:03.560]  In addition, I don't want anything that trusts an IP address within an IP header.
[04:04.120 --> 04:19.720]  So, you know, if there's any, if, if a, it's relative, it would become relatively easy to man in the middle, a port knocking implementation, just, if that implementation chooses to trust the source IP of the sequence.
[04:19.880 --> 04:32.840]  So, if you've got a demon out there that is parsing a firewall log and seeing this port knocking sequence come across the wire, and saying, okay, I saw the connections to these following ports, therefore, I know that that, that person actually wants access to SSHD.
[04:32.840 --> 04:42.100]  Well, you know, if you, if that implementation trusts the IP address in the IP header, there is, that is totally unauthenticated information.
[04:42.260 --> 04:46.480]  It could have been changed by someone who has access to man in the middle of those incoming packets.
[04:47.760 --> 04:50.180]  Single packet authorization does not work that way.
[04:51.060 --> 05:11.620]  It is designed to encrypt the IP address along with several other pieces of information within a payload, and will only reconfigure the local firewall for the IP address that's actually included within that payload, which means that it must be decrypted properly in order for whoever sent that packet to actually gain the access.
[05:12.660 --> 05:17.820]  I like the SPA implementation to be portable to embedded devices.
[05:18.160 --> 05:24.840]  So, to me, this means that, you know, I don't want a heavyweight interpreted language.
[05:24.840 --> 05:33.660]  In many cases, a lot of people, if they're running a lightweight firewall gateway device, you know, ordering two networks, they don't even want Perl or Python installed at all.
[05:33.940 --> 05:48.780]  So, you know, they will only deploy the absolute minimum system libraries and user space code and cut down kernel configurations in order to actually provide filtering for those networks and nothing else.
[05:48.780 --> 05:53.640]  So, I would like the FWNOP project to be able to fall within that paradigm.
[05:56.020 --> 06:01.520]  Also, it should be portable to various firewall architectures and ACL languages.
[06:01.860 --> 06:05.780]  So, currently, today, FWNOP 2.0 supports three different firewalls.
[06:05.820 --> 06:13.760]  It supports IP tables on Linux, IPFW on FreeBSD and Mac OS X systems, and also the PF firewall on OpenBSD.
[06:16.120 --> 06:18.760]  The client should be relatively portable as well.
[06:18.980 --> 06:22.600]  There's no reason that it shouldn't be, it shouldn't be able to be run on.
[06:22.620 --> 06:31.100]  SigWint on Windows, you know, you name the UNIX system it should run there, and also, you know, Android and iPhone clients, which do exist, by the way.
[06:31.460 --> 06:36.300]  We are looking for some assistance for people who are interested in this sort of development to maintain them.
[06:38.120 --> 06:50.600]  And, you know, one of the consequences of this too is we don't want to necessarily require someone to have administrator-level control of their local device in order to send an appropriately constructed SPA packet.
[06:51.580 --> 07:04.340]  We don't want to require raw socket manipulation of packet headers, you know, stuffing authentication information within, let's say, the DCP options portion of the DCP header, or that sort of thing.
[07:04.460 --> 07:06.800]  There's lots of places where you can stuff information.
[07:08.160 --> 07:13.320]  But those kinds of activities typically require administrative-level control of your device.
[07:13.500 --> 07:15.140]  There are lots of users that don't have that.
[07:15.420 --> 07:19.680]  And I'd like to be able to have FWNOP reach those users.
[07:20.500 --> 07:22.240]  And then also a library implementation.
[07:22.680 --> 07:23.760]  So there is a...
[07:23.760 --> 07:33.900]  So both the FWNOP client and server link against a library called LibFKO that implements the SBA protocol as envisioned by FWNOP.
[07:34.020 --> 07:38.100]  So this brings it into the realm of third-party usage.
[07:38.340 --> 07:41.660]  So there are also Perl and Python bindings that use that library.
[07:45.190 --> 07:46.750]  So as I've mentioned...
[07:46.750 --> 07:48.890]  By the way, any questions up to now?
[07:50.670 --> 07:51.170]  Nope.
[07:55.310 --> 07:59.950]  So I've already mentioned most of this on the slide, but the force NAT mode is probably notable.
[07:59.950 --> 08:05.570]  So if anybody has been running the Perl version up to now, this is a new mode that doesn't exist in that code.
[08:06.750 --> 08:17.010]  Essentially, the force NAT mode allows individual SBA keys to be associated with automatically built NAT rules.
[08:17.010 --> 08:22.490]  So you can have a border filtering device running the FWNOP daemon.
[08:22.490 --> 08:30.910]  And it can construct NAT rules to allow external systems to reach internal devices transparently.
[08:31.130 --> 08:34.570]  So they would never even know that they're not actually reaching the firewall itself.
[08:34.730 --> 08:37.690]  They're being NATed all the way into an internal device of your choosing.
[08:39.290 --> 08:41.870]  And there are iPhone and Android clients.
[08:42.210 --> 08:44.390]  And by the way, also, I've switched to Git.
[08:45.230 --> 08:46.710]  Any developers out there...
[08:47.370 --> 08:48.170]  I went...
[08:48.170 --> 08:48.670]  Let's see...
[08:48.670 --> 08:52.210]  A decade ago, I guess, it was, you know, mostly CVS.
[08:52.350 --> 08:54.010]  And it's sort of the subversion wave came along.
[08:54.210 --> 08:56.870]  And then, if you haven't tried Git yet, highly recommend it.
[08:56.910 --> 08:57.490]  Git is awesome.
[08:58.410 --> 09:00.350]  You can clone the repository there if you like.
[09:03.170 --> 09:13.890]  So, as I mentioned before, now that FWNOP is a C application, there is a pretty high burden on trying to write secure code as much as possible.
[09:14.030 --> 09:15.750]  Of course, this is not an easy thing to do.
[09:16.430 --> 09:19.070]  I'm not claiming FWNOP has zero bugs.
[09:19.230 --> 09:20.370]  No one can ever claim that.
[09:21.430 --> 09:31.430]  This is a listing of the library dependencies in the server-side implementation of the FWNOP daemon.
[09:33.410 --> 09:34.370]  Those in...
[09:35.010 --> 09:37.790]  Those that are not in bold come essentially from libc.
[09:38.250 --> 09:46.930]  You're going to get pretty much those libraries, no matter what application you write, assuming you're using GCC to compile into an executable on a Linux system.
[09:48.610 --> 09:53.310]  The libraries in bold, this libfko one is the first one that I mentioned.
[09:53.510 --> 09:55.710]  This is one that implements the SBA protocol.
[09:56.150 --> 09:57.730]  It also uses libpcap.
[09:57.950 --> 09:58.950]  More on this in a moment.
[09:58.950 --> 10:01.250]  And these two are optional.
[10:01.590 --> 10:04.610]  It uses libgpg.me for the...
[10:04.610 --> 10:10.090]  For the GPG portion of the SBA implementation, if you choose to enable that.
[10:10.190 --> 10:11.130]  That is not mandatory.
[10:14.150 --> 10:19.030]  But contrast this with the dependencies in the old Perl version.
[10:19.230 --> 10:19.970]  This is one of...
[10:19.970 --> 10:21.310]  So I have a Linksys...
[10:21.310 --> 10:23.010]  I have a Linksys...
[10:23.870 --> 10:24.830]  I can't remember the...
[10:24.830 --> 10:25.100]  54G.
[10:25.750 --> 10:26.570]  I can't remember the exact number.
[10:26.810 --> 10:28.930]  It's one of those Linksys routers where you can actually...
[10:28.930 --> 10:31.590]  flash the memory and you can get OpenWRT to run.
[10:33.030 --> 10:33.470]  I...
[10:33.470 --> 10:43.250]  There's just no way in such a small form factor to get all of those Perl dependencies to actually run along with a Perl demon in such a, you know, in such a small system.
[10:43.810 --> 10:45.470]  Or at least, I should say, it's really difficult.
[10:45.750 --> 10:54.270]  I mean, if you do choose to get all those Perl modules to actually run and execute, you're not going to have very much processing left or memory left for anything else.
[10:54.270 --> 11:04.030]  So, let alone, of course, many of these libraries or these Perl modules have C code that are excess extensions that get compiled to.
[11:04.450 --> 11:09.410]  So, you know, the auditing requirement for such a heavyweight code base is pretty large.
[11:09.830 --> 11:20.150]  This is one of the reasons that, you know, we chose in the FWNOT project to go with the C implementation where you don't have such a heavyweight burden of module code.
[11:20.150 --> 11:21.630]  And those are just the modules.
[11:21.810 --> 11:23.330]  Then you also have the Perl interpreter itself.
[11:24.330 --> 11:26.370]  So, you know, interpreted languages, wow, they're great.
[11:26.510 --> 11:27.070]  And I love Perl.
[11:27.150 --> 11:28.270]  Python is also fantastic.
[11:28.890 --> 11:31.350]  It's also a large code base, too.
[11:31.750 --> 11:35.090]  And that is not the friend of security.
[11:40.180 --> 11:44.500]  So, I mentioned that FWNOT uses libpcap.
[11:46.180 --> 11:53.900]  Some people automatically dismiss port docking or SBA even just because of that.
[11:54.080 --> 11:59.000]  It is a C library that is relatively, you know, it's not a simple C library.
[12:02.060 --> 12:13.440]  But in defense of using libpcap, so, first of all, libpcap, usage of libpcap allows the design goals that I mentioned earlier on to be achieved.
[12:15.080 --> 12:20.340]  And every port docking or SBA system has a burden of acquiring data in some fashion.
[12:20.340 --> 12:26.320]  And even those, even log parsers have had vulnerabilities from time to time.
[12:26.620 --> 12:36.400]  So, you know, it's, what this really is about is reducing the attack surface for, you know, for all sorts of server software.
[12:37.020 --> 12:50.660]  I am, you know, if libpcap in itself were a huge problem, then we should see evidence of, let's say, exploit frameworks, being able to take advantage of libpcap based software and attack them too.
[12:51.640 --> 12:56.020]  You know, usage of port docking and SBA is different.
[12:56.400 --> 13:07.960]  It, the exploit frameworks don't expect that they have to go to the level of, of actually circumventing or compromising a sniffer in order to gain access to something else.
[13:08.260 --> 13:11.960]  So, different is good in security usually.
[13:13.400 --> 13:20.840]  So, but we can certainly ask the question, you know, what, what is Metasploit doing about, about exporting libpcap based software?
[13:21.040 --> 13:23.960]  Well, it certainly does have some exploits for snort.
[13:24.620 --> 13:27.100]  There were, there was a DCRPC vulnerability from 2007.
[13:27.660 --> 13:30.900]  Before that, there was a, a vulnerability in the back or for its preprocessor.
[13:31.040 --> 13:32.620]  They have long since been fixed.
[13:34.620 --> 13:40.960]  Wireshark, there's, you know, several exploits for various decoders in, in Wireshark.
[13:42.500 --> 13:49.700]  Generally, however, Metasploit is not exploiting libpcap itself.
[13:50.040 --> 13:53.080]  It's exploiting the code that's layered on top of libpcap.
[13:53.200 --> 14:00.000]  And also, if you search the national vulnerability database, there are some vulnerabilities in libpcap that have been fixed over time.
[14:00.060 --> 14:04.860]  But the vast majority of them are in the complex software that writes on top of it.
[14:08.520 --> 14:19.660]  So, to me, that indicates that there is, there at least is some room for usage of libpcap with a simplistic user space implementation on top of that.
[14:20.380 --> 14:21.860]  And more about this in a moment.
[14:33.590 --> 14:35.410]  So, that's kind of annoying.
[14:37.170 --> 14:42.350]  Another thing about SPA is, you know, things aren't really always as they seem.
[14:42.850 --> 14:53.850]  So, in this, so, consider for a moment that in single packet authorization, neither the source IP nor the destination IP are actually important.
[14:53.850 --> 15:02.930]  So, in this case, what we have here is a user that's using SPA here down on network A, is trying to access a service that's on network B.
[15:03.310 --> 15:08.030]  It's protected by this SPA implementation that's running here on this sniffer.
[15:08.650 --> 15:13.430]  And the sniffer has access to network traffic along a certain routing path.
[15:14.510 --> 15:25.450]  An attacker who is in a really privileged position to be able to also monitor network traffic that you're sending, may also be able to see the SPA packet as it is sent from network A.
[15:26.530 --> 15:31.610]  But, depending upon where the attacker sniffer is located, that may not actually do them any good.
[15:31.850 --> 15:33.670]  Because you can spoof the IP.
[15:33.850 --> 15:37.290]  I've just chosen Google here as the source IP and Yahoo as the destination.
[15:37.690 --> 15:39.230]  Those are just, you know, randomly selected.
[15:39.510 --> 15:46.690]  The point is that this sniffer only has to be able to see the network traffic along the routing path.
[15:46.690 --> 15:52.270]  And neither the source IP in the network layer header nor the destination IP are significant.
[15:52.490 --> 16:01.210]  Because it is only going to allow the IP address that's been encrypted in the SPA payload to actually gain access to this network B here.
[16:01.490 --> 16:08.330]  The attacker may certainly see the SPA packet coming from, but it looks like it comes from Google in this case.
[16:08.330 --> 16:10.330]  And it looks like it's destined for Yahoo.
[16:10.630 --> 16:20.390]  And the attacker has no way to know that along, it's not the Yahoo IP that's actually going to be running the SPA sniffer and gaining access to anything.
[16:20.590 --> 16:26.830]  It was this other system that was even before, that was in the routing path even before the attacker had a chance to see the SPA packet.
[16:26.830 --> 16:37.450]  So, you know, with SPA you can leverage how networks work and, you know, IP spoofing in this case becomes an advantage.
[16:39.010 --> 16:46.830]  So an attacker can't always assume that the IP addresses and the headers are actually significant.
[16:47.090 --> 16:49.330]  Does FW not do that for you?
[16:53.590 --> 16:56.550]  So, I haven't looked at the spoofing code in a little while.
[16:56.890 --> 17:02.490]  The spoofing code was built into the Perl version and I'm getting to that for the C version.
[17:02.630 --> 17:15.110]  But yes, one note on that, of course, is that it does require administrative level access on your local machine because you're messing with a data structure that the kernel normally builds for you.
[17:15.110 --> 17:18.870]  So, but it certainly, if it doesn't now, it certainly will.
[17:19.310 --> 17:20.830]  It's not a hard thing to do.
[17:21.050 --> 17:23.250]  I think it does actually, but I haven't tested it in a while.
[17:25.450 --> 17:27.110]  I haven't tested that particular feature.
[17:31.930 --> 17:38.310]  So, what other things are happening in the FWNOP project to try to heighten the security of its code?
[17:39.650 --> 17:41.110]  Well, quite a lot.
[17:41.770 --> 17:45.910]  So, we use Valgrind quite extensively.
[17:47.870 --> 17:48.830]  Excellent project.
[17:49.050 --> 17:52.990]  Essentially, it allows you to verify that there are no memory leaks that you've introduced.
[17:53.270 --> 17:55.770]  So, all of your mallocs are coupled with freeze.
[17:56.030 --> 17:58.970]  You're not leaving any dangling file handles around.
[17:59.230 --> 18:00.850]  There's all sorts of things that it checks.
[18:00.970 --> 18:02.370]  I'll have an example of this in a little bit.
[18:03.670 --> 18:04.630]  Static analyzers.
[18:05.130 --> 18:10.750]  So, I really wish I could get a copy of Coverity to use against FWNOP.
[18:11.410 --> 18:12.230]  But it's really expensive.
[18:17.550 --> 18:18.650]  I think it's...
[18:19.750 --> 18:20.630]  So, Coverity...
[18:23.070 --> 18:28.450]  So, some of the bugs that are fixed in the Linux kernel have been found by Coverity.
[18:28.970 --> 18:29.850]  At least...
[18:29.850 --> 18:32.090]  It's been a little while since I've looked at that.
[18:32.230 --> 18:34.970]  But at least as of about two years ago, I'm not sure if they're still using it.
[18:34.970 --> 18:37.370]  But, you know, to me that really says something.
[18:37.570 --> 18:38.330]  That if you've got...
[18:38.830 --> 18:46.970]  If you've got the ability to handle a kernel code, which is not easy code, from a static analysis perspective and find...
[18:46.970 --> 18:48.930]  Find programming errors and bugs.
[18:49.110 --> 18:49.370]  That's...
[18:49.370 --> 18:50.150]  That's pretty impressive.
[18:51.690 --> 18:52.170]  But...
[18:52.670 --> 18:55.230]  I talked to Coverity a few weeks ago.
[18:55.530 --> 18:56.010]  And...
[18:56.010 --> 19:01.610]  The FWNOP project is so tiny that they just don't have a user license category that even fits.
[19:01.990 --> 19:04.170]  I think it's like $15,000 for the minimum.
[19:04.410 --> 19:04.670]  And...
[19:04.670 --> 19:04.910]  I don't know.
[19:06.290 --> 19:07.090]  FWNOP is free.
[19:07.350 --> 19:08.970]  So, if anybody wants to donate that, that'd be great.
[19:09.110 --> 19:09.870]  But I can't afford it.
[19:15.510 --> 19:18.850]  There are, of course, a lot of compile time security options that can be enabled.
[19:19.870 --> 19:20.670]  And...
[19:20.670 --> 19:22.370]  FWNOP checks for these.
[19:22.570 --> 19:26.890]  And make sure that they are enabled in your local installation.
[19:27.930 --> 19:31.470]  Automated testing is a big piece.
[19:32.930 --> 19:33.470]  So...
[19:33.470 --> 19:33.510]  So...
[19:33.510 --> 19:33.990]  It...
[19:33.990 --> 19:34.750]  So...
[19:35.470 --> 19:35.790]  So...
[19:35.790 --> 19:38.770]  In the original Perl version of FWNOP, there was a test suite.
[19:39.610 --> 19:42.450]  And I kind of got really interested in writing test suites.
[19:42.650 --> 19:42.950]  So I...
[19:42.950 --> 19:45.050]  I ported that over to the C version.
[19:45.230 --> 19:45.670]  But it...
[19:45.670 --> 19:48.350]  I'm trying to be a lot more ambitious with what it's checking.
[19:49.630 --> 19:50.170]  So...
[19:51.450 --> 19:55.090]  Automated function coverage support has been added.
[19:55.430 --> 19:58.410]  That uses some extensions that GCC provides.
[19:58.410 --> 19:59.410]  And also...
[20:00.070 --> 20:01.410]  You can also run everything...
[20:01.930 --> 20:05.730]  Every test that the test suite executes can be run underneath Valgrind.
[20:05.910 --> 20:08.110]  And it's output collected and parsed.
[20:10.890 --> 20:12.210]  SBA protocol review.
[20:12.470 --> 20:13.910]  I'll have a little bit more on this in a moment.
[20:14.030 --> 20:15.750]  In fuzzing, I haven't gotten to that yet.
[20:16.750 --> 20:21.490]  That's an area that I think needs to be explored with FWNOP2.
[20:21.870 --> 20:23.910]  There was a recent report of...
[20:24.850 --> 20:28.390]  There's a client out there called the Morpheus client that runs on...
[20:28.390 --> 20:29.210]  Runs on Windows.
[20:29.510 --> 20:29.770]  It was...
[20:29.770 --> 20:32.870]  It was built back when FWNOP2 was still a Perl project.
[20:34.490 --> 20:35.070]  And...
[20:35.070 --> 20:36.390]  It exposed...
[20:36.950 --> 20:41.190]  Because it wasn't actually resolving an IP address properly in a particular mode.
[20:41.190 --> 20:42.550]  It exposed...
[20:42.550 --> 20:46.110]  An interesting sort of scenario on the FWNOP2 demon side.
[20:46.470 --> 20:47.950]  And that is where I think...
[20:47.950 --> 20:48.170]  You know...
[20:48.170 --> 20:53.670]  There is some room for having a fuzzing style sort of operation against the FWNOP2 demon too.
[20:54.630 --> 20:57.350]  And if there are things to be exploited there...
[20:58.130 --> 20:58.890]  You know...
[20:58.890 --> 21:00.270]  That would be a great way to help find them.
[21:02.250 --> 21:02.650]  So...
[21:02.650 --> 21:03.390]  I should...
[21:03.390 --> 21:05.970]  So all major SBA functionality is tested and validated.
[21:06.150 --> 21:07.050]  I should say...
[21:07.050 --> 21:08.490]  With the exception of the IP spoofing.
[21:08.670 --> 21:09.070]  Thank you.
[21:09.190 --> 21:09.790]  I will add that.
[21:12.270 --> 21:13.070]  Compilation warnings.
[21:14.990 --> 21:15.550]  So...
[21:15.550 --> 21:24.130]  The Ubuntu security team has a really interesting web page that talks about all the security features that are enabled on Ubuntu systems these days.
[21:24.330 --> 21:26.070]  And it's really quite complete.
[21:27.190 --> 21:33.570]  It talks about everything from kernel options that are set all the way through compiler options that you can compile code with.
[21:33.570 --> 21:34.950]  And this...
[21:34.950 --> 21:36.670]  This hardening check script from...
[21:37.590 --> 21:38.290]  I think it's...
[21:38.290 --> 21:38.870]  C's cook...
[21:41.030 --> 21:42.090]  Helps to...
[21:42.090 --> 21:43.550]  To verify that...
[21:43.550 --> 21:47.410]  That Ubuntu binaries are compiled with these security aspects built in.
[21:48.370 --> 21:49.010]  And...
[21:49.010 --> 21:51.070]  I bundle that with the FWNOP2 project too.
[21:51.190 --> 21:53.330]  And run that through the test suite to verify things.
[21:53.970 --> 21:56.090]  I mentioned the Valgram mode already.
[21:56.390 --> 21:58.090]  And also there's a diff mode.
[21:58.410 --> 21:58.730]  So...
[21:58.730 --> 22:01.490]  Development of FWNOP2 has changed from...
[22:01.490 --> 22:02.790]  Adding new features.
[22:02.930 --> 22:03.650]  Adding new features.
[22:03.950 --> 22:03.970]  Adding new features.
[22:03.970 --> 22:04.270]  To...
[22:04.270 --> 22:05.630]  Add new features.
[22:06.410 --> 22:07.510]  Run it through...
[22:07.510 --> 22:08.610]  Run them through the test suite.
[22:08.850 --> 22:09.850]  And then diff the...
[22:09.850 --> 22:10.790]  Diff the output.
[22:11.130 --> 22:12.270]  Underneath Valgrind.
[22:12.350 --> 22:15.470]  To see if there are any new problems that have come up with respect to handling memory.
[22:16.970 --> 22:18.250]  So this is an example.
[22:19.690 --> 22:21.390]  Running the FWNOP2 test suite.
[22:21.590 --> 22:23.410]  And you can see that...
[22:23.410 --> 22:25.510]  These compilation options here.
[22:26.150 --> 22:29.190]  Everything from position independent executables to...
[22:29.190 --> 22:29.730]  You know...
[22:29.730 --> 22:31.850]  Stack protected binary fortify source functions.
[22:32.190 --> 22:35.730]  These are all things that are verified by that hardening check script that I mentioned.
[22:36.050 --> 22:38.790]  And are enabled with this GCC command line.
[22:38.990 --> 22:40.590]  These command line arguments here.
[22:41.390 --> 22:41.950]  Um...
[22:41.950 --> 22:42.690]  So if you're...
[22:42.690 --> 22:45.430]  If you're writing C code and you want to take advantage of...
[22:45.430 --> 22:46.070]  Um...
[22:46.070 --> 22:48.430]  Some security mechanisms that the compiler provides...
[22:48.430 --> 22:48.710]  Uh...
[22:48.710 --> 22:49.530]  For you...
[22:50.190 --> 22:50.550]  Uh...
[22:50.550 --> 22:51.650]  That's a great way to...
[22:51.650 --> 22:52.250]  To enable them.
[22:56.140 --> 22:56.680]  Um...
[22:56.680 --> 22:57.740]  The test suite...
[22:57.740 --> 23:03.360]  Of course, runs both the client side and the server side in conjunction to make sure that things are...
[23:03.360 --> 23:04.260]  Are working properly.
[23:04.420 --> 23:06.100]  This is a sample of some of the output.
[23:06.800 --> 23:07.340]  Um...
[23:07.340 --> 23:08.980]  From one of the Rijndael tests.
[23:09.260 --> 23:09.560]  Uh...
[23:09.560 --> 23:10.380]  That shows...
[23:11.180 --> 23:11.720]  Um...
[23:11.720 --> 23:14.200]  Shows the commands that are executed against IP tables.
[23:14.580 --> 23:15.040]  Uh...
[23:15.040 --> 23:16.740]  Once a valid packet is...
[23:16.740 --> 23:17.040]  Is...
[23:17.040 --> 23:17.240]  Is...
[23:17.240 --> 23:17.540]  Is monitored.
[23:20.660 --> 23:21.080]  So...
[23:21.080 --> 23:22.880]  You know...
[23:22.880 --> 23:25.120]  Development becomes...
[23:25.120 --> 23:27.000]  Run the test suite underneath Valgrind.
[23:27.140 --> 23:28.340]  Make sure there are no problems.
[23:28.940 --> 23:29.300]  Um...
[23:29.300 --> 23:30.020]  Incidentally, if you...
[23:30.020 --> 23:31.020]  If you actually do this on a...
[23:31.020 --> 23:33.320]  On a Linux system with the current FWNOP code.
[23:33.600 --> 23:33.840]  Uh...
[23:33.840 --> 23:34.710]  You will see certain...
[23:35.100 --> 23:37.640]  Certain things that come up that Valgrind flags.
[23:37.980 --> 23:38.380]  Uh...
[23:38.380 --> 23:41.260]  But they sometimes turn out to be false positives in a sense.
[23:41.420 --> 23:42.260]  Like, um...
[23:42.260 --> 23:42.920]  There's a...
[23:42.920 --> 23:45.040]  There's a C user ID function in libc.
[23:45.300 --> 23:46.880]  That returns a pointer to a static...
[23:46.880 --> 23:47.780]  A allocated...
[23:47.780 --> 23:48.340]  Um...
[23:48.340 --> 23:48.700]  Uh...
[23:48.700 --> 23:48.840]  Buffer.
[23:49.020 --> 23:50.460]  Which is not something that you're going to free.
[23:50.780 --> 23:51.220]  But even...
[23:51.220 --> 23:52.940]  But nevertheless, it doesn't get freed.
[23:53.280 --> 23:54.380]  You know, when the process...
[23:54.380 --> 23:55.420]  Before the process exit.
[23:55.680 --> 23:56.540]  Therefore, Valgrind...
[23:56.540 --> 23:57.380]  Um...
[23:57.380 --> 23:58.180]  Flags it as an error.
[23:58.300 --> 23:59.420]  But that's not a problem with...
[23:59.420 --> 24:00.000]  Um...
[24:00.000 --> 24:01.460]  That's not a problem with FWNOP.
[24:01.560 --> 24:02.720]  That's how libc is implemented.
[24:03.720 --> 24:04.160]  Um...
[24:04.160 --> 24:04.720]  But it's still...
[24:04.720 --> 24:06.340]  It's nice to see when those things come up.
[24:06.660 --> 24:07.480]  Valgrind is a pretty...
[24:07.480 --> 24:08.280]  Pretty amazing project.
[24:09.660 --> 24:10.100]  But...
[24:11.080 --> 24:12.800]  Enable Valgrind with the...
[24:12.800 --> 24:13.400]  First test run.
[24:13.600 --> 24:14.880]  Add a bunch...
[24:14.880 --> 24:15.220]  Add a bunch of code.
[24:15.820 --> 24:16.440]  Before committing it.
[24:16.640 --> 24:17.460]  You know...
[24:17.460 --> 24:18.560]  Run it again through the test suite.
[24:18.740 --> 24:19.720]  And diff the results.
[24:20.520 --> 24:20.960]  And...
[24:20.960 --> 24:23.140]  If at any point there's a problem that's been...
[24:23.140 --> 24:23.840]  Flagged by Valgrind...
[24:23.840 --> 24:25.640]  You'll see that come up within that diff.
[24:26.040 --> 24:27.860]  And then that can be fixed before committing.
[24:30.620 --> 24:31.260]  So...
[24:31.260 --> 24:32.000]  Here's an example.
[24:33.560 --> 24:34.200]  Um...
[24:34.200 --> 24:34.520]  So...
[24:34.520 --> 24:35.860]  FWNOP right now...
[24:35.860 --> 24:36.800]  Um...
[24:36.800 --> 24:37.580]  I mentioned...
[24:37.580 --> 24:39.060]  It uses either...
[24:39.060 --> 24:40.020]  Symmetric Cypher...
[24:40.480 --> 24:41.240]  Rijndael specifically.
[24:41.640 --> 24:42.060]  Or...
[24:42.060 --> 24:42.360]  Um...
[24:42.360 --> 24:43.980]  Any of the Cypher's...
[24:43.980 --> 24:44.800]  Offered by Canoe VG.
[24:46.680 --> 24:47.320]  Um...
[24:47.320 --> 24:49.080]  This is gonna be extended to include...
[24:50.000 --> 24:50.640]  Uh...
[24:50.640 --> 24:51.100]  A...
[24:51.100 --> 24:52.160]  An HMAC.
[24:52.240 --> 24:53.320]  And I'll have more on this in a moment.
[24:53.500 --> 24:53.920]  But...
[24:53.920 --> 24:54.260]  In...
[24:54.260 --> 24:55.760]  Some of this crypto work has been...
[24:55.760 --> 24:57.460]  Has been in this crypto update branch.
[24:57.580 --> 24:59.540]  Which I haven't merged back to master yet.
[25:00.720 --> 25:01.160]  Um...
[25:01.160 --> 25:01.640]  But...
[25:01.640 --> 25:02.440]  In that...
[25:02.440 --> 25:03.440]  In that branch.
[25:04.060 --> 25:04.440]  You know...
[25:04.440 --> 25:05.380]  This is an example of...
[25:06.020 --> 25:07.300]  Remember how I had the...
[25:07.300 --> 25:08.740]  There's this workflow where you have...
[25:08.740 --> 25:09.660]  Run it through the test suite.
[25:10.340 --> 25:11.440]  Add a bunch of code.
[25:11.520 --> 25:12.020]  Run it again.
[25:12.160 --> 25:12.580]  And do a diff.
[25:12.800 --> 25:14.540]  Here is some of that diff...
[25:14.540 --> 25:15.440]  Here's a diff result.
[25:15.640 --> 25:18.280]  Where I was going to introduce a problem into FWNOP.
[25:19.280 --> 25:23.480]  But the test suite with Valgrind enabled me to find it before committing the code.
[25:24.900 --> 25:25.420]  So...
[25:26.320 --> 25:27.260]  Once that...
[25:27.260 --> 25:32.900]  Once that had been flagged by Valgrind, I was able to add this fix before commit.
[25:33.300 --> 25:35.980]  And therefore that was never introduced into...
[25:35.980 --> 25:37.920]  Into the FWNOP code base as a problem.
[25:39.020 --> 25:44.020]  So if you're writing security-based software, I highly recommend that as a strategy for...
[25:44.020 --> 25:46.020]  For detecting when there are problems coming up.
[25:50.180 --> 25:50.760]  So...
[25:50.760 --> 25:56.880]  One criticism of FWNOP currently is that it does not include an HMAC.
[25:57.100 --> 26:01.440]  So HMAC stands for hash message authentication code.
[26:02.140 --> 26:06.920]  This is going to be released in FWNOP 2.2, which will come up in a couple of months probably.
[26:06.920 --> 26:10.860]  The reason for doing this is...
[26:10.860 --> 26:12.040]  So...
[26:12.040 --> 26:13.340]  There are...
[26:13.340 --> 26:14.940]  Down at the bottom of the slide...
[26:15.820 --> 26:16.920]  There are...
[26:16.920 --> 26:19.600]  So three very well-known security projects today.
[26:19.900 --> 26:21.600]  SSH, SSL, and IPsec.
[26:23.080 --> 26:30.520]  So they all offer message authentication as a part of their implementations.
[26:30.700 --> 26:33.660]  That is cryptographically strong message authentication.
[26:34.580 --> 26:36.780]  But they don't all do it in the same way.
[26:37.040 --> 26:39.520]  So, you know, there's a saying in the crypto community.
[26:39.760 --> 26:43.040]  Whenever you think you need to write a new cryptographic algorithm, don't.
[26:43.160 --> 26:46.060]  Because somebody already has done it in a peer-reviewed way.
[26:46.300 --> 26:49.420]  And it will have less bugs probably than what you're going to introduce.
[26:50.100 --> 26:53.040]  I think that's a very important principle.
[26:53.280 --> 26:55.920]  Certainly want to leverage good work that's been done before.
[26:56.860 --> 26:58.700]  But there's no general...
[26:58.700 --> 27:00.760]  The crypto world is huge.
[27:00.960 --> 27:10.860]  So you still have, as a designer of secure software, you still have a burden to select different algorithms and putting them together.
[27:10.860 --> 27:12.680]  Even though you're using a well-known implementation.
[27:13.260 --> 27:18.240]  But putting them together in a way that does result in certain security properties being met.
[27:18.240 --> 27:25.840]  So, at the bottom there, IPsec gives you these two really, really nice security properties.
[27:26.140 --> 27:28.960]  So, this integrity of the ciphertext.
[27:29.200 --> 27:35.420]  And also, ciphertext indistinguishability underneath an adaptive chosen ciphertext attack.
[27:37.380 --> 27:42.420]  IPsec is provably achieves both of those goals.
[27:43.380 --> 27:49.100]  And FWDOP will also, as soon as it has support for this HMAC, SHA-256 that I mentioned.
[27:50.060 --> 27:56.540]  You know, SSH falls underneath the paradigm of encrypt and MAC.
[27:57.380 --> 28:03.500]  SSL is MAC then encrypt and IPsec is encrypt then MAC.
[28:03.960 --> 28:11.660]  So, each one of these has an important implication with respect to these ciphertext or these cryptographic properties that you want to achieve.
[28:12.060 --> 28:21.550]  If you read Bruce Schneier, Schneier says that the natural order is MAC then encrypt.
[28:24.200 --> 28:32.440]  So, that does not invalidate the provably secure aspect of IPsec.
[28:32.800 --> 28:43.420]  His point is that it's just a little bit harder to get the encrypt then MAC order or implementation properly done.
[28:43.420 --> 28:53.740]  So, for any of you that are interested, yes, the FWDOP implementation will include the initialization vector as a part of the data that is authenticated.
[28:55.500 --> 28:59.060]  That was his criticism for one implementation of that.
[28:59.240 --> 29:00.260]  It didn't get it properly.
[29:03.140 --> 29:11.500]  So, it turned out that SSL, as I mentioned before, uses this MAC then encrypt paradigm.
[29:11.960 --> 29:19.220]  And there was a very, very well-known attack against that that was published, I think, in 2001.
[29:20.100 --> 29:29.540]  That showed a, essentially it was a, it exploited a weakness with respect to how padding is added within an SSL encrypted messages.
[29:29.980 --> 29:35.480]  And allowed essentially full decryption of SSL communications.
[29:35.820 --> 29:40.280]  It wasn't, you certainly have to generate a lot of data in order to implement this attack.
[29:40.460 --> 29:43.000]  But it was still, you know, it certainly wasn't a theoretical thing.
[29:43.120 --> 29:47.400]  It was an actual attack against a, you know, well-known cryptographic protocol.
[29:48.440 --> 29:52.480]  But there's an additional reason why adding an HMAC is important.
[29:53.480 --> 30:01.700]  So, you know, with an HMAC, we're running a very simplistic, relatively simplistic algorithm.
[30:02.020 --> 30:12.780]  So, computing SHA-256 is a lot more simplistic than actually running an Elgamal GPG decrypt against, again, against data that's come in, for example.
[30:12.780 --> 30:19.900]  So, you know, back on the, one of the earlier slides, I mentioned the GPG-ME libraries are optional.
[30:20.580 --> 30:37.180]  But even if you, if you choose to compile them in and use GPG as part of your FWNOP communications, with the HMAC support, those communications are, essentially, any of the functions in GPG-ME are going to be gated by whether or not the HMAC verifies first.
[30:37.180 --> 30:40.920]  And that's a very simplistic operation compared to GPG.
[30:41.620 --> 30:52.180]  So, that, you know, not only do we get a speed up for that, which is not really maybe what you're concerned about in this case, but it's mostly about, you know, reducing your attack surface even in FWNOP2.
[30:53.080 --> 30:55.520]  And adding the HMAC will help to do that.
[30:55.720 --> 31:09.000]  The link at the bottom has a really nice summary of why, you know, sort of, you know, why encrypt then authenticate is a good paradigm to adhere to.
[31:10.560 --> 31:18.260]  So, I also mentioned that one thing that I like to do for FWNOP is try to audit the SBA protocol itself.
[31:18.660 --> 31:25.960]  And one way I like to do that is by taking a look at the, what I, so, cross packet ciphertext entropy.
[31:27.700 --> 31:41.400]  So, what, what this does essentially is the SPA entropy dot PL script, it take, it generates, in this case, we're down at the bottom of the slide, we're generating a thousand SBA packets.
[31:41.620 --> 31:44.560]  And what we're doing is we're on a byte by byte basis.
[31:44.760 --> 31:55.080]  So, like, select the 20th byte and tell me across all of those packets, all thousand of those packets, was there any very repetitive information in that byte?
[31:55.080 --> 32:02.020]  So, if the 20th byte were always, let's say, you know, hex zero C, that's probably a bad thing.
[32:02.220 --> 32:13.760]  Because that means that, that means that the, the, somewhere along the implementation or the design, we weren't able to achieve very good entropy levels in the encrypted data.
[32:14.020 --> 32:20.460]  You know, encrypted data is supposed to be, you know, is supposed to have a lot of entropy.
[32:20.460 --> 32:26.420]  Because it's not supposed to be able to, easy to be able to infer what is, what the contents of that data actually are.
[32:26.640 --> 32:31.160]  If there's a lot of, if, you know, the low entropy information in your encrypted data, that's a, that's a really bad thing.
[32:31.540 --> 32:46.940]  So, with that script, this is the entropy level for across every single byte, zero to 120 in SBA package that are created by the FWNOP client.
[32:47.860 --> 32:52.060]  Notice that there are no peaks, no significant peaks, no significant valleys.
[32:52.320 --> 32:59.780]  That means that, on average, no byte within the encrypted payload is easier to predict than any other byte.
[32:59.960 --> 33:02.220]  That is a good property to try to achieve.
[33:05.640 --> 33:07.520]  This is what it looks like for GPG.
[33:07.820 --> 33:09.740]  When I first saw this, I was kind of shocked.
[33:11.700 --> 33:16.180]  So, you know, it starts off really low here, near zero.
[33:16.560 --> 33:19.220]  There's another dip here, and another dip here.
[33:19.360 --> 33:21.140]  This is across zero to 800 bytes.
[33:21.360 --> 33:25.860]  GPG encrypted packets are a little bit bigger because you're typically dealing with larger key sizes.
[33:25.860 --> 33:30.080]  And even if you encrypt a single byte with GPG, you're not going to get...
[33:30.080 --> 33:35.660]  It's not like a block cipher that gives you, you know, a block size worth of data back.
[33:36.860 --> 33:39.280]  So, like I said, the packets are typically larger.
[33:40.360 --> 33:50.060]  But I always kind of assumed that the entropy levels that you would get across GPG encrypted packets would also be similarly high as what you would get for Rijndael.
[33:50.060 --> 33:53.700]  But it turns out that this is not a weakness in GPG.
[33:54.060 --> 34:03.500]  It turns out that there's a specific data format that GPG adheres to where it encodes links at certain points in the data stream where necessary.
[34:03.860 --> 34:14.400]  And that's what you're seeing here, is that this drop in entropy represents the regions in the SBA packets that are associated with these length bytes.
[34:14.620 --> 34:18.800]  And therefore, they're similar because all of the SBA packets have a relatively similar length.
[34:23.860 --> 34:31.100]  So, if you notice back on these two slides, the average for both of them is pretty close to...
[34:31.100 --> 34:32.440]  Pretty close to 8.
[34:32.600 --> 34:33.620]  Not quite, but close.
[34:34.340 --> 34:36.080]  You know, pretty close to 8.
[34:36.620 --> 34:37.900]  What is that saying?
[34:38.200 --> 34:41.900]  Well, if you just...
[34:41.900 --> 34:52.920]  Measuring the actual entropy source on my Ubuntu system itself comes up with the int program, shows that the entropy source is pretty good.
[34:53.100 --> 34:56.500]  So, 7.999.625 bits per byte.
[34:56.900 --> 34:58.300]  That's pretty good entropy level.
[34:58.640 --> 35:09.840]  But I think it's worthy of noting that the implementation of the encryption algorithms themselves are also getting you very close to that sort of ideal level.
[35:11.140 --> 35:14.800]  Not quite there, but I would say close enough for government work anyway.
[35:18.250 --> 35:18.690]  Okay.
[35:19.290 --> 35:21.210]  Let's turn to a little bit more of a fun example.
[35:22.010 --> 35:23.510]  Any questions at this point?
[35:25.850 --> 35:26.290]  Yes.
[35:26.410 --> 35:28.870]  How are you calculating the output?
[35:29.310 --> 35:31.930]  So, the question is how am I calculating the entropy for the graphs?
[35:32.290 --> 35:33.390]  So, great question.
[35:33.580 --> 35:37.980]  So, actually this command line is illustrative right here.
[35:37.980 --> 35:41.710]  So, this int program is generating this output.
[35:42.000 --> 35:44.890]  What I'm doing is I'm taking...
[35:44.890 --> 35:47.600]  So, imagine you've got two SBA packets.
[35:47.810 --> 35:49.540]  They're 120 bytes long approximately.
[35:51.410 --> 35:52.520]  I take...
[35:52.520 --> 35:53.620]  So, I generate the packets.
[35:53.770 --> 35:57.140]  I then take a slice of each byte.
[35:57.290 --> 36:05.370]  So, the first byte of each packet, I will take the byte from the first packet and the byte value from the second packet and feed that to the int program.
[36:05.370 --> 36:13.540]  The int program will measure the amount of entropy that those bytes were able to produce across the sampling values.
[36:13.830 --> 36:17.020]  So, you know, just iterate over that.
[36:17.250 --> 36:21.020]  So, that's why you see in these graphs...
[36:23.980 --> 36:29.480]  That's why you see, you know, bytes zero all the way through 800 for the GPG ones.
[36:29.480 --> 36:36.520]  Each one of these dots represents the amount of entropy at that byte position across all thousand packets.
[36:37.310 --> 36:50.350]  So, again, if there were a problem or something that should be looked at, then you would expect that the entropy would be lower and that would show up as a dip, as you see here in this GPG graph, across those thousand packets.
[36:50.350 --> 36:56.540]  So, incidentally, I mean, that technique can probably be applied to other protocols, too.
[36:56.770 --> 36:59.450]  And I'm not sure if that's been done before.
[36:59.560 --> 37:05.230]  I know there's... I think there's a technique called callback-Lieber divergence and this might be a variation, I don't know.
[37:05.460 --> 37:07.250]  But anyway, that's how it was calculated.
[37:14.860 --> 37:15.500]  Okay.
[37:16.160 --> 37:19.160]  So, single-packet authorization in the Amazon Cloud.
[37:22.360 --> 37:25.500]  Amazon Web Services is really interesting, I think.
[37:25.780 --> 37:32.520]  You know, essentially, they've got... they provide you massive computing infrastructure for cheap, on-demand costs.
[37:33.200 --> 37:37.400]  A couple of notable usages of the Amazon Cloud.
[37:38.520 --> 37:42.480]  So, when I first read this, I thought it was an April Fool's article.
[37:42.480 --> 37:45.320]  But it wasn't published on April 1st.
[37:45.380 --> 37:46.400]  It was published in December.
[37:46.400 --> 37:47.940]  So, I'm assuming this is true.
[37:48.820 --> 37:51.880]  It was also published through Wired, which is a pretty reputable source.
[37:53.580 --> 38:02.420]  But the 42nd fastest supercomputer in the world was constructed on Amazon's cluster, according to this article.
[38:03.800 --> 38:07.480]  That, to me, is incredibly impressive.
[38:07.480 --> 38:14.420]  That just shows that the amount of computing resources that you have available at your fingertips is staggering.
[38:14.880 --> 38:25.260]  So, if you have a really, really intractable problem that requires a lot of computing resources, you know, the Amazon Cloud would probably be a good place to look to get that.
[38:25.260 --> 38:30.920]  Because, if you had to try to build the world's 42nd fastest supercomputer, how would you do it?
[38:31.300 --> 38:32.420]  Well, I don't know.
[38:32.600 --> 38:40.720]  Let's just say that that requires, I don't know, thousands of CPUs, and you've got to have lots of, you know, data center space, and you've got to have lots of power and cooling.
[38:41.260 --> 38:41.500]  No.
[38:41.680 --> 38:42.820]  You don't have to worry about any of that.
[38:42.960 --> 38:49.520]  You just say to Amazon, I want the world's 42nd fastest supercomputer right now, and you essentially have it.
[38:49.640 --> 38:51.060]  That, to me, is really amazing.
[38:51.820 --> 38:53.760]  I don't work for Amazon, by the way.
[38:55.400 --> 39:19.340]  So, I think another thing that was interesting is, at this conference in 2008, if anybody remembers the open, the Debian open SSL key debacle, there was a one-line change made to how the Debian packaged version of the open SSL library acquired data from its entropy source.
[39:19.580 --> 39:26.820]  The change had the effect of drastically reducing the amount of entropy that was used for cryptographic key information.
[39:27.560 --> 39:51.800]  And so, what the researchers did, and this is a link to their presentation, is they used the EC2, the Amazon EC2 cluster, to go ahead and calculate all possible, you know, essentially a database of all of the possible keys that could have been resulted from this lowered entropy calculation from Debian systems.
[39:52.080 --> 39:57.940]  And it cost them, so they generated this pretty massive database, but it cost them a total of like eight bucks.
[39:58.640 --> 40:00.720]  I mean, that's just, to me, is really impressive.
[40:00.980 --> 40:03.940]  So, I think Amazon is just an interesting computing resource.
[40:04.460 --> 40:08.460]  So, I wanted to try to see if FWNOP could work in their environment.
[40:09.300 --> 40:20.280]  So, in this context, we deploy SBA on their EC2 service along with their virtual private cloud or VPC networks.
[40:24.120 --> 40:39.780]  So, essentially you have this Amazon VPC, virtual private cloud, where you provision as many systems as you need to get whatever job done you want, and you can access them over the Internet through what Amazon calls its elastic IP service.
[40:39.920 --> 40:47.460]  So, you associate elastic IPs with internal systems in this virtual, in this VPC cloud.
[40:51.760 --> 40:55.860]  So, this, to me, was kind of one of the perfect SBA use cases.
[40:56.140 --> 41:03.440]  Earlier this year, there was a serious vulnerability announced in Microsoft's RDP service.
[41:03.440 --> 41:09.160]  And this was assigned CVE 2012-002.
[41:09.620 --> 41:10.600]  Essentially, thanks.
[41:11.140 --> 41:14.800]  Essentially, full remote code execution potential.
[41:15.060 --> 41:25.420]  Although, currently, as far as I know, Metasploit has the ability to execute a DOS against RDP that is vulnerable, but not get you actual full remote code execution.
[41:25.660 --> 41:27.180]  But it certainly, I'm sure, exists.
[41:28.540 --> 41:36.780]  So, I wanted to see if there was a way to protect RDP services behind an SBA daemon.
[41:37.080 --> 41:38.640]  You know, there's a couple of problems with that.
[41:38.760 --> 41:44.100]  First of all, Amazon has their own filtering devices, which aren't going to run FWNOP daemon.
[41:44.300 --> 41:47.400]  And secondly, FWNOP does not support a Windows firewall.
[41:50.710 --> 41:52.530]  So, there is a solution to that.
[41:52.530 --> 42:16.010]  And essentially, what you can do is you can use an internal Ubuntu system as a jump host using the NAT capabilities in FWNOP to send connections from an external system through that Ubuntu system to reach internal, other internal Windows machines or any other machine that you like.
[42:16.870 --> 42:24.750]  And it also changes the normal Amazon usage model for associating elastic IPs with internal systems.
[42:24.850 --> 42:29.790]  You only need a single elastic IP associated with that internal Ubuntu system.
[42:29.930 --> 42:37.130]  And it functions essentially as your internal gateway to augment the NAT model that Amazon provides.
[42:39.850 --> 42:43.350]  So, this is probably not legible, but this is a screenshot.
[42:43.350 --> 42:57.810]  What essentially you can do is you essentially have a very permissive VPC filtering policy that allows all sorts of connections, SSH, RDP, whatever, into that Ubuntu system.
[42:57.930 --> 43:01.250]  But remember that SBA assumes that you're running a default drop packet filter.
[43:01.470 --> 43:11.510]  So, you're essentially telling Amazon you want to allow connections into that internal system, but you're also running IP tables in that device too.
[43:11.510 --> 43:15.790]  So, you're still filtering that traffic.
[43:16.010 --> 43:20.190]  It's just that, you know, I can't integrate FWNOP into this filtering device.
[43:22.010 --> 43:31.650]  So, what you do from your home network, let's say, is you generate this SBA packet, which is, you know, according to Amazon's filter, is allowed through.
[43:33.150 --> 43:35.450]  It hits the Ubuntu system.
[43:36.050 --> 43:46.570]  And then the FWNOP daemon running on that system allows an RDP connection, which will also be initiated from the home network, to be NATed through to this internal Windows machine.
[43:48.130 --> 43:52.010]  So, this is an example of the FWNOP command line that allows that to work.
[43:52.190 --> 43:53.530]  Just a couple things to note here.
[43:57.580 --> 44:01.880]  This IP is the IP of the Windows machine running RDP.
[44:03.580 --> 44:07.060]  RDP runs on this port, 3389.
[44:07.580 --> 44:13.480]  I'm telling that... I'm telling FWNOP to send an SBA packet over port 53.
[44:13.480 --> 44:21.240]  People like to just completely allow source and destination port 53 through because they know that they don't want to mess with DNS.
[44:23.660 --> 44:29.940]  And then, what we're actually going to allow is now what looks to be a web connection through.
[44:31.480 --> 44:42.100]  And once this SBA packet has been sent, and then the FWNOP daemon monitors it, then you can make an R desktop, this is from Ubuntu, an RDP connection to...
[44:42.100 --> 44:47.100]  This is the external elastic IP that was associated with that Ubuntu system.
[44:48.060 --> 44:54.960]  Make an RDP connection over port 80, which is now being NATed through internally to port 3389 on the Windows system.
[44:57.620 --> 44:59.360]  I'm going to rush through this a little bit.
[44:59.940 --> 45:03.520]  There's a couple of things that need to be configured on the FWNOP configuration.
[45:04.240 --> 45:07.120]  But essentially, this is a screenshot that shows it working.
[45:07.820 --> 45:09.080]  Sorry, I can't demo this.
[45:09.080 --> 45:16.060]  But this is the FWNOP command line, the client window here where I'm executing the client.
[45:17.040 --> 45:20.080]  I provide the encryption key.
[45:20.700 --> 45:22.040]  SBA packet is sent.
[45:22.600 --> 45:24.340]  I then get...
[45:24.340 --> 45:34.120]  Then I launch the R desktop application from my Ubuntu instance, and now I have an RDP connection into that internal Windows machine through...
[45:34.120 --> 45:34.400]  Thanks.
[45:35.020 --> 45:38.540]  Through that single elastic IP instance on Amazon's network.
[45:40.600 --> 45:41.920]  Any questions so far?
[45:42.360 --> 45:47.120]  Within the SBA packet, it's being told what service to allow?
[45:47.460 --> 45:48.100]  Yes.
[45:48.240 --> 45:50.120]  The client submits the SBA packet.
[45:50.520 --> 45:55.520]  Within the encrypted packet is the command to tell it which service I want to start.
[45:56.200 --> 46:03.980]  So he's asking, in the encrypted payload of the SBA packet, am I telling it what service I want to allow?
[46:04.060 --> 46:05.080]  And the answer to that is yes.
[46:05.320 --> 46:13.280]  I'm not actually sending a command in the sense that I'm not telling it the specific IP tables commands or the specific IPFW commands to execute.
[46:13.760 --> 46:23.440]  It has a representation for what network access should be allowed, so what IP address should be allowed, on what port and protocol, and you can have multiples of these things.
[46:24.220 --> 46:31.980]  And then the FWNOP daemon reconfigures the firewall according to its understanding of the underlying filtering device to allow that access.
[46:32.760 --> 46:42.600]  Have you or anyone else created a client, like a Mozilla plug-in, to allow the, to submit the packet?
[46:43.680 --> 46:46.860]  A Mozilla plug-in for generating SBA packets.
[46:47.000 --> 46:47.820]  Or any, any plugin.
[46:48.120 --> 46:49.060]  That's a great question.
[46:49.340 --> 46:52.160]  No one has done a Mozilla plug-in as far as I know.
[46:52.280 --> 46:53.480]  That would be a great thing to add.
[46:53.480 --> 46:57.740]  Someone has written a web proxy that interfaces.
[46:58.180 --> 47:02.520]  So essentially it's a PHP, SSL encrypted web proxy.
[47:02.680 --> 47:13.900]  So if you don't have, if you don't have the FWNOP command binary on your local system, you can use your web browser, this proxy, and have it generate an SBA packet for you to whatever external system.
[47:14.040 --> 47:18.700]  And of course, remember that the actual IP addresses are all in the, in the SBA packet itself.
[47:18.980 --> 47:20.840]  So you just tell it what IP you want to allow.
[47:20.840 --> 47:23.780]  And then, and then the access will be, will be allowed.
[47:25.480 --> 47:26.500]  SSL plug-in would be great.
[47:27.640 --> 47:29.600]  I mean, a Mozilla plug-in would be great.
[47:30.580 --> 47:32.320]  So I'm running out of time here.
[47:32.520 --> 47:34.040]  So maybe just one more minute.
[47:36.660 --> 47:38.480]  The, here are a few of the things.
[47:38.760 --> 47:44.420]  If you, if you have iPhone development experience and you would like to get involved in the FWNOP project, please let me know.
[47:44.580 --> 47:46.400]  We're looking for a maintainer of that.
[47:47.900 --> 47:50.580]  There are lots of things that you can do.
[47:50.580 --> 47:57.520]  So, to, to, to make the FWNOP protocol perhaps more efficient.
[47:57.720 --> 47:59.380]  A packed binary protocol would be nice.
[47:59.720 --> 48:03.780]  And also, playing tricks with various applications.
[48:04.140 --> 48:10.220]  There's, you know, single packet authorization kind of implies that you can't use TCP in a sense.
[48:10.400 --> 48:10.520]  Right?
[48:10.700 --> 48:16.160]  I mean, you don't want to require that you have to run a server in order to gain this, get this kind of information across the wire.
[48:17.080 --> 48:33.260]  Having said that, DNS and, and others, you know, you could still see, I think, interesting applications of the principle of a lightweight cryptographic layer, hardening other services that may have a larger attack surface.
[48:33.440 --> 48:36.880]  And that's the general point of both port knocking and SBA.
[48:37.940 --> 48:40.340]  So, with that, thank you very much.
[48:50.330 --> 48:51.170]  Any other questions?
[48:51.310 --> 48:52.430]  I don't, is the next speaker here?
[48:53.270 --> 48:53.950]  Oh, great.
[48:54.190 --> 48:55.090]  What's your email?
[48:55.410 --> 48:56.130]  Oh, yes.
[48:58.210 --> 48:58.890]  There you go.
[48:59.110 --> 49:02.530]  So, that, that's the, please email me if you have any questions.