Combining Port Knocking With OS Fingerprinting

michaelrash writes "Port knocking implementations are on the rise. I have just released fwknop; (the Firewall Knock Operator) at DEF CON 12. Fwknop implements both shared and encrypted knock sequences, but with a twist; it combines knock sequences with passive operating system fingerprints derived from p0f. This makes it possible to allow, say, only Linux systems to connect to your SSH daemon. Fwknop is based entirely around iptables log messages and so does not require a separate packet capture library. Also, at the Black Hat Briefings, David Worth has released a cryptographic port knock implementation based around one-time pads."

It's kinda cool

but is anyone out there using port knocking for serious security?

LK

Re:It's kinda cool

Not only is it security through obscurity

Only in the same sense that passwords are security through obscurity.

Right combination of keystrokes, right combination of ports to knock, these sound very similar to me.

LK

Re:It's kinda cool

There is absolutely nothing wrong with using something a bit obscure to help fend off attacks.

The only time that "security through obscurity" is wrong is if that is your entire approach to security.

Even if you have the latest and greatest copy of the most secure software written to perform some service, there is always a possibility that there is something exploitable that is yet unknown.

Port knocking is an excellent way to greatly reduce the probability that someone will be able to use a newly discovered exploit from using it against your server before an update is available to fix the exploit.

Of course, if someone is in the right place and can monitor the network traffic from another computer somewhere along the path, they can discover the port knocking sequence. For that reason, you still need your normal security and you still need to keep the patches up to date.

But the result will still be a vastly improved possibility of avoiding an attack when a vulnerability is found.

Re:It's kinda cool

It's not.. I almost suspect you of trolling.

The primary purpose of port knocking is to hide the fact that you have open ports to begin with. You don't want to have those ports unprotected once the right knock sequence is in place. You want both password/challenge AND port knocking so no active scanner detects your open ports.

Re:It's kinda cool

I use portsentry for protection against scans. The result is that all my ISP scanners are now in hosts.deny and consequenlty I can run any server I want and they will never know and can't complain about it...

How much more is needed?

With a large port knock routine say 20 ports or more, can't you be sure it's YOUR box that's comming in? More defense and limitations are good, sure, but why filter by OS? Is it in case someone gets by the knock?

Re:How much more is needed?

Because the next step is to generate 'fake' OS fingerprints for the client computer, thus insuring not only must someone reply with the right sequence, but also send back the nuances of a specific OS to do so... kinda like recieving a callback to which you must reply in the proper accent before you'll be allowed in :)

The above is completely conjecture, but it sure does sound cool ;p

-- vranash

Re:How much more is needed?

Well, as another poster pointed out, if someone sniffs what ports you're connecting to, then it would be simple to replay that knock. That's the reason you need a security level underneath it, and shouldn't rely on port knocking unless it's a changing sequence (like the one-time pad idea also mentioned in the post).

I'm not quite sure how the OS detection is supposed to help. Maybe you could customize things for different OSes? As long as port knocking schemes are implemented on two OSes, you could let the port knocker determine which OS you're connecting from, and connect to a specific service depending upon it. I don't really see any other use for the OS-dependent port knocking, but it's something that's cool, and not been done before, so I guess it's news-worthy.

OS fingerprinting, whew!

thank goodness, if there's one thing a hacker can't get his hands on, it's a copy of Linux!

yuk yuk yuk

Layers

1. TCPWrappers (has to be be right IP and/or daemon)
2. Portknocking (has to have the right sequence)
3. Passive Fingerprinting (only Linux and BSD systems can connect)
4. Keys Only (you must have the correct DSA private key)

Usually unnecessary, yet very interesting - much like Slashdot itself....

The more complicated you make it,

the bigger is the chance of screwing up. The point of port knocking is to have a simple and therefore less bug prone layer around real authentication systems like ssh, so that when a bug in ssh is found, portscanners don't find your vulnerable service. Complicated port knocking systems defeat the purpose of port knocking.

In other news...

