Combining Port Knocking With OS Fingerprinting 154
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 (Score:5, Interesting)
LK
Re:It's kinda cool (Score:3, Insightful)
it seems like a fad, and of course the authors of such programs will defend its usefulness.
my opinion is that this technique is not new, and hackers have been using very similiar things for decades.
and since he mentioned defcon, oh boy has that hacking con gone down hill. Bugs are just not as easy to find now days so the bar has been raised for h4x0rs.
Re:It's kinda cool (Score:1, Interesting)
Re:It's kinda cool (Score:5, Insightful)
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 (Score:2)
The addition of a one-time pad to the port knock verification process is helpful.
Re:It's kinda cool (Score:2)
Nope. Port knocking is truely Security Through Obscurity in the worse way.
PK is an abuse of the TCP/IP protocol- by repeatedly sending data to a "closed" port which the remote is really listening to, you can send some data which a typical eavesdropper might ignore. But that only lasts until PK becomes common enough that network-sniffing tools get checkboxes added to record this new data stream.
Right combination of keystrokes, right
Re:It's kinda cool (Score:2)
Right combination of keystrokes, right combination of ports to knock, these sound very similar to me.
Except that anyone else on the net can't insert characters into the middle of your password while you type it.
If I know your ip address, and what host to knock on, I can send out forged "knocks" and you'll never be able to enter the right sequence.
Contrast this to a password, where
Re:It's kinda cool (Score:5, Insightful)
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 (Score:1)
This is only true for vulnerabilities in services which allow for or rely on attackers making new connections. many vunerabilities take other forms, and port-knocking is no protection against them. For example:
Re:It's kinda cool (Score:2)
Port knocking has one purpose - to hide services from casual or dedicated port scanners.
Anyone who does not know that the service is there because it is obscured by port knocking cannot attack it when a vulnerability is discovered.
As a result, your security is enhanced to some degree.
Re:It's kinda cool (Score:1)
Re:It's kinda cool (Score:1)
"Security Through Obscurity" Ain't What They Think It Is [bastille-linux.org]
Re:It's kinda cool (Score:2)
You're right. They've probably been using it for years already.
Re:It's kinda cool (Score:2)
Re:It's kinda cool (Score:5, Insightful)
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 (Score:3, Informative)
I am not aware of PK schemes that just open the port wide once you send in a magic passphrase, that would be dumb.
In this regard, PK is quite similar to any other access scheme; the access control is a bit coarse, but so are all protocol-specific NAT helpers in firewalls, and most folks do not complain.
Re:It's kinda cool (Score:5, Interesting)
Re:It's kinda cool (Score:3, Informative)
Most services don't though. You should be updating iptables not hosts.deny.
Re:It's kinda cool (Score:1)
Hos is psad different from portsentry? [cipherdyne.org]
They Will Never Know (Score:3, Insightful)
They will never know.
Unless... they see their logs.
Your ISP may not be able to directly open your ports but they have to receive, handle and send every single inbound and outbound IP packet of yours, each of them containing source and destination port numbers.
If they don't know the easi
Re:It's kinda cool (Score:2)
That benefit can be essentially obtained without portknocking.
The practical effect of PK is that you have an additional wrapper protocol that must be negotiated before your REAL TCP daemons will talk to someone. That outside wrapper could be implemented with TCP (hiding all your various services behind one port #), UDP (a single packet containing authent key which wakes up the daemon), or PK as we know it.
All
Re:It's kinda cool (Score:2)
Re:It's kinda cool (Score:2)
How much more is needed? (Score:2, Insightful)
Re:How much more is needed? (Score:5, Interesting)
The above is completely conjecture, but it sure does sound cool
-- vranash
Re:How much more is needed? (Score:4, Interesting)
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.
Re:How much more is needed? (Score:2, Insightful)
Re:How much more is needed? (Score:2, Insightful)
Re:How much more is needed? (Score:2, Funny)
It's so we can block out all those Linux machines, because we all know that's where the hackers are coming from
OS fingerprinting, whew! (Score:4, Funny)
yuk yuk yuk
Layers (Score:5, Interesting)
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....
Re:Layers (Score:1)
Personally I think the fingerprinting part is a bad idea, since I often don't know what kind of computer I'll need to connect from, or maybe I was booted into windows that day to have a sane sound recording enviornment.
Re:Layers (Score:2)
TCPWrapper is IP, thats layer 3.
Portknokcing is ports, thats layer 5.
Keys Only is encryption, thats Presentation, layer 6
Passive Fingprinting is the OS, layer 7.
so we have layers 3,5,6 and 7 of the OSI model covered. Now, for the other 3...
layer 1: Run a dedicated line? Not very practical.
layer 2: Filter on MAC address, not hard to spoof, but it would require knowning the MAC to spoof before hand.
layer 4: TCP... hmm, you got me. but 5 layers of security is pretty friggin good.
Re:Layers (Score:2)
As for the MAC address filtering, you can do that with Netfilter as well, but it wouldn't help much in a WAN setting since you are only going to see the MAC address of your next router hop.
The more complicated you make it, (Score:5, Insightful)
Re:The more complicated you make it, (Score:2, Insightful)
Now look at the complexity and functionality of SSH, and its share of security problems over the past years.
Then look at port knockers, their simplicity and minimal reliance on bloated libraries. Note they only use a single, simplistic - but cryptographically proven - authentication scheme based on things such as basic symmetric ciphers or one-way shortcut functions, with implementations that could hardly go wrong.
The whole point is, SSH and many other complex services have proven to be not reliable
In other news... (Score:5, Funny)
Re:In other news... (Score:1)
Breaking news (Week later): IIS loses 30% market share due to stupid move on the part of the developers!
MS may be monopolisitc, but they aren't exactly stupid.
Re:In other news... (Score:1)
From ActiveX to DHTML to
Re:In other news... (Score:1)
Re:In other news... (Score:2, Funny)
Port knocking and some added ingredients (Score:5, Interesting)
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.
Re:Port knocking and some added ingredients (Score:2)
Yeah, that's what the other guy mentioned did. He's got a one-time-pad implementation that looks pretty cool.
Re:Port knocking and some added ingredients (Score:2)
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.
The problem I see with OS fingerprinting is the assumption that certains OSes are running certain (vulnerable/potentionally trojaned) applications. I don't think you can safely make those assumptions.
Re:Port knocking and some added ingredients (Score:2, Informative)
While the method you mention is one way of fingerprinting, most modern tools use a more sophisticated approach. Here [insecure.org] is a fairly simple explanation of some of those methods if you're interested.
Port knocking, firewalls, DMZs,... (Score:4, Insightful)
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,... (Score:5, Interesting)
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,... (Score:5, Insightful)
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,... (Score:2)
In what way? What, specifically, is "corporate" about the internet. What has been added to it in say, oh, the past five years, that would make you think that?
Re:Port knocking, firewalls, DMZs,... (Score:1)
Thhe web has become a lot more corporate, in the same way television has (due to advertising). I'm fairly sure that initially, TV was just the programmes and nothing else, although I'm too young to be a primary source
Re:Port knocking, firewalls, DMZs,... (Score:2)
Well yeah. And those programs were sponsored by RCA, which sold the TVs needed to watch them.
Re:Port knocking, firewalls, DMZs,... (Score:2)
Re:Port knocking, firewalls, DMZs,... (Score:3, Insightful)
I have a private server I use for e-mail, irc, and as a convenient, central location to store files. I have no interest in making this server public--it's only on the Internet because to set up a dedicated line to it would be prohibitively expensive. I don't even want people to know the server is there, and if they do find out it's there, I want security to be as tight as possible. Port knocking, in a way, helps to me
Re:Port knocking, firewalls, DMZs,... (Score:5, Insightful)
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,
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.
Re:Port knocking, firewalls, DMZs,... (Score:2)
As the internet becomes more and more available to people, we begin to realize what complete a-holes people can be, thus the need for more and more security measures.
Re:Port knocking, firewalls, DMZs,... (Score:2)
Security Through Obscurity (Score:4, Insightful)
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 (Score:4, Insightful)
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 (Score:2, Insightful)
Re:Security Through Obscurity (Score:2)
I don't, and I don't think you appreciate it either. The OP said that if one could sniff the traffic going to your node on the net that port knocking was trivial to get around. All arguments of that aside, how does having an open UDP port listening for some traffic make things any better? A good UDP scan will turn up your listening daemon (which may be vulner
Re:Security Through Obscurity (Score:1)
But no, using encryption on the UDP daemon would be making it more compl
Re:Security Through Obscurity (Score:2)
One way to increase security would be using a range of UDP ports, encrypting a timestamp and perhaps serial number to prevent replay attacks.
Re:Security Through Obscurity (Score:4, Interesting)
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 (Score:1, Insightful)
Security through obscurity is valid in some case, when the obscurity is deep enough that guessing in the dark is time expensive and must be repeated for each intrusion, and simple enough for the user. For example a security based on hiding logic only needs 1 successfull attempt to be broken (guess the logic and the security is broken until changed, which is n
Re:Security Through Obscurity (Score:1)
Sounds interesting. Is there an implementation of this scheme already available?
Re:Security Through Obscurity (Score:4, Interesting)
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 (Score:5, Interesting)
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?
Re:Security Through Obscurity (Score:1)
How, exactly does it do that? my understanding of UDP is that there is no indication to the sending computer that anything happened on the receiving end. The reason you can portscan TCP is because of the handshake required to open a stream connection. There is no "expectation of meaningful communication" with UDP.
Seriously, read RFC 768 [faqs.org], which defines UDP. It's a quick read. There's no w
these ports are made for knockin' (Score:2, Funny)
one of these days these ports
are gonna walk all over you........
Daemon watching iptables (Score:2, Interesting)
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.
Re:Daemon watching iptables (Score:1)
NOT a one-time pad (Score:5, Informative)
That's good (Score:2)
Eh? (Score:2)
Re:Eh? (Score:2)
However security through obscurity is not the reason. Most security is to some extent reliant on obscurity (eg. you can bet there are security bugs in the browser you're using, but nobody knows about them yet). Every time you enter your password to login you're relying on obscu
Watching the logs.. (Score:3, Insightful)
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: Now you don't have to clutter the system with logs and a daemon that may run into trouble.
Re:Watching the logs.. (Score:1)
-encrypted sequences with the Rijndael algorithm
-timing delays (both min and max) between successive ports in a knock sequence
Now... I don't know if this was asked already but. (Score:2, Interesting)
Re:Now... I don't know if this was asked already b (Score:1)
I don't have the
Re:Now... I don't know if this was asked already b (Score:1)
Nice idea but... (Score:2)
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 (Score:1, Interesting)
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 passwo
Re:A more interesting twist (Score:2)
One of the packets could even identify the particular IP address of the computer from which the connection will be made.
Re:A more interesting twist (Score:1)
OpenBSD (Score:4, Informative)
Why is port knocking a good idea? (Score:2)
Re:Why is port knocking a good idea? (Score:3, Informative)
If you have a static sequence, then yes if someone is sniffing the traffic then yes you have s security through obscurity layer in protecting blanket access to your service (for sake of discussion let's say SSH).
But you still have your auth on the SSH service.
The idea bei
Re:Why is port knocking a good idea? (Score:1)
> UDP packet with an access code in it (perhaps specific to the time of day and other
> parameters) doesn't get you?
I'd think it depends on your confidence in the security of the UDP listener.
Granted, it would be a simple piece of code to audit, but you'd still need to
open up the UDP port in the firewall, and expose the "UDP listener" to potential exploits.
Whilst a method that monitors log files is more of a kludg
Re:Why is port knocking a good idea? (Score:2)
I may be missing something, but port knocking sequences is just a silly waste of time as far as I can see - kinda amateurish actually.
leet Windows users (Score:2)
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...
Re:leet Windows users (Score:2)
Re:leet Windows users (Score:2)
port knocking sounds .. dirty (Score:1)
Re:port knocking sounds .. dirty (Score:1)
Naming Schemes ... (Score:2)
And wasn't he played by Mark Hamill?
Re:Naming Schemes ... (Score:2)
And yes, it was Mark Hamill.
OTP, not OTP (Score:2)
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! (Score:2)
I like the cryptographic approach. (Score:2)
Here are some methods from an earlier discussion, mine and some others.
http://slashdot.org/comments.pl?sid=104064&cid=
Re:So how long.... (Score:3, Interesting)