Tales from the Crypto : TCP/IP

How FTP Data Connections Work Part 1 (OR: Don’t Open Port 20 in your Firewall!)

Alun Jones — Thu, 09 Jul 2009 06:18:42 GMT

This will be the first of a couple of articles on FTP, as I’ve been asked to post this information in an easy-to-read format in a public place where it can be referred to. I think my expertise in developing and supporting WFTPD and WFTPD Pro allow me to be reliable on this topic. Oh, that and the fact that I’ve contributed to a number of RFCs on the subject.

Enough TCP to be dangerous

First, a quick refresher on TCP – every TCP connection can be thought of as being associated with a “socket” at each device along the way – from one computer, through routers, to the other computer. The socket is identified by five individual items – the local IP address, the local port, the remote IP address, the remote port, and the protocol (in this case, the protocol is TCP).

Firewalls are essentially a special kind of router, with rules not only for how to forward data, but also rules on connection requests to drop or allow. Once a connection request is allowed, the entire flow of traffic associated with that connection request is allowed, also – any traffic flow not associated with a previously allowed connection request is discarded.

When you set up a firewall to allow access to a server, you have to consider the first segment – the “SYN”, or connection request from the TCP client to the TCP server. The rule can refer to any data that would identify the socket to be created, such as “allow any connection request where the source IP address is 10.1.1.something, and the destination port is 54321”.

Typically, an external-facing firewall will allow all outbound connections, and have rules only for inbound connections. As a result, firewall administrators are used to saying things like “to enable access to the web server, simply open port 80”, whereas what they truly mean is to add a rule that applies to incoming TCP connection requests whose source address and source port could be anything, but whose destination port is 80, and whose destination address is that of the web server.” This is usually written in some short hand, such as “allow tcp 0.0.0.0:0 10.1.2.3:80”, where “0.0.0.0” stands for “any address” and “:0” stands for “any port”.

Firewall rules for FTP

For an FTP server, firewall rules are known to be a little trickier than for most other servers.

Sure, you can set up the rule “allow tcp 0.0.0.0:0 10.1.2.3:21”, because the default port for the control connection of FTP is 21. That only allows the control connection, though.

What other connections are there?

In the default transfer mode of “Stream”, every file transfer gets its own data connection. Of course, it’d be lovely if this data connection was made on port 21 as well, but that’s not the way the protocol was built. Instead, Stream mode data connections are opened either as “Active” or “Passive” connections.

Active and Passive Data Connections

The terms "Active" and "Passive" refer to how the FTP server connects. The choice of connection method is initiated by the client, although the server can choose to refuse whatever the client asked for, at which point the client should fail over to using the other method.

In the Active method, the FTP server connects to the client (the server is the “active” participant, the client just lies back and thinks of England), on a random port chosen by the client. Obviously, that will work if the client's firewall is configured to allow the connection to that port, and doesn't depend on the firewall at the server to do anything but allow connections outbound. The Active method is chosen by the client sending a “PORT” command, containing the IP address and port to which the server should connect.

In the Passive method, the FTP client connects to the server (the server is now the “passive” participant), on a random port chosen by the server. This requires the server's firewall to allow the incoming connection, and depends on the client's firewall only to allow outbound connections. The Passive method is chosen by the client sending a “PASV” command, to which the server responds with a message containing the IP address and port at the server that the client should connect to.

The ALG comes to the rescue!

So in theory, your firewall now needs to know what ports are going to be requested by the PORT and PASV commands. For some situations, this is true, and you need to consider this – we’ll talk about that in part 2. For now, let’s assume everything is “normal”, and talk about how the firewall helps the FTP user or administrator.

If you use port 21 for your FTP server, and the firewall is able to read the control connection, just about every firewall in existence will recognise the PORT and PASV commands, and open up the appropriate holes. This is because those firewalls have an Application Level Gateway, or ALG, which monitors port 21 traffic for FTP commands, and opens up the appropriate holes in the firewall. We’ve discussed the FTP ALG in the Windows Vista firewall before.

So why port 20?