Microsoft IIS has implemented a similar scheme to only allow HTTP sessions to Microsoft OS running clients.

Port knocking and some added ingredients

While port knocking is by now an established technique, I do not think OS fingerprinting adds anything useful, because the ease of static replay attacks is left unchanged by OS fingerprinting.
Though not that easy, OS spoofing is not remarkably labour intensive, and setting up a "OS generator" who will replay the static attack with every known OS is a distinct possibility.
In other words, though a nice intellectual possibility, it is perhaps of rather limited application.
Now, mixing instead knocking and a cryptographic application seems to me instead more promising.

Port knocking, firewalls, DMZs,...

are techniques I've seen appearing for the last 10 years that are designed to compartment sections of the net. They make me sad, because that's definitely not what the net was intended to be, i.e. a global interconected network of machines to freely communicate. Instead, the net is slowly being segregated, and you'll soon have to show some sort of proof of identity to do anything other than HTTP. If you don't believe me, just consider how hard it is to do something as mundane as a DCC CHAT on IRC today, as opposed to, say, in 1994.

I realize the need for these things, basically forced upon us by the combination of commercial interests, shitty insecure OS, script kiddies and greedy crackers (not hackers), but all the same, I can't help realize that the internet of today is a far cry from what it was intended to be in terms of freedom of communication...

Re:Port knocking, firewalls, DMZs,...

I agree with your points, but surely you must see that this commentary of yours applies to pretty much every invention known to man that is both powerful and started out being free and open.

Look at air travel - there you have spend a ton of time just getting on a plane because of very few bad people. The Wright brothers didn't want this, I'm sure, but it doesn't mean the invention is being perverted in any way; it only says that our world is hostile and that we must protect ourselves from ourselves. Anything useful and completely open these days is ripe for exploitation.

Re:Port knocking, firewalls, DMZs,...

Never under-estimate the power of stupid people in large groups.

I can't help realize that the internet of today is a far cry from what it was intended to be in terms of freedom of communication

Um...wasn't the internet born at the department of defense? Awfully nice of them, to make this huge network for freedom of communication.

Oh, wait, that's not what it was intended for. It was intended to be a network of communication, built to survive outages of several large nodes, in case of a nuclear attack. It's only been as more and more people began romaticising it, that we've come up with this free communications thing.

While I'm not apposed to it, I am realistic about it. Would you leave your car, complete with keys, parked in a stadium parking lot, with an open door, and a sign stuck on the steering wheel saying, "Please don't take"? That's essentially what you do with your computer when you go online without any sort of protection ( short of the sign, mind you ).

Re:Port knocking, firewalls, DMZs,...

I'm not a history buff but I can't recall anything I've read about ARPAnet being created with the intention of complete access to all connected machines.

I think the majority of people - geeks included, but not to the exclusion of everyone else - think the internet, on the whole, is performing fairly reasonably. Just like in reality, when you have a small group of people working together, issues of trust are much easier to deal with compared to working with hundreds of millions of people.

Blaming "commercial interests, shitty insecure OS, ..." are symptoms of having a ton of people connected. Assuming the internet would be perfect if those bad people didn't exist, there'd be a new group people didn't like: spammers, NET SENDers, etc. Once they are gone, we'd be left with people that use software we don't like, or people from a country we don't like.

Soon enough, the Internet would be compartmentalized exactly the way you fear - into groups of like-minded people instead.

The Internet isn't supposed to be utopia. It was about making resources easier to access and it does that job amazingly well, given the imperfect people using it.

Security Through Obscurity

Not more - not less. All that portknocking does is shifting the security to a layer where it doesn't belong.

And even if you don't want others to see that there are services running on your host there are better solutions. e.g. sending a special string to some UDP port.

If someone can sniff your traffic and he knows about portknocking it's trivial for him to detect it. If someone can't sniff your traffic there's no advantage in using portknocking.

Re:Security Through Obscurity

