 nwrickertsand groperPremium,MVM
join:2004-09-04
Geneva, IL
kudos:7
 ·AT&T U-Verse
| reply to Daniel
Re: Is Portknocking "Real" Security? The fact that you're comparing portknocking with a line of uni-directional, non-mobile gun turrets (while the enemy has airborne troops) is illustrative of the fact that I've been wasting my time. But just for the sake of argument I'll show you why that's a horrible analogy. But that's exactly what you are doing. You are aiming your "guns" at direct attacks from the network, when the major risk is from clever use of social engineering techniques.
--
AT&T dsl; Westell 2200 modem/router; SuSE 10.1; firefox 1.5.0.10 |
|
 DanielPremium,MVM
join:2000-06-26
San Francisco, CA | said by nwrickert:You are aiming your "guns" at direct attacks from the network, when the major risk is from clever use of social engineering techniques. If we're trying to address the problem of millions of people having access to your SSH daemon, the way to counter that is with a network-based control. And that's what we're discussing here -- the effectiveness of one such control.
To say that we shouldn't be trying to protect ourselves from threat A just because threat B also exists is utterly insane. The bottom line is that this technique significantly lowers overall risk to a company that requires their SSH daemon be available to employees regardless of source network.
If you don't see that by this point then I guess there's little more for me to say.
--
dmiessler.com -- grep understanding knowledge |
|
|
|
 EGeezerSummertimePremium
join:2002-08-04
Midwest
kudos:7
 ·Callcentric
| Based on what I've read here, it appears that portknocking can be a useful part of an SSH implementation. While there were several general non-technical analogies presented, none seemed to address the methods a hacker might use to discover and obtain the port knocking sequence in a public network.
I was hoping to see an answer to the scenario I referenced in my earlier post, but that appears not to be forthcoming. Perhaps there is no practical way.
One question, though - how would one build an IP table for the IP authorization if the clients are road warriors using DHCP? Seems that option would not be useful in that case.
--
03:14:07 UTC Tuesday, Jan. 19, 2038 - a date that will live in infamy... |
|
DanielPremium,MVM
join:2000-06-26
San Francisco, CA | said by EGeezer:Based on what I've read here, it appears that portknocking can be a useful part of an SSH implementation. While there were several general non-technical analogies presented, none seemed to address the methods a hacker might use to discover and obtain the port knocking sequence in a public network. I was hoping to see an answer to the scenario I referenced in my earlier post, but that appears not to be forthcoming. Perhaps there is no practical way. One question, though - how would one build an IP table for the IP authorization if the clients are road warriors using DHCP? Seems that option would not be useful in that case. Actually it does work for that. That's the whole point of the project -- to have it work for roaming, dynamic-source clients.
--
dmiessler.com -- grep understanding knowledge |
|
EGeezerSummertimePremium
join:2002-08-04
Midwest
kudos:7 Reviews:
·Callcentric
| Re: IP access rules and DHCP clients I'm sure I'm missing something - If the road warrior has a dynamically assigned IP, how would I build an access rule based on the client's IP? It could be anything depending on where and when the user connects.
--
03:14:07 UTC Tuesday, Jan. 19, 2038 - a date that will live in infamy... |
|
DanielPremium,MVM
join:2000-06-26
San Francisco, CA | That's the point of it: the user sends a cryptographic "knock" to the firewall that only it could have sent, at which point the firewall opens just the SSH port for just that one client (and just for a moment).
--
dmiessler.com -- grep understanding knowledge |
|
EGeezerSummertimePremium
join:2002-08-04
Midwest
kudos:7 Reviews:
·Callcentric
| I was trying to figure out Ghost's reply(»Re: Is Portknocking "Real" Security?)
... I was thinking more along the lines of a port being accessible by everyone whenever a single user entered the correct port sequence for access. Obviously I forgot that iptables can allow access to ports on a per IP address after a port knocking sequence. Hence, my previous questions do not apply. So it's possible to have thousands of users access a service remotely, but no indication to others that a remote service is listening on a certain port.
Based on that, I'm thinking that one would need a fixed client IP address to implement IP based rules. If the client is DHCP assigned, this IP rules layer wouldn't be in the picture. Hope that clarifies my curiosity.
--
03:14:07 UTC Tuesday, Jan. 19, 2038 - a date that will live in infamy... |
|
nwrickertsand groperPremium,MVM
join:2004-09-04
Geneva, IL
kudos:7 Reviews:
·AT&T U-Verse
| reply to Daniel
Re: Is Portknocking "Real" Security? If we're trying to address the problem of millions of people having access to your SSH daemon, the way to counter that is with a network-based control. Millions of people do have access to my SSH daemon. So far that hasn't been a problem.
--
AT&T dsl; Westell 2200 modem/router; SuSE 10.1; firefox 1.5.0.10 |
|
DanielPremium,MVM
join:2000-06-26
San Francisco, CA
3 edits | Millions of people do have access to my SSH daemon. So far that hasn't been a problem.
Indeed. My mistake.
--
dmiessler.com -- grep understanding knowledge |
|
nwrickertsand groperPremium,MVM
join:2004-09-04
Geneva, IL
kudos:7 Reviews:
·AT&T U-Verse
| reply to EGeezer
Based on what I've read here, it appears that portknocking can be a useful part of an SSH implementation. 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.
--
AT&T dsl; Westell 2200 modem/router; SuSE 10.1; firefox 1.5.0.10 |
|
EGeezerSummertimePremium
join:2002-08-04
Midwest
kudos:7 Reviews:
·Callcentric
| I'm not disputing that there are other ways to provide security. I'm just observing that knocking appears to provide a layer of security that would provide some protection. That's what I got from reading Daniel's article. I still don't see how the hacker in the scenario would proceed.
--
The society which scorns excellence in plumbing as a humble activity and tolerates shoddiness in philosophy because it is an exalted activity will have neither good plumbing nor good philosophy: neither its pipes or its theories will hold water.
|
|
DanielPremium,MVM
join:2000-06-26
San Francisco, CA
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 |
|
nwrickertsand groperPremium,MVM
join:2004-09-04
Geneva, IL
kudos:7 Reviews:
·AT&T U-Verse
| 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 |
|
DanielPremium,MVM
join:2000-06-26
San Francisco, CA | 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 |
|
TheWiseGuyDog And ButterflyPremium,MVM
join:2002-07-04
Yonkers, NY
kudos:1 Reviews:
 ·Optimum Online
| 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. |
|
nwrickertsand groperPremium,MVM
join:2004-09-04
Geneva, IL
kudos:7 Reviews:
·AT&T U-Verse
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 |
|
TheWiseGuyDog And ButterflyPremium,MVM
join:2002-07-04
Yonkers, NY
kudos:1 Reviews:
·Optimum Online
1 edit | 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. |
|
nwrickertsand groperPremium,MVM
join:2004-09-04
Geneva, IL
kudos:7 Reviews:
·AT&T U-Verse
| 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 |
|
TheWiseGuyDog And ButterflyPremium,MVM
join:2002-07-04
Yonkers, NY
kudos:1 Reviews:
·Optimum Online
| 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. |
|
DanielPremium,MVM
join:2000-06-26
San Francisco, CA
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 |
|