Where does port 20 come in? A rather simplistic view is that administrators read the “Services” file, and see the line that tells them that port 20 is “ftp-data”. They assume that this means that opening port 20 as a destination port on the firewall will allow FTP data connections to flow. By the “elephant repellant” theory, this is proved “true” when their firewalls allow FTP data connections after they open ports 21 and 20. Nobody bothers to check that it also works if they only open port 21, because of the ALG.

OK, so if port 20 isn’t needed, why is it associated with “ftp-data”? For that, you’ll have to remember what I said early on in the article – that every socket has five values associated with it – two addresses, two ports, and a protocol. When the data connection is made from the server to the client (remember, that’s an Active data connection, in response to a PORT command), the source port at the server is port 20. It’s totally that simple, and since nobody makes firewall rules that look at source port values, it’s relatively unimportant. That “ftp-data” in the Services file is simply so that the output from “netstat” has a meaningful service name instead of “:20” as a source port.

Coming up in part 2…

Next time, we’ll expand on this topic, to go into the inability of the ALG to process encrypted FTP control traffic, and the resultant issues and solutions that face encrypted FTP.

Debugging SSTP error -2147023660

Alun Jones — Wed, 28 Jan 2009 14:57:45 GMT

Setting up an SSTP (Secure Socket Tunneling Protocol) connection earlier, I encountered a vaguely reminiscent problem. [SSTP allows virtual private network – VPN – connections between clients running Vista Service Pack 1 and later and servers running Windows Server 2008 and later, using HTTP over SSL, usually on port 443. Port 443 is the usual HTTPS port, and creating a VPN over just that port and no other allows it to operate over most firewalls.]

The connection just didn’t seem to want to take, even though I had already followed the step-by-step instructions for setting up the SSTP server. I thought I had resolved the issue originally by ensuring that I installed the certificate (it was self-signed) in the Trusted Roots certificate store. [If the certificate was not self-signed, I would have ensured that the root certificate itself was installed in Trusted Roots]

The first thing I did was to check the event viewer on the client, where I found numerous entries.

I found error -2147023660 in the Application event log from RasClient. This translates to 0x800704D4, ERROR_CONNECTION_ABORTED. That was pretty much the same information I already had, that the connection was being prevented from completing. So I visited the server to see if there was more information there.

On the server, I couldn’t find any entries from the time around when I was trying to connect. Not too good, because of course that’s where you’re going to look. In some cases, particularly errors that Microsoft thinks are going to happen too frequently, the conditions are checked at boot-time, and an error reported then, rather than every time the service is called on to perform an action.

Fortunately, it hadn’t been that long since I last booted (and I had a hint or two from the RRAS team at Microsoft), so my eyes were quickly drawn to an Event with ID 24 in the System Log, sourced at Microsoft-Windows-RasSstp. The text said:

The certificates bound to the HTTPS listener for IPv4 and IPv6 do not match. For SSTP connections, certificates should be configured for 0.0.0.0:Port for IPv4, and [::]:Port for IPv6. The port is the listener port configured to be used with SSTP.

Note that this happens even if your RRAS server isn’t configured to offer IPv6 addresses to clients.

So, here’s some documentation on event ID 24 :

http://technet.microsoft.com/en-us/library/cc733844.aspx

This is one of those nasty areas where there is no user interface other than the command-line. Don’t get me wrong, I love being able to do things using the command line, because it’s easy to script, simple to email to people who need to implement it, and it works well with design-approve-implement processes, where a designer puts a plan together that is approved by someone else and finally implemented by a third party. With command-line or other scripts, you can be sure that if the script didn’t change on its way through the system, then what was designed is what was approved, and is also what was implemented.

But it’s also easy to get things wrong in a script, whereas a selection in a UI is generally much more intuitive. It’s particularly easy to get long strings of hexadecimal digits wrong, as you will see when you try and follow the instructions above. Make sure to use copy-and-paste when assembling your script, and read the output for any possible errors.

Kaminsky Black-Hat Webcast: "By Any Other Name: DNS has doomed us all."

Alun Jones — Fri, 25 Jul 2008 09:03:00 GMT

Okay, so the talk’s official title was “Dan Kaminsky’s DNS Discovery: The Massive, Multi-Vendor Issue and the Massive, Multi-Vendor Fix”.