Port knocking has one specific and reasonable purpose: It hides open ports from port scanners. Yes, it's security by obscurity, but as it's supposed to be another layer, it can increase security if, and only if it's simple enough that there is a near-zero chance of introducing new exploitable bugs into the system. Passive monitoring is not necessarily unexploitable. There are bugs in packet capture tools. There will be exploitable bugs in complicated port knocking daemons. Keep port knocking simple and it can be a valuable security enhancement. Make it complicated and it becomes another thing that can break.

Port knocking buys you the time between a new ssh exploit and the fix. It significantly reduces the chance of being found by portscanners and therefore of being hacked. You still have to fix ssh though.

Re:Security Through Obscurity

People who make blanket statements like "Security through obscurity is bad" really annoy me. What a load of crap.

Secuirty through obscurity is bad when it's the only form of security. However, what is bad about using it to enhance existing security? What is bad about making things that little bit more difficult for a hacker?

No where in this has the author said you should replace your existing security models with this. All it's done is add another layer to help disguise your existing security making it that much harder to crack. No one has "shifted" the security anywhere.

Re:Security Through Obscurity

I agree that UDP could be used similarly to port knocking. Both methods will serve equally well when the attacker is unaware of the method you choose to use. (true security through obsecurity). I also agree that both methods are equally vulnerable if the attacker can sniff your network traffic, and they can get in by replaying the requests.

However, lets assume that the security daemons are *not* vulnerable to replay type attacks becuase we use one time pads, or computed keys or something. In this case, sniffing will tell the attacker what method is in use, but it won't allow them to get in by simply repeating a successful login sequence. Are the methods still equivalent?

I would think that port knocking would still be safer of the two. The port knocking monitor is still sitting behind the firewall, isolated from the network traffic. It would be more difficult to induce a failure in the monitor. Even if the monitor failed, the security would revert to the firewall -- which means you don't get in.

On the other hand, your UDP daemon would have to be written just as carefully as the services you are trying to protect. A buffer overflow, or any similar flaws in your daemon could allow someone to break in through your daemon. And such a flaw could be exploited blindly too -- all the attacker would have to suspect is that you are using a flawed daemon.

Am I wrong?

Re:Security Through Obscurity

Not more - not less. All that portknocking does is shifting the security to a layer where it doesn't belong.

Yes, but that's exactly the point. Portknocking is a steganographic application: it doesn't protect the message, but hides the existence of the message. It does so precisely because it interferes at a layer where it doesn't belong.

And even if you don't want others to see that there are services running on your host there are better solutions. e.g. sending a special string to some UDP port.

No, because having a server listen on a UDP port clearly signals the expectation of meaningful communication. The equivalent of portknocking would be a server that listens on a UDP port, but rather than looking at the string it receives, looks at (say) the delay between each byte received. Obviously network delays and other uncontrollable factors make this impractical.

If someone can sniff your traffic and he knows about portknocking it's trivial for him to detect it. If someone can't sniff your traffic there's no advantage in using portknocking.

It's not that simple. Even if somebody can sniff traffic in principle, he can't sniff everybody's traffic all the time. He has to evaluate which targets are likely to yield anything of value. Since a system protected by portknocking does not give him any clues of what he can expect to find, why would he sniff your traffic?

these ports are made for knockin'

and that's just what they'll do

one of these days these ports

are gonna walk all over you........

Daemon watching iptables

Am I the only one to wonder why the author made a deamon that watches iptable-logs and then modify the ruleset when a matching knock sequence is found instead of implementing a iptables match module instead?

Same goes for psad [cipherdyne.org] (by same author) -- I thought the purpose of iptables was to allow plug-in modules to be COMBINED.

NOT a one-time pad

This is a one-time password system, which uses hashes, just like S/Key does. This is NOT a one-time pad system.

Eh?

I thought port knocking was definitively debunked as security through obscurity.

Watching the logs..

I always considered watching logs to be a very ugly and inelegant way of doing port knocking. Netfilter is stateful, why not make use of it?

