Daniel
Premium,MVM
join:2000-06-26
Pleasanton, CA
clubs: 
| reply to Daniel
Re: Is Portknocking "Real" Security?
Ok, man, whatever...
I guess there's no convincing you of anything here despite how many disagree with you. If you want to think it's a waste of time, whiz-bang technology that adds complexity with no security benefit then so be it.
No hard feelings, man. Ultimately, in the grand scheme of things, it matters very little.
Cheers,
-Daniel
--
dmiessler.com -- grep understanding knowledge |
|
nwrickert
sand groper
Premium,MVM
join:2004-09-04
Geneva, IL
 ·AT&T U-Verse
 ·AT&T Midwest
| reply to Daniel
Industrial CISCO routers are not using IP tables either. And if the firewall were running on CISCO equipment at our work, there is no way our servers would be given access to the firewall logs on those routers.
I provided an example with the broadband routers. I didn't say that's the only example.
I used broadband routers as my example, because I had already commented on them earlier in an earlier post. What you wrote in response to that earlier post was wrong and insulting.
--
AT&T dsl; Westell 2200 modem/router; SuSE 10.1; firefox 1.5.0.10 |
|
Daniel
Premium,MVM
join:2000-06-26
Pleasanton, CA
clubs:
| reply to nwrickert
said by nwrickert  :However, most inexpensive broadband routers are not suitable. So this is mostly a geek technique, particularly for those enthralled by the gee-whiz nature of the methodology.
--
dmiessler.com -- grep understanding knowledge |
|
nwrickert
sand groper
Premium,MVM
join:2004-09-04
Geneva, IL | reply to Daniel
So if a security layer doesn't work on "inexpensive broadband routers" then it's essentially a toy technology? I never said that.
--
AT&T dsl; Westell 2200 modem/router; SuSE 10.1; firefox 1.5.0.10 |
|
Daniel
Premium,MVM
join:2000-06-26
Pleasanton, CA
clubs:
1 edit | reply to nwrickert
However, most inexpensive broadband routers are not suitable. So this is mostly a geek technique, particularly for those enthralled by the gee-whiz nature of the methodology.
Ah, now I see where you're coming from. So if a security layer doesn't work on "inexpensive broadband routers" then it's essentially a toy technology? I think this illustrates why you're completely disjointed from those who are in support of this technology as a layer: you're thinking of things from a home/SOHO standpoint, and we're coming at it from a corporate perspective.
No offense to you, but this has largely been an enterprise discussion all along, so busting out now with "this doesn't work on my Linksys" isn't really a strong argument.
At any rate, can we agree that for corporate situations (where they're not likely to be using broadband routers) this is a decent layer? If so then I'll definitely agree that it might be overkill for the average home setup. 
--
dmiessler.com -- grep understanding knowledge |
|
TheWiseGuy
Dog And Butterfly
Premium,MVM
join:2002-07-04
Yonkers, NY
| reply to nwrickert
Not really, again if the router can log packets via syslog to the server machine, all you need to do is forward the Port to the firewalled server. The server then opens or closes its own port.
--
Warning, If you post nonsense and use misinformation and are here to argue based on those methods, you will be put on ignore. |
|
nwrickert
sand groper
Premium,MVM
join:2004-09-04
Geneva, IL
·AT&T U-Verse
·AT&T Midwest
| reply to TheWiseGuy
Does this help? From the linked reference, "Any *NIX host running IPCHAINS/IPTABLES is suitable."
However, most inexpensive broadband routers are not suitable. So this is mostly a geek technique, particularly for those enthralled by the gee-whiz nature of the methodology.
--
AT&T dsl; Westell 2200 modem/router; SuSE 10.1; firefox 1.5.0.10 |
|
TheWiseGuy
Dog And Butterfly
Premium,MVM
join:2002-07-04
Yonkers, NY
1 edit | reply to nwrickert
Does this help?
»www.portknocking.org/view/about/requirements
Edit:
Assuming you want to run the server on a specific IP and do not need to dynamically select the IP, you should be able to forward the port (you would need to anyway) to the firewalled server and then read the logs as they come into that server. So I assume
whose rules can be dynamically modified.
is not absolutely needed for the router. I believe it needs to be able to log via syslog. |
|
Daniel
Premium,MVM
join:2000-06-26
Pleasanton, CA
clubs:
| reply to Daniel
Actually, it does work through intermediate firewalls, and the issue with one packet (SPA) or multiple packets (PK) is unimportant. Either way the service is unavailable to over 99.9% of the world, which is a 99.9% improvement over not using one of these technologies.
--
dmiessler.com -- grep understanding knowledge |
|
nwrickert
sand groper
Premium,MVM
join:2004-09-04
Geneva, IL
·AT&T U-Verse
·AT&T Midwest
1 edit | reply to Daniel
So, yeah...it's just one port, man. Does this change anything for you? According to the doc "encoded in the form of connection attempts to closed ports, in which the port sequence forms the encoding,". You can't have much of a port sequence with only one port. In other words, it isn't going to work too well when you are behind an external firewall/router.
So sure, you add a security layer of some sort. But I have to remove an existing security layer (the external firewall), to be able to use it. In that case, when you are behind a typical NAT box, it may be a net loss in security.
--
AT&T dsl; Westell 2200 modem/router; SuSE 10.1; firefox 1.5.0.10 |
|
swhx7
Premium
join:2006-07-23
Elbonia
 ·RoadRunner Cable
| reply to Daniel
My remarks above were mostly theoretical. After reading more I find the implementations are not that far along. There are problems with NAT, and with the respective roles of the app and the firewall and interactions between them. Still, I don't see any negatives. |
|
TheWiseGuy
Dog And Butterfly
Premium,MVM
join:2002-07-04
Yonkers, NY
| reply to nwrickert
said by nwrickert :But why port knocking? Couldn't you achieve the same thing with a udp listener that can open the firewall for a particular connection in response to an encrypted and digitally signed udp packet? It seems to me that this would be more effective and simpler to implement. Moreover, it would work behind a NAT router, where I would only have to forward that one udp port instead of all of the ports that would be needed for port knocking. That would be SPA or Single Packet Authorization.
(See the link I posted earlier)
Technically I would consider both a form of Port Knocking, since I believe the definition of port knocking used in the paper is valid and I expect there will be newer forms of Port Knocking that will add strength to port knocking as a security layer.
said by Sebastien Jeanquier :
"In broad terms, port knocking is a method for transmitting information across closed ports, with the aim of authenticating users before allowing them, and only them, to access a protected service.." Both SPA and the "Port Knocking Perl Prototype" seem to have strengths and weaknesses.
As examples
If you run SPA it can be attacked off line via a dictionary or Brute force attack.
With either method if you run a "listener" of some sort to check if the authorization should be granted you run the risk of the "listener" having a vulnerability. While the writer of the paper indicates that
said by Sebastien Jeanquier :
The knock daemon has the ability to read knocks out of the firewall log, or directly off of the wire using libpcap. Due to the way that this implementation deals directly with the bit-representation of the knocked ports, it would be quite difficult to compromise the daemon itself with maliciously crafted packets. See page 32 for his full discussion which is interesting.
IMO if you run the "Port Knocking Perl Prototype" you can in theory simply check the logs of the firewall and remove almost all of this risk.
I liked qrkx 's summary earlier, and agree with Daniel Port Knocking (including SPA) does add a layer of security, it is not the foolproof but no layer is foolproof. I also agree with you that "social engineering techniques" are the primary risk against a secured system/server but that does not make Port Knocking any less of a layer.
--
Warning, If you post nonsense and use misinformation and are here to argue based on those methods, you will be put on ignore. |
|
Daniel
Premium,MVM
join:2000-06-26
Pleasanton, CA
clubs: | reply to nwrickert
Fair enough, my bad. I got a bit rowdy.
So, yeah...it's just one port, man. Does this change anything for you?
--
dmiessler.com -- grep understanding knowledge |
|
nwrickert
sand groper
Premium,MVM
join:2004-09-04
Geneva, IL
·AT&T U-Verse
·AT&T Midwest
| reply to Daniel
said by Daniel :Holy God. You mean you've been arguing all this time against it and you don't even know how it works? Portknocking only opens ONE (1) port, e.g. 22 for SSH. If you could avoid these unwarranted insults, perhaps intelligent discussion might break out.
--
AT&T dsl; Westell 2200 modem/router; SuSE 10.1; firefox 1.5.0.10 |
|
Daniel
Premium,MVM
join:2000-06-26
Pleasanton, CA
clubs:
2 edits | reply to nwrickert
Moreover, it would work behind a NAT router, where I would only have to forward that one udp port instead of all of the ports that would be needed for port knocking.
Holy God. You mean you've been arguing all this time against it and you don't even know how it works?
Portknocking only opens ONE (1) port, e.g. 22 for SSH.
»www.portknocking.org/
One source address, one port, for a short amount of time. And what you're talking about is called SPA, and it was mentioned earlier in the thread. I agree that it's an interesting alternative to the portknocking implementation, but ultimately it's pretty much the same.
The firewall is closed, but when the trusted client sends a secret stimuli the firewall opens up JUST FOR THEM -- keeping the rest of the world locked out. This is the same for both portknocking and SPA.
But dude...do you see now?
--
dmiessler.com -- grep understanding knowledge |
|
quetwo
That VoIP Guy
Premium
join:2004-09-04
East Lansing, MI
| reply to Daniel
We use port-knocking in our office. We administrator hundreds of PBXs on campus and have the firewalls block ALL incoming traffic. Our techs can the "knock" on the firewall and then launch their PBX admin interface. After 5 minutes of inactivity, it blocks all traffic again. The nice thing is it blocks all traffic from ALL addresses except for the knocked-port. So, even if an interception of data between the tech and the PBX happens, the attacker can't do do anything unless they knock on the port (which is accomplished over an HTTPS page.) |
|
gkweb
join:2003-06-09
76800
| reply to Daniel
Hello,
I fully agree with Daniel about port knocking.
This debate reminds me of security software on Windows, should we add more layers or not. An antivirus, for instance, is not a 100% security as it can be bypassed, especially by someone targeting you in particular. Anyway, it is strongly advised to run an antivirus software.
Portknocking, as Daniel highlighted, is an additional layer, it does not replace your SSH's own security (e.g : login & password, RSA certificates). It cannot weaken the security of your listening daemon. Portknocking is filtering 99% of unauthorized access attempts.
In a real scenario, let's say that a new 0-day exploit has been discovered, the timeframe from the time where the exploit is discovered and used, to the time where a patch is issued, you are very unlikely to have received a single SYN packet to your SSH daemon, as any automated attack would not get past portknocking.
In the other scenario where someone is targeting your server, is knowing you are running a SSH server, portknocking at best will prevent him to connect to your SSH, or at worse will make him loose time getting past it
(in this case, I would like to know how to remotely "guess" a portknocking sequence).
Portknocking is an additional layer. That the additional security margin it provides is judged weak, or strong, it is still an additional security layer and I see no reason not to use it.
Regards,
gkweb.
--
Firewall tester : »www.firewallleaktester.com
*member of ASAP : Alliance of Security Analysis Professionals* |
|
swhx7
Premium
join:2006-07-23
Elbonia
·RoadRunner Cable
1 edit | reply to Daniel
Of course port knocking is a good security layer. I thought so as soon as I first read about it a few years ago, and nothing since has changed my mind.
The argument in the Reddit thread is weak: "I can't imagine why someone clever enough to discover a new implementation exploit for ssh would be slowed done for more than a few minutes by your silly little portknock trick. ssh already defeats script kiddies, so why bother implementing a technique that is only effective against low skill amateurs?"
Unfortunately this person does not explain how he would defeat portknocking. You could try brute-force or fuzzing, but this could be defeated by making the required "knock" longer or more complex. Maybe also the firewall can be configured to ban any IP that looks like it's trying such an approach. And to even try any attack, you would have to either be already targeting a particular host, or already know that a particular host was using portknocking.
Port knocking can move the "weakest link" from SSH to somewhere else. Maybe there is an insecure, internet-exposed box somewhere in the same network that could be leveraged to get "from LAN not WAN" access to the one where you are protecting SSH with pork knocking. This is hardly a criticism of port knocking. You just need good policies everywhere, e.g. disk encryption for remote employees.
said by Daniel :Actually, using cryptography, you can keep the knock secure even if it is captured. Even better, give each employee a different one, and in each session give a new one, encrypted, for their next session. Of course this requires a more elaborate implementation. |
|
Daniel
Premium,MVM
join:2000-06-26
Pleasanton, CA
clubs: | reply to Daniel
Actually, using cryptography, you can keep the knock secure even if it is captured.
--
dmiessler.com -- grep understanding knowledge |
|
Nerdtalker
Working Hard, Or Hardly Working?
Premium,MVM
join:2003-02-18
Tucson, AZ
clubs:
| reply to Daniel
I wholeheartedly agree with your assertions, Daniel . Adding additional levels of obfuscation in conjunction with methods that are already proven as being secure makes perfect sense.
If the objective here isn't to guarantee 100% forward security, but rather prevent people running netblock-size scans from stumbling across your SSH server, it makes sense. Often, these kind of hurdles simply turn-off attackers, and, assuming that you're not a very high priority target, it's unlikely that your exact knock will be captured.
However, in this circumstance, the additional layer becomes less and less secure as more and more people use it. The higher the likelihood that their traffic/handshake will be captured, and that someone will put 2 and 2 together.
It's funny, this concept is very reminiscent of the kind of creative data transfer like modulating the transmit times between mundane traffic to send information.
--
"Some people never see the light till it shines thru bullet holes." -Bruce Cockburn
I'm testing Gmail's spam filters: Broadbandreports1@gmail.com
Spam: 12900+ messages currently using 406 MB. |
|
