EGeezer
Go Bobcats
Premium
join:2002-08-04
Country!
 ·Callcentric
 ·RoadRunner Cable
·AT&T CallVantage
| reply to Daniel
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... |
|
Daniel
Premium,MVM
join:2000-06-26
Pleasanton, CA
clubs: 
| 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 |
|
EGeezer
Go Bobcats
Premium
join:2002-08-04
Country!
·Callcentric
·RoadRunner Cable
·AT&T CallVantage
| 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... |
|
Daniel
Premium,MVM
join:2000-06-26
Pleasanton, CA
clubs:
| reply to Daniel
Re: Is Portknocking "Real" Security?
Hmm, no. He was just saying that he thought the gate would stay open once someone entered through it, which would be bad. He was just acknowledging that he didn't know it was actually a per-use thing, for each source IP.
So, no, you don't create source-based ACLs with this. It's just the opposite; you create NO allow ACLs. Nobody gets through unless they send the proper crypto sequence.
--
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
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 |
|
Daniel
Premium,MVM
join:2000-06-26
Pleasanton, CA
clubs:
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 |
|
nwrickert
sand groper
Premium,MVM
join:2004-09-04
Geneva, IL
·AT&T U-Verse
·AT&T Midwest
| 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 |
|
EGeezer
Go Bobcats
Premium
join:2002-08-04
Country!
·Callcentric
·RoadRunner Cable
·AT&T CallVantage
| 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.
|
|
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. |
|
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 |
|
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. |
|
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* |
|
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.) |
|
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 |
|
nwrickert
sand groper
Premium,MVM
join:2004-09-04
Geneva, IL
·AT&T U-Verse
·AT&T Midwest
| 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: | 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 |
|
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. |
|
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. |
|
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 |
|
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 |
|