Use the recent match module and something like the following for requiring ports 1000, 2000 and 3000 to be knocked in order and within 30 seconds before allowing ssh from a particular host:

iptables -A INPUT -p tcp --dport 1000 -m recent --remove --name PART2
iptables -A INPUT -p tcp --dport 1000 -m recent --remove --name PART3
iptables -A INPUT -p tcp --dport 2000 -m recent --remove --name PART3
iptables -A INPUT -p tcp --dport 1000 -m recent --set --name PART1
iptables -A INPUT -p tcp --dport 2000 -m recent --set --name PART2
iptables -A INPUT -p tcp --dport 3000 -m recent --set --name PART3
iptables -A INPUT -p tcp --dport 22 -m recent --rcheck --seconds 30 --name PART1 --name PART2 --name PART3 -j ACCEPT

Now you don't have to clutter the system with logs and a daemon that may run into trouble.

Now... I don't know if this was asked already but.

Would this if further developed simply allow a company say, like Microsoft to prevent people who are not using Windows to visit websites? If put on servers that would be trouble for many Linux users. Microsoft could just try to shrug it off saying that its not a "trusted" operating system. Anyone using say, frontpage or Windows Server could effectively just by using those products prevent "those dirty Open Source infidels" from viewing big websites. ...just a thought.

Nice idea but...

The passive operating system fingerprints are going to prove to be useless in preventing abuse. It boils down to this -- you can't trust any information gained exclusively from the user (even passively).

Writing software to spoof OS characteristics won't prove to be a challenge, esp. when you know what characteristics the other side is trying to detect. I just can't really see this system as bringing any added value at all.

A more interesting twist

Would be to implement invisible port knocking, that is one where there is no preceeding magic packet that would hint the attacker about the presence of port knocker.

You can encode plenty of bits of data into the initial sequence number, TTL, window size, timestamp options and so forth (you can probably stuff a TCP packet with up to 128 bits of data with no effort).

The port knocking daemon could then only allow connections for which this 128 footprint matches the one-time cryptographically generated password, silently dropping all other traffic.

OpenBSD

OS detection combined with firewall rules is already implemented [openbsd.org] in OpenBSD.

Why is port knocking a good idea?

I mean it seems cute and all, but what does it buy you that, for example, sending a UDP packet with an access code in it (perhaps specific to the time of day and other parameters) doesn't get you?

leet Windows users

This makes it possible to allow, say, only Linux systems to connect to your SSH daemon.

You mean you could block all the leet blackhat Windows users from your box? You could really be in trouble if they were able to reach it...

port knocking sounds .. dirty

Hey baby, you ever had your port knocked by a black hat?

Naming Schemes ...

How long before someone comes up with a port knocker called "Cypher Operated Combination Key Knocker"?

And wasn't he played by Mark Hamill?

OTP, not OTP

Also, at the Black Hat Briefings, David Worth has released a cryptographic port knock implementation based around one-time pads.

The summary is incorrect: David Worth's tool uses one-time passwords, not one-time pads. That's a good thing, because one-time pads would make the system really inconvenient to use.

Order and Delivery of Packets not guaranteed!

...as I say every time this comes up. The more complicated the knock sequence, the less reliable it will be.

I like the cryptographic approach.

I personally would prefer a PGP public key encrypted token with the token being what ever is in the one time pad.

Here are some methods from an earlier discussion, mine and some others.

http://slashdot.org/comments.pl?sid=104064&cid=8 86 4815

AuthPF

Yes, its not on topic..

But for the BSD users out there, PF has support for a thing called 'AuthPF' which allows people access to specific ports with IPSEC.
So you can drop all packets from whatever port/s unless the client authenicates first, which can also be used in conjunction with fingerprints/Altq etc etc. This is more secure then just port knocking+Fingerprints and can also be used for a more secure way to authenticate your WIFI AP's then 802.11* WAP.

Re:So how long....

Install portsentry. Wait until corporate Nazi scanned your machine and got added to hosts.deny. Enjoy the freedom.