Arcane details of TCP are something of a hobby of mine, so I attended the webcast to see what Dan had to say.

The Past is Prologue

A little history first – six months ago, Dan Kaminsky found something so horrifying in the bowels of DNS that he actually kept quiet about it. He contacted DNS vendors – OS manufacturers, router developers, BIND authors, and the like – and brought them all together in a soundproofed room on the Microsoft campus to tell them all about what he’d discovered.

Everyone was sworn to secrecy, and consensus was reached that the best way to fix the problem would be to give vendors six months to release a coordinated set of patches, and then Dan Kaminsky would tell us all at BlackHat what he’d found.

Until then, he asked the security community, don’t guess in public, and don’t release the information if you know it.

Now is the winter of our DNS content (A records and the like)

Fast forward a few months, and we have a patch. I don’t think the patch was reverse-engineered, but there was enough public guessing going on that someone accidentally slipped and leaked the information – now the whole world knows.

Kaminsky confirmed this in today’s webcast, detailing how the attack works, to forge the address of www.example.com:

Attacker persuades victim to ask for 1.example.com
Victim’s DNS server queries for an A record for 1.example.com
Attacker forges a response that says “I don’t know 1.example.com, but the DNS server at www.example.com knows, and it’s at 1.2.3.4”
Victim’s DNS server accepts this response, queries 1.2.3.4 for 1.example.com, and now the attacker knows that the victim can be directed to www.example.com at 1.2.3.4, allowing the attacker to steal cookies, represent as a trusted web site, etc, etc.

Note that this is a simple description of the new behavior that Kaminsky found – step 3 allows the DNS server’s cache to be poisoned with a mapping for www.example.com to 1.2.3.4, even if it was already cached from a previously successful search.

If that was all that Kaminsky could do, even on an unpatched server, he’d have a 1 in 65535 chance of guessing the transaction ID to make his forgery succeed. However, old known behaviours simply make it easier for the attacker to make the forgery work:

Because the attacker tells the victim to search for a site, the attacker controls when the race with the authoritative DNS server starts.
The attacker can tell the victim to search several times, and can forge several possible responses, using the birthday paradox to be more likely to guess the transaction ID (and source port), so that his forged response is accepted.
Because this attack overwrites cached entries, the attacker can try again and again (picture a site with a million 1-pixel images each causing a different DNS query) until he is successful. Stuffing the cache won’t protect you.
The attacker can insert an obscenely huge TTL (time-to-live) on the faked entry, so that it remains in cache until the DNS service is flushed or restarted.

Kaminsky’s tests indicate that a DNS server’s cache can be poisoned in this way in under ten seconds. There are metasploit plugins that ‘demonstrate’ this (or, as with all things metasploit, can be used to exploit systems).

The patch, by randomizing the source port of the DNS resolver, raises the difficulty of this attack by a few orders of magnitude.

The long-term fix, Kaminsky said, is to push for the implementation of DNSSEC, a cryptographically-signed DNS system, wherein you refuse to pass on or accept information that isn’t signed by the authoritative host.

A port, a port, my domain for a port

One novel wrinkle that Kaminsky hadn’t anticipated is that even after application of the patch to DNS servers, some NATs apparently remove the randomness in the source port that was added to make the attack harder. To quote Kaminsky “whoops, sorry Linksys” (although Cisco was one of the companies he notified of the DNS flaw, and they now own Linksys). Such de-randomising NATs essentially remove the usefulness of the patch.

Patching is not completely without its flaws, however – Kaminsky didn’t mention some of the issues that have been occurring because of these patches:

ZoneAlarm decided that DNS queries from random source ports must be a sign of attack, and denied all such queries, essentially disconnecting the Internet from users of ZoneAlarm. I guess I can learn to live with that.
BIND doesn’t check when binding to a random port to see if that port is already in use – as a result, when the named server sends out a DNS query, there’s a chance the response packet will come back to a service that isn’t expecting it. Because the outgoing query punches a return hole in most firewalls, this could mean that a service blocked by the firewall from receiving Internet traffic is now opened up to the Internet. The workaround is to set the avoid-udp-v4-ports configuration setting, listing any ports that named shouldn’t use.
Windows’ DNS service takes a different tack, binding to 2500 (the number is configurable) random ports on startup. As with BIND, these ports might conflict with other services; different from BIND, however, is the behavior – since the ports are already bound by the DNS server, those other services (starting later than DNS, because most IP components require it) are now unable to bind to that port. As with BIND, the workaround is to tell the DNS server which ports not to use. The registry entry ReservedPorts will do this.
Users are being advised to point their DNS server entries to OpenDNS. Single point of failure, anyone?

