Weekly Edition
Return to the Press page
| |||||||||||||
Single Packet Authorization (Linux Journal)
Linux Journal looks
at how Single Packet Authorization fills the gaps in port knocking.
"Vulnerabilities have been discovered in all sorts of security
software from firewalls to implementations of the Secure Shell (SSH)
Protocol. For example, OpenSSH is developed by some of the most
security-conscious developers in the world, and yet it occasionally
contains a remotely exploitable vulnerability. This is an important fact to
note because it seems to indicate that security is hard to achieve and,
therefore, bolsters the case for a defense-in-depth approach. This article
explores the concept of Single Packet Authorization (SPA) as a
next-generation passive authentication technology beyond port
knocking."
(Log in to post comments)
Bad Security Posted Mar 5, 2007 23:26 UTC (Mon) by ldo (subscriber, #40946) [Link] The article illustrates exactly what happens when you toss together a "solution" (port knocking) without a proper analysis of what exactly is the security problem you are trying to solve. Then, when you discover shortcomings in the technique--like vulnerability to something as elementary as a replay attack--you try to patch it up by throwing even more complexity at it, in the hope that you will end up with something that actually works. Fat chance.
Bad Security Posted Mar 5, 2007 23:49 UTC (Mon) by flewellyn (subscriber, #5047) [Link] I partly agree.
Port-knocking itself isn't something I'd heard of before, but as soon as I read the description, I knew it would not work. Even before I read the list of shortcomings in the article, my first thought was, "Umm, what's to be done about replay attacks?" The issues of bandwidth, out-of-order delivery and denial-of-service, which I didn't think of before reading that part, killed the idea for me. Plus, the whole idea of using the port fields for something other than what they are intended -- port numbers -- seems altogether wrong.
SPA, on the other hand, seems like a much better idea. It doesn't use port numbers in a bad and wrong way, it has decent bandwidth, it's designed to circumvent replay issues, and doesn't have the denial-of-service problem. It could be a useful additional layer of security, and I don't see it having any huge problems in theory.
In practice, of course, the SPA server is something programmers need to get right: bugs in the SPA server could either kill network traffic altogether ("block everything!"), or make the SPA layer useless ("block nothing!"). And I think the article should take pains to remind people that this is not a replacement for securing the actual application programs, either; I would be very nervous about someone setting up an SPA server, and then thinking that this made host-level and service-level security unnecessary.
Bad Security Posted Mar 6, 2007 0:24 UTC (Tue) by dark (subscriber, #8483) [Link] You forgot option 3: bugs in the SPA server could allow execution ofarbitrary code.
From what I can see, it just adds more possibly-vulnerable code to an
Bad Security Posted Mar 6, 2007 1:11 UTC (Tue) by flewellyn (subscriber, #5047) [Link] Good point, although that can be mitigated by setting up SELinux to control the SPA server's access to system resources.
I do see your point about it being a proliferation of more potentially-vulnerable code. As for its utility...well, it would have the benefit of providing a level of access control beyond the service level, blocking access to a host until the client authenticates, and then allowing connections to provided services. It provides defense in depth of the host.
We can do host-based blocking through the tcp_wrappers suite, but there isn't a way to authenticate a host dynamically: a host in hosts.deny is blocked until the administrator manually removes it (moving it to hosts.allow, depending on setup). Plus, tcp_wrappers works at the application level, not the packet filter level. So tcp_wrappers doesn't (as far as I can tell) prevent a DoS attack.
I could be wrong, of course, but it looks like SPA might provide some useful security. I think the tech is too new to be evaluated properly, though. It definitely needs more testing.
Bad Security Posted Mar 6, 2007 6:42 UTC (Tue) by job (guest, #670) [Link] The same (that risks can be mitigated by SELinux) could be said about OpenSSH.
Bad Security Posted Mar 6, 2007 8:38 UTC (Tue) by drag (subscriber, #31333) [Link] Ya pretty much.
Personally I like the idea that less software is, on average, is going to more secure then more software. As long as everything is designed for security, that is.
Bad Security Posted Mar 6, 2007 15:07 UTC (Tue) by bronson (subscriber, #4806) [Link] Well, it would be foolish to run a dictionary attack against udp:62201. There are a number of security articles demonstrating surprising success when doing the same thing against tcp:22.
In theory, practice and theory are the same. In practice, they're different. Personally, I use port knocking as a last-ditch measure if high-traffic OpenVPN goes down. It sure beats driving 300 miles to the data center.
There's little chance of a replay attack since I'll just change the knock sequence in the rare event that I actually need to knock in. Out-of-order packets just aren't a problem in practice. Port knocking makes my life easier and my /var/log/auth.logs much smaller. Don't be so quick to dismiss it because of theoretical flaws.
Bad Security Posted Mar 6, 2007 17:06 UTC (Tue) by allesfresser (subscriber, #216) [Link] Are the articles demonstrating success using a dictionary attack against SSH when it's configured for password access, or with private-key only? One would think (though intuition can be notoriously unreliable in these sorts of things) that configuring the SSH server to only allow private-key authorization would reduce the change of dictionary success considerably. Does this sound reasonable?
Bad Security Posted Mar 6, 2007 18:53 UTC (Tue) by bronson (subscriber, #4806) [Link] Requiring private keys does ensure a dictionary attack could not succeed. Perhaps why it doesn't see more widespread use:- it is notoriously difficult to set up right. Admins tend to half-ass it (lack of time or understanding) and end up producing the equivalent of a shared-root setup. - it requires more maintenance. On busy sites (think sourceforge), just the day-to-day key management would require at least one full time employee. - it doesn't stop /var/log/auth.log from growing by 4MB/day.
Don't get me wrong: I run all my sshds with mandatory private keys for this very reason. And I also use port knocking! Use the right tool for the job.
Bad Security Posted Mar 6, 2007 20:04 UTC (Tue) by allesfresser (subscriber, #216) [Link] I find it interesting (and slightly disturbing) that setting up a private-key-only sshd is considered difficult. I find it disturbing because in that case I may have done it incorrectly myself! :) From my understanding all that is necessary is to enable only the PubkeyAuthentication method in sshd_config, place the applicable public keys in the user accounts' ~/.ssh/authorized_keys files, and restart sshd. Is there more to it that I'm missing?
Bad Security Posted Mar 6, 2007 21:05 UTC (Tue) by gravious (subscriber, #7662) [Link] Er, that's what I do - if there is a step or two (or more heaven forbid) we are missing out, please enlighten us Oh LWN Gurus of Security :)
Bad Security Posted Mar 6, 2007 22:35 UTC (Tue) by bronson (subscriber, #4806) [Link] It's the key management that makes it difficult. If you and a friend are administering four boxes, it's trivial. If 25 admins are responsible for 400 boxes, it gets painful quick. At one place where I consulted, one admin got sick of swapping keys in and out and just set up a single shared key (what I meant by "shared root setup"). Most admins know why it's bad to share a root password but apparently at least one didn't see a problem with sharing a root key. (weird, I know!)
Another problem is that when people set this up, some see it as an opportunity to use a single private key with no password. That's both easier than setting up ssh-agent and more secure, right? Well, if you lose the key (say, a stolen laptop), you've given up the entire farm. Now you need to try to find all copies of the compromised key and update it to your new key. On more than 5 machines that becomes really tedious.
Maybe I just run into stupid/lazy admins a lot more than the average person. :)
Bad Security Posted Mar 7, 2007 2:41 UTC (Wed) by ArbitraryConstant (guest, #42725) [Link] -Let's face it, it doesn't take much to halt most dictionary attacks, and I don't think setting up port knocking well is any easier than requiring a private key. Yeah, you're screwed if you don't bother putting some basic measures in place to stop dictionary attacks, but the answer is not to pick an unhelpful method and add complexity to your setup, the answer is to take the daemon you have to run anyway and do it right.
-A port knocking solution that doesn't require maintenance is no more worthwhile than a bad SSH solution. It might be guessable, it'll be vulnerable to replay attacks, a fired employee can get to it, etc. Once you stop the script kiddies and botnets that scan the Internet, you're left with more determined attacks, and it's worthless against those. A good port knocking solution needs a pseudo-random and ever-changing sequence, or UDP packets filled with large, single-use keys, etc. It'll need maintenance just like SSH private keys. In that case, why not just use SSH with private keys?
-I can't be the only one that compresses my logs. The dictionary attacks still spatter against a windshield, they just spatter against a slightly different windshield. I, for one, am not opposed to having a record of who's doing it.
Bad Security Posted Mar 6, 2007 1:16 UTC (Tue) by Sutoka (guest, #43890) [Link] I think the 'problem' port knocking was designed to help solve were zeroday vulnerabilities and lists of servers with what version of certain applications they are running.
As far as I know, most people aren't in positions to perform replay
Sure, there are holes and problems (primarily if you go with multiple
Well, there are different kinds of security Posted Mar 6, 2007 10:05 UTC (Tue) by dion (subscriber, #2764) [Link] ssh is what provides the real security, I don't think anyone wants to replace ssh with telnet and port knocking.
As far as I can tell the two arguments for port knocking are:
1) It's very likely that casual attackers (99.99% or more) cannot sniff your traffic, so it's still worth while to shut those down.
2) Port knocking can be implemented using very simple code that can be audited completely (a perl script reading the firewall log) and thus you can be sure that there are no dangerous holes in the implementation.
Moving actual crypto and package parsing into the solution (SPA) is a mistake IMHO, as that's simply moving too much complexity to trust.
If history has shown anything then it's that real security is hard (see ssh) and as a consequence of that people some times make mistakes, port knocking is a dead simple way of dramatically decreasing the chance that some script kiddie hits your server before you get around to patching it.
Good Security Posted Apr 15, 2007 1:26 UTC (Sun) by mrash (guest, #44663) [Link] So, can you suggest an attack vector against SPA? SPA is relatively simplistic (especially when only the symmtric Rijndael algorithm is used for encryption), depends on libpcap (which gets a lot of scrutiny), and fwknop is written in a buffer-safe language (perl).
The security benefit is that there is nothing a remote adversary can reasonably do to tell that fwknop is running, and arbitrary servers can be protected behind it using a kernel-level filtering mechanism (iptables) to fundamentally limit the number of user-space functions that an attacker would otherwise have access to.
agree Posted Mar 6, 2007 1:03 UTC (Tue) by ArbitraryConstant (guest, #42725) [Link] I share the skepticism of others here. Port knocking isn't a security solution, it's for when your ISP will get angry with you if you have servers listening for connections. It's still trivial for traffic analysis to figure out what you're up to, so I'm not convinced of the value even then; if port knocking will fool them, so will listening on 1024+. When it's a matter of security and a proper VPN isn't an option for whatever reason, I use AuthPF, and I'm sure something similar is available through Linux. It uses SSH for authentication and keepalives. The post argues that even SSH is sometimes vulnerable, but as others have mentioned, everything is sometimes vulnerable. A port knocking implementation won't be any less so. At least with SSH, patches are needed only infrequently, and they're usually available quickly when needed. The problem with this is that it is the most secure port knocking implementation you're ever likely to get, but the connections you make past the firewall are still subject to the risks associated with going over the Internet in the clear, and if you're NATing or someone can spoof your IP, you're still vulnerable. There's only one solution that's actually resistant to a determined attack, and that's cryptographically secure authentication and communication. SSH tunnels and VPNs are the answer for this, not port knocking. I simply don't see the benefit. Whatever permutation you're looking at, there's either an easier way or a more secure way, depending on your priorities.
agree Posted Mar 6, 2007 8:41 UTC (Tue) by niner (subscriber, #26151) [Link] Port knocking has just one advantage over plain ssh: it keeps your logs free of thousands of failed login attempts due to brute force ssh guessing by automated scripts.It's not security, just a little more convenience.
It's the same as with simple text-based CAPTCHAs like addition of two numbers. They are very easily broken and scripted even by the youngest script kiddie. But this assumes, that there is a human individual interested in your site. And in most cases there just isn't.
agree Posted Mar 6, 2007 14:30 UTC (Tue) by drag (subscriber, #31333) [Link] If you want to avoid script kiddies then stick have your ssh session run on port 23 instead of port 22 (or whatever port you want). At least that way you avoid the massive amount of traffic that automated scanners generate.
That's pretty much all you have to do to have fairly clean and relevent logs.
agree Posted Mar 6, 2007 15:27 UTC (Tue) by bronson (subscriber, #4806) [Link] nmap will find sshd on port 23 without even breaking a sweat. It will also eventually discover it on port 31337, even if you aggressively block portscanning. But it will never find your knock sequence.
I agree that moving sshd's listening port currently deters many script kiddies. But it's like greylisting: it's utterly trivial to get around. Once a lot of people put sshd on different ports, the kiddies will just learn how to use nmap.
agree Posted Mar 6, 2007 18:17 UTC (Tue) by ofeeley (guest, #36105) [Link] And capturing a list of hostile machine's IP addresses and adding them to /etc/hosts.deny is nice. As long as you're using ssh keys the script kiddie attacks are just providing a handy list of IP's to treat as hostile with very little actual risk.
Not sure I agree Posted Mar 6, 2007 23:09 UTC (Tue) by bronson (subscriber, #4806) [Link] There's a fine line between banning hostile IPs and DOSing yourself. :)
A lot (most?) of the traffic will be arriving on dynamic or shared IP addresses. Just because one packet was hostile, that doesn't mean that all traffic from that address will be hostile. Imagine visiting your parents and not being able to log to your production server just because some script kiddie managed to get most of AOL's proxy IPs on your block list.
Also, I'm not sure that keeping a list of IPs actually buys you much. Most of the script kiddies responsible for this noise won't bother trying any other attack against you. And a determined attacker would never try something as noisy as a dictionary attack. Presumably he would already know that you're using pubkey authentication and a dictionary attack would be futile anyway.
So... Keeping a list of mostly harmless script kiddie IPs doesn't strike me as a very worthwhile endeavor...?
agree Posted Mar 6, 2007 19:31 UTC (Tue) by ArbitraryConstant (guest, #42725) [Link] meh
Just rate-limit SSH connections. You can even simply block IPs that have more than a certain number of failed login attempts in a given period of time.
Single Packet Authorization (Linux Journal) Posted Mar 6, 2007 2:34 UTC (Tue) by tialaramex (subscriber, #21167) [Link] The main thing people seem to be looking for is a way to disadvantage bulk scanners. But that already exists, as a production system, in the form of IPv6. Bulk scanning IPv6 networks is not practical because of the much larger address space, so you can hide the entire machine, rather than just a service port, by simply neglecting to publicise its existence. With your SSH server using just one or two addresses in a LAN that has many billions of possible addresses, script kiddies simply can't find you. Once they start losing all the time, "find the SSH server" stops being a fun game and most script kiddies won't even bother trying any more.
Modern DNS servers no longer offer transfers to unknown third parties, so if you don't tell anyone that "panda.toys.example.com" is your IPv6 SSH server, there's no practical way for them to find out that it even exists, let alone that it's vulnerable to a brand new SSH vulnerability.
Of course this doesn't protect you against a sophisticated criminal, who might be shoulder-surfing your SSH server address at the same time he snoops on your passphrase and pickpockets your SecureID keyring. Resourceful attackers remain a significant threat, but eliminating the chaff we all deal with every day from script kiddies would even help to make the serious stuff more visible. If your IDS flagged one intrusion attempt per month you'd investigate, but on today's crowded IPv4 networks the IDS may be logging a hundred potentially serious incidents per hour, 24/7, until you switch it off altogether
Single Packet Authorization (Linux Journal) Posted Mar 6, 2007 15:32 UTC (Tue) by bronson (subscriber, #4806) [Link] "you can hide the entire machine, rather than just a service port, by simply neglecting to publicise its existence."
Once that machine emits a single packet (of ANY type), its cover is blown. That doesn't sound like very effective security to me.
Single Packet Authorization (Linux Journal) Posted Mar 7, 2007 9:32 UTC (Wed) by tialaramex (subscriber, #21167) [Link] Earlier in these same comments you seemed to understand that there are two major categories of attacker.
Script kiddies can't search 2^128 addresses, or even the much smaller but still vast IPv6 range actually allocated and in service, nor can a worm. On the whole the script kiddies aren't very smart, but if they persist in scanning anyway they're just wasting their time and a little bit of everyone's bandwidth until they learn better. Script kiddies don't have access to your traffic logs, or an optical splitter in your ISPs fibre, so they can't tell when your machine "emits a single packet". So IPv6 makes Internet scale scanning go away. That means no false alarms, packets arriving at your machines were directed at you, not just sent to randomly generated IP addresses.
Sophisticated attackers probably aren't interested in you. If they are, the thing keeping you safe is SSH itself, and if you have a vulnerability then they doubtless know about it and will be inside your network before you even read the security advisory. Port knocking is, if anything, adding to the cracks in the wall.
I find it odd that you seem to claim maintaining complicated "knocking" rituals for every server is less effort than managing SSH public key crypto. If you really meant that you don't have any security at all inside your network and rely on port knocking to protect a /gateway/ machine, then might I suggest that you manage SSH public key crypto just for that machine (and get some more security)?
Single Packet Authorization (Linux Journal) Posted Mar 7, 2007 16:31 UTC (Wed) by bronson (subscriber, #4806) [Link] A few thoughts...
If you're saying that hiding a machine deep in IPv6 space is poor security, just like port knocking is poor security, then we are in agreement. :)
I use the same knock sequence on every server. Port knocking is bad security, why pretend otherwise? But, here's the thing: even a simple, static 3-port sequence significantly raises the bar to touching the good security. With port knocking, when I see multiple failed login attempts in my logs, I know that something is wrong and I'll bring the heavy immediately.
Port knocking is not about adding more security. It's about eliminating the noise that would otherwise hide a determined attacker.
As I said before, I do have pubkey login on every ssh machine I maintain. We pubkey users seem to be a tiny minority, unfortunately. I was just explaining why I think that many admins either don't do it or, if they try, do it badly. It's takes forethought to securely scale up to many admins on many machines. It isn't plug-and-chug.
Because port knocking can be done entirely with iptables rules, it doesn't need to add appreciably to your threat surface. It just adds the 'recent' module, which seems to be a well written module. SPA, with its dedicated listening daemon, adds significantly to your threat surface. A quick google search finds this article, which appears to be good but isn't the one I followed: http://www.soloport.com/iptables.html .
Here's a much more thorough treatement that I just found: http://web.mac.com/s.j/iWeb/Security/Port%20Knocking%20an... I haven't read the whole thing yet but, reading the conclusion, I think Sebastien Jeanquier is spot on.
Does that make my position a little more clear?
Single Packet Authorization (Linux Journal) Posted Mar 7, 2007 18:28 UTC (Wed) by tialaramex (subscriber, #21167) [Link] Yes, your position is more clear, I think we're pretty much on the same wavelength about what the problems are and the extent to which different techniques are appropriate, it's just that I don't agree with your choice of solution (although I agree it's working for you). I prefer elegant solutions, and I see sparse addresses as elegant while secret handshakes are not. I haven't any data as to which is more effective in practice.
Adding "more" iptables rules would constitute a non-negligible increase in attack surface for me because I don't currently use, or intend to use, iptables. Of course you could argue that using IPv6 at all, even during the lengthy (perhaps a decade or more still) transition period also increases the attack surface, but if you view IPv6 as inevitable then finding any security problems in it now seems like a good up-front investment.
My original purpose in mentioning this was to justify why I think scanning is mostly a transitory problem not worthy of creating specialised protocols and tools like the one in the article.
Single Packet Authorization (Linux Journal) Posted Mar 6, 2007 7:54 UTC (Tue) by amando (guest, #36597) [Link] This looks very much like doormanhttp://doorman.sourceforge.net/
Single Packet Authorization (Linux Journal) Posted Apr 14, 2007 17:47 UTC (Sat) by mrash (guest, #44663) [Link] doorman uses a hashed payload (instead of an encrypted one as used by fwknop), and this results in a significantly different architecture.
Single Packet Authorization (Linux Journal) Posted Mar 6, 2007 13:18 UTC (Tue) by RobSeace (subscriber, #4435) [Link] The one advantage simple port-knocking has over more complex/secure stuff such as this is that you don't need a specialized knocker client... If I knew I'd never need to access my system from any arbitrary system, I'd simply lock it down to prevent access from anywhere except the known places I expect to be connecting from... But, the whole point of something like port-knocking is that you potentially can be connecting from anywhere, so you have to prove up front that it's really you before you'll even be given a chance to try to connect... Now, with simple port-knocking, you can just do the knocks with anything, including plain old telnet... Which means you can do them literally from any machine you might find yourself on, with no need for carrying around special software with you (compiled for every OS/architecture on the planet that you might run into?)... That's a huge advantage, IMHO... Sure, this scheme sounds a lot more secure and cool and all, but a lot less convenient... As someone else said, the real security should come from your sshd (or whatever server you're protecting behind the knock server); just think of the port-knocking as another layer of obfuscation on top of it, with the main goal of hiding it from casual observers, not from stopping any and all possible determined attacks... That is plenty for some (dare I say most?) people's needs...
Single Packet Authorization (Linux Journal) Posted Mar 11, 2007 21:32 UTC (Sun) by ekj (guest, #1524) [Link] I'm extremely skeptical of any "security"-product designed by people who sprout useless crap like: For instance, the raw ElGamal algorithm used by GnuPG doubles the plain-text size when encrypting data. Even though GnuPG also utilizes compression (which can sometimes reduce the size of the cipher text to below the original size of the plain text), the typically large key size of GnuPG keys implies that the cipher text for even the smallest messages will be in the hundreds of bytes.Stupidity ^ 3. First, all major encryption-algorithms are 1:1 in size plaintext-ciphertext, it doesn't matter if you encrypt using AES, triple-Des, Twofish or Blowfish, in all cases the ciphertext is going to be exactly as large as the plaintext. Thus, the entire rationale, that "ciphertext is large" is plain and simple bullshit. Secondly, port-knocking ain't really designed to guard against an attacker that has full access to your network-traffic and can scan and replay at will. It's designed to make automated scanning and zero-day automated exploits just that little bit more difficult. A 5-port knocking-sequence has 80 bits of entropy, the odds that a random scanner gets it rigth are 1:2^80, which is adequate for repelling most automated attacks. Third, moving crypto into this layer actively *hurts* security. The point is to have a guardian that is so simple that you can feel completely confident that the guardian itself has no bugs. The moment you have a crypto-application listening on udp:6112 (or whatever) for a magical packet, you're not much better off than just letting sshd do the same job on a tcp-port. The *sole* remaining possibly useful idea is the idea: "Don't let an attacker know that you're even listening until he has successfully convinced you he is a friend".
Single Packet Authorization (Linux Journal) Posted Apr 14, 2007 17:04 UTC (Sat) by mrash (guest, #44663) [Link] All of the encryption algorithms you mention as 1:1 plaintext-ciphertext ratio are _symmetric_ ciphers. ElGamal is not a symmetric cipher. While I don't know what the exact ratio is (and I suspect there will be differences depending on the size of the plaintext - especially if the plaintext size is very small), try encrypting a single byte of data with an ElGamal cipher and take a look a how large the ciphertext is. It is not 1 byte.
Your statement about the fact that "port knocking is not designed to guard against an attacker that has full access to your network-traffic and can scan and replay at will" is true because port knocking has such serious limitations. SPA is designed to offer protection from just such an attacker. The fwknop (http://www.cipherdyne.org/fwknop) implementation is written in a buffer safe language (perl) using standard encryption algorithms. While I agree that no software is 100% secure (ever), that is not the point. I'm trying to make the "prove you are a friend before granting access through the firewall" stance as strong as possible.
|
|||||||||||||