Metrics and statistics:

When Kaminsky’s vulnerability detection tool was first made available at doxpara.com, 80+% of all checks indicated that the DNS server was vulnerable. This last week, 52% of all checks showed vulnerable servers. Patches are getting installed.
The attack is noisy – output from the metasploit framework showed “poisoning successful after 13250 attempts” – that’s thirteen thousand DNS queries and 260,000 forged DNS responses. IDS and IPS tools should have signatures for this attack, and may be able to repel boarders.
Metasploit exploits for this are at http://www.caughq.org/exploits/CAU-EX-2008-0003.txt if you want to research it further.

Tomorrow, and tomorrow, and tomorrow...

The overall message of the webcast is this:

This attack is real, and traditional defences of using a high TTL will not protect you. Patching is the way to go. If you can’t patch, configure those unpatched DNS servers to forward to a local new (patched) DNS server, or an external patched server like OpenDNS. Scan your site for unexpected DNS servers.

Whoops - Information Wanted to be Free Again.

Alun Jones — Tue, 22 Jul 2008 05:09:51 GMT

Picture the scene at Security Blogs R Us:

"We're so freakin' clever, we've figured out Dan Kaminsky's DNS vulnerability"

"Yeah, but what if someone else figures it out - won't we look stupid if we post second to them?"

"You're right - but we gave Dan our word we wouldn't publish."

"So we won't publish, but we'll have a blog article ready to go if someone else spills the beans, so that we can prove that we knew all about it anyway."

"Yeah, but we'd better be careful not to publish it accidentally."

>>WHOOP, WHOOP, WHOOP<<

"What was that?"

"The blog alert - someone else is beating us to the punch as we speak."

"Publish or perish! Damn the torpedoes - false beard ahead!"

"What? Are you downloading those dodgy foreign-dubbed pirated anime series off BitTorrent through the company network again?"

"Yes - I found a way around your filters."

"Good man."

It's true (okay, except for all of the made-up dialog above), a blog at one of the security vulnerability research crews (ahem, Matasano) did the unthinkable and rushed a blog entry out on the basis that they thought someone else (ahem, Halvar Flake) was beating them to it. And now we all know. The genie is out of the bag, the cat has been spilled, and the beans are out of the bottle.

Now we all know how to spoof DNS.

Okay, so Matasano pulled the blog pretty quickly, but by then it had already been copied to server upon server, and some of those copies are held by people who don't want to take the information off the Internet.

Clearly, Information Wants To Be Free.

There's an expression I never quite got the hang of - "Information Wants To Be Free", cry the free software guys (who believe that software is information, rather than expression, which is a different argument entirely) - and the sole argument they have for this is that once information is freed, it's impossible to unfree it. A secret once told is no longer a secret.

There's an allusion to the way in which liquid 'wants to be at its lowest level' (unless it's liquid helium, which tends to climb up the sides of the beaker when you're not looking), in that if you can't easily put something back to where it used to be, then where it used to be is not where it wants to be.

So, information wants to be free, and Richard Stallmann's bicycle tyre wants to have a puncture.

But back to the DNS issue.

I can immediately think of only one extra piece of advice I'd have given to the teams patching this on top of what I said in my previous blog, and that's something that, in testing, I find the Windows Server 2003 DNS server was doing anyway.

So, that's alright then.

Well, not entirely - I do have some minor misgivings that I hope I've raised to the right people.

But in answer to something that was asked on the newsgroups, no I don't think you should hold off patching - the patch has some manual elements to it, in that you have to make sure the DNS server doesn't impinge on your existing UDP services (and most of you won't have that many), but patching is really a whole lot better than the situation you could find yourself in if you don't patch.

And Dan, if you're reading this - hi - great job in getting the big players to all work together, and quite frankly, the secrecy lasted longer than I expected it to. Good job, and thanks for trying to let us all get ourselves patched before your moment of glory at BlackHat.

DNS Server Reserves 2500 Ports.

Alun Jones — Sat, 19 Jul 2008 07:02:00 GMT

After applying the patch for MS08-037 - KB 953230 (the multi-OS DNS flaw found by Dan Kaminski), you may notice your Windows Server 2003 machine gets a little greedy. At least, mine sucks up 2500 - yes, that's two thousand five hundred - UDP sockets sitting there apparently waiting for incoming packets.

This is, apparently, one of those behaviours sure to be listed in the knowledge base as "this behavior is by design" - a description that graces some of the more entertaining elements of the Microsoft KB.

Why does this happen? I can only guess. But here's my best guess.

The fix to DNS, implemented across multiple platforms, was to decrease the chance of an attacker faking a DNS response, by increasing the randomness in the DNS requests that has to be copied back in a response.

I don't know how this was implemented on other platforms, but I do know that it's already been reported that BIND's implementation is slower than it used to be (hardly a surprise, making random numbers is always slower than simply counting up) - and maybe that's what Microsoft tried to forestall in the way that they create the random sockets.

Instead of creating a socket and binding it to a random source port at the time of the request, Microsoft's patched DNS creates 2500 sockets, each bound to a random source port, at the time that the DNS service is started up. This way, perhaps they're avoiding the performance hit that BIND has been criticised for.

There are, of course, other services that also use a UDP port. ActiveSync's connection to Exchange, IPsec, IAS, etc, etc. Are they affected?

Sometimes.

Randomly, and without warning or predictability. Because hey, the DNS server is picking ports randomly and unpredictably.

[Workaround: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\ReservedPorts is a registry setting that lists multiple port ranges that will not be used when binding an ephemeral socket. The DNS server will obey these reservations, and not bind a socket to ports specified in this list. More explanation in the blog linked above, or at http://support.microsoft.com/kb/812873]

DNS, you see, is a fundamental underpinning of TCP/IP services, and as such needs to start up before most other TCP/IP based services. So if it picks the port you want, it gets first pick, and it holds onto that port, preventing your application from binding to it.

This just doesn't seem like a fix written by someone who 'gets' TCP/IP. Perhaps I'm missing something that explains why the DNS server in Windows Server 2003 works this way, but I would be inclined to take the performance hit of binding and rebinding in order to find an unused random port number, rather than binding before everyone else in an attempt to pre-empt other applications' need for a port.

There are a couple of reasons I say this:

Seriously, how many Windows Server 2003 users out there have such a high-capacity DNS server that they will notice the performance hit?
Most Windows Server 2003-based DNS servers are small caching servers for businesses, rather than Internet infrastructure servers responsible for huge numbers of requests per second - even if you implement this port-stealing method, it shouldn't be the default, because the majority of users just don't need that performance.
If you do need the performance, get another server to handle incoming requests. Because the cost of having your DNS server's cache poisoned is considerably greater than the cost of increasing the number of servers in your pool, if you're providing major DNS service to that many customers.
A major DNS service provider will be running fewer services that would pre-empt a DNS server request to bind to a random port, whereas systems running several UDP-based services are going to need less performance on their outgoing DNS requests.

I'd love to know if I'm missing something here, but I really hope that Microsoft produces a new version of the DNS patch soon, that doesn't fill your netstat -a output with so many bound and idle sockets, each of which takes up a small piece of nonpaged pool memory (that means real memory, not virtual memory).

Vista's Secret Windows Firewall hole

Alun Jones — Fri, 25 Jan 2008 05:19:00 GMT

First, the good news - it's not a flaw in the operation of Windows Firewall on Windows Vista. It's a design feature, it makes sense, and it fits in with the principle that the firewall should keep out unsolicited traffic. It's not really a hole, but I thought I'd grab your attention.

The symptom first came up in a Usenet posting (thanks, Jesper, for bringing me in) about Vista and a third-party FTP client:

When I do a directory listing, and a PORT command is issued, and the
server attempts to connect, it works, but at the same time a dialogue
appears telling me it's blocked, and I can keep blocking or unblock.
I choose keep blocking but it doesn't actually block it once.

Here's how it looks.

First, if you haven't got a third-party FTP client let's fake it, by copying Microsoft's command-line FTP client from the Windows System32 directory to another directory:

C:\users\MyMe> copy %windir%\system32\ftp.exe
1 file(s) copied.

The FTP client will not display prompts to you, but that's a minor issue - if it upsets you, try downloading a third-party client and trying it.

Anyway, here we go - let's try the issue in question:

Type ftp ftp.microsoft.com
After you see the "220" greeting message, enter ftp as the user - press enter.
Now you're prompted for a password - enter anything and press enter.
Once you're logged on, enter dir - again, press enter.
You'll see the directory listing succeed, but you'll also see a warning that a connection is being blocked:

Wow - that's freaky - at the same time you're being told that the connection used for the file listing will be blocked, it allows the connection through!

What's more, even if you specify Keep Blocking, and then go issue another dir command, that one succeeds.

Huh? And why on earth did you make me use a copy of FTP?

Let's go look at the Windows Advanced Firewall Rules for Inbound, and see if this sheds any light:

[That means click the Start button, type Firewall into the search box, and right-click on Windows Firewall with Advanced Security - select Run as Administrator

and accept the elevation prompt from UAC. If you don't have an elevation prompt, then you should really re-enable UAC. Now select Inbound Rules in the left-hand pane]

Me, I've got a few rules labeled File Transfer Program:

That first (and fourth) rule is set to block any listening ports opened by the File Transfer Program in C:\users\myme\ftp.exe, the second two seem to be allowing any listening ports created by the one in C:\windows\system32\ftp.exe.

Obviously, that's why I asked you to copy ftp.exe to a new directory, so that any previous allowance by the firewall rules wouldn't get in the way.

So what's happening here? Is the "Allow" rule somehow overriding the "Block" rule, even though it's not dealing with the same executable?

We can test that simply by deleting both sets of rules - go ahead and do that, I'll wait for you.

Didn't make a bit of difference, did it? It still allowed the traffic, then prompted you if you wanted to block it. Even if you selected to "Keep Blocking", the next and subsequent transfers still worked, right?

Okay - let's consult the Big Book of Knowledge (alright, what I can vaguely remember after mumbleteen years in the networking world). Some routers and firewalls use an Application Layer Gateway (ALG) to translate FTP commands, and open ports. Is that what's going on here?

Let's take a peek at the services on this machine (as an administrator, run services.msc):

Bingo - there it is, the Application Layer Gateway Service. And when you have Internet Connection Sharing running, that's what translates IP addresses in FTP commands for you, and what opens up port mappings and holes in the NAT that ICS hosts.

Oh, but wait a moment - what's that in the "Status" column?

That's right, nothing. This service isn't running.

Something must be happening to open this port up - it's not just a case of "port left open", nor is it an outbound port. Those ports are closed tight until the FTP client starts listening for incoming data connections, and then they're opened up.

Here's where I go into MVP-mode, and start searching in all the nooks and crannies of the web and whatever documentation it holds.

Net result - Windows Firewall in Windows Vista includes something called a "connection inspection engine".

Sounds like something from "Schoolhouse Rock".

No, seriously, there's a "connection inspection engine" for FTP - if you connect to port 21, the firewall monitors your communications on that channel, looking for PORT commands. When it finds one, it opens up a hole in the firewall for the incoming data connection.

So why the scary dialog warning that something's going to block traffic?

Probably because the dialog pops up whenever an application starts listening, whereas the connection inspection engine only opens a hole when it sees a PORT command. And an FTP client can't actually give the PORT command until it's started listening.

So, the process goes something like this:

Start the FTP client.
Connect to the FTP server on port 21, waking up the connection inspection engine.
Log on, then type dir
The FTP client knows that it needs to open a data connection.
To start the data connection, the FTP client binds to port 0, and starts listening.
The firewall says "Oh no, an unknown program has started listening - better warn them that they won't get any traffic."
The FTP client checks what port it actually got, and sends a matching PORT command.
The connection inspection engine says "PORT command? That's my cue!" and opens a hole in the firewall to incoming data connections.

Well, that's easy, but what if I don't ever want to do an FTP connection? How do I stop this from becoming a potential hacker tool?

Okay, apart from the obvious - that if a hacker could connect out to a server on port 21, nothing's stopping that hacker from transferring data in - you might want to cripple this functionality.

No problem - just set the following DWORD registry value to 1:

HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ SharedAccess \ Parameters \ FirewallPolicy \ DisableStatefulFTP

The default setting for this value on Windows Vista is 0. [It remains to be seen what value will be the default on Windows Server 2008]

How could Microsoft make this better?

I'd really like to see this documented. Just so that it's not a surprise to anyone.
I'd like to know how many other connection inspection engines there are (at least one, judging from the DisableStatefulPPTP value - but I don't know enough about PPTP to know how that affects operation).
I'd like to know if I can add my own connection inspection engine to the firewall.
Above all, I'd like to do away with the rather confusing and clumsy "We're going to block your incoming ... wait, what just happened?" dialog. If the connection inspection engine is monitoring a command channel, and the process that owns the socket for that command channel starts listening, perhaps we could wait a quarter of a second for a PORT command before calling this a blocked connection?

Finally, is this a vulnerability, a hole, or anything outside the correct operation of a firewall?

No, because the firewall is documented as blocking unsolicited incoming connections - and by any reasonable definition, the data connection requested by a PORT command is solicited.

Is a NAT a security device?

Alun Jones — Sat, 29 Dec 2007 19:23:12 GMT

I've been working lately on a couple of IPv6-related projects. First, there's a chapter for an upcoming book, and second, there's the effort to make WFTPD and WFTPD Pro work on IPv6, since it's enabled by default in Windows Vista and Windows Server 2008 [more on that in a future post].

A big argument to my mind, as an old-school Internet user, for enabling IPv6 is that every one of your hosts becomes a fully-fledged Internet participant, like it used to be with IPv4 back in the '90s.

What do I mean by that?

I mean that every machine is reachable at its own address on every port that it chooses to open, rather than requiring someone to tinker with a NAT to open port mappings for specific applications.

IPv6 removes the need for a NAT at all.

Wow. To a security professional, that's a shocking statement. It feels rather like saying that living in a tent removes the need for locks. How on earth do you protect your stuff without a NAT?

The answer is that a NAT was never intended to be a security device - it just happened, somewhat accidentally, that requiring address translation and port mapping to be statically configured created a security barrier.

Unfortunately, NATs also killed a lot of protocols (H.323 for webcams, FTP for file transfers - particularly when secured, IPsec) that quote IP addresses in their traffic.

To some extent this was fixed with ALGs - Application Layer Gateways - but never very satisfactorily (particularly in the case of secured FTP). What would be far better is to have a device that had the blocking advantages of a NAT, but didn't require IP addresses and ports to be altered in transit.

There's a name for such a device:

A firewall.

[Only if the firewall is configured by default to list all ports as "closed". An open-by-default firewall is not a firewall, it's a router.]

And a firewall is a far simpler program than a NAT (even if it's in hardware, it's the program's simplicity that matters most). If it matches incoming traffic to ports that are opened, it allows that traffic in. If outgoing traffic occurs on a port that was closed, the firewall usually opens that port for the reverse traffic, so that clients on the inside of the firewall can get a response.

So, when the time comes that your network is required to transition to IPv6, don't beg for an IPv6 NAT. I actually hope such a device doesn't actually exist, and that nobody's stupid enough to develop one. What you should insist on is an IPv6 firewall.

"But what about the problem that the layout of my network inside of the firewall will be revealed?" you might ask.

It won't, because IPv6 addresses are sparsely allocated.

"How about machines that won't ever need to be accessed by, or access out to, anything outside my company? What's the IPv6 equivalent of an RFC 1918 address?"

No problem - there's a standard for link-local and site-local (Unique Local Unicast, technically) addressing, which will never be routed outside of your site.

Any other reasons you're clinging to the idea that a NAT is a security device?