  Daniel Premium,MVM join:2000-06-26 Pleasanton, CA clubs: 
| reply to Name Game Re: Is Portknocking "Real" Security?
said by Name Game :You did not add a security layer..you just look for one to protect a port I keep closed. I think you missed the point; we're talking about people who 1) have a need to run the daemon, and 2) require connections from a dynamic range of source addresses.
So how do you propose to allow only certain people to come to your gate (they still have to login), while presenting a completely firewalled appearance to the rest of the world?
If this isn't "real" security, what do you propose as an alternative? And don't mention anything involving SSH itself, because that's already being done. BEYOND SSH itself. -- dmiessler.com -- grep understanding knowledge |
|
  Name Game Premium join:2002-07-07 North Myrtle Beach, SC
| said by Daniel :said by Name Game :You did not add a security layer..you just look for one to protect a port I keep closed. I think you missed the point; we're talking about people who 1) have a need to run the daemon, and 2) require connections from a dynamic range of source addresses. So how do you propose to allow only certain people to come to your gate (they still have to login), while presenting a completely firewalled appearance to the rest of the world? If this isn't "real" security, what do you propose as an alternative? And don't mention anything involving SSH itself, because that's already being done. BEYOND SSH itself. The alternatives are not available for discussion in this forum. -- Gladiator Security Forum »www.gladiator-antivirus.com/ Missing Kids »www.missingkids.com/ |
|
  Daniel Premium,MVM join:2000-06-26 Pleasanton, CA clubs: 
1 edit | said by Name Game :said by Daniel :said by Name Game :You did not add a security layer..you just look for one to protect a port I keep closed. If this isn't "real" security, what do you propose as an alternative? And don't mention anything involving SSH itself, because that's already being done. BEYOND SSH itself. The alternatives are not available for discussion in this forum. Why? Are they too 133t? -- dmiessler.com -- grep understanding knowledge |
|
  Daniel Premium,MVM join:2000-06-26 Pleasanton, CA clubs:  1 edit | reply to Name Game .. |
|
  nwrickert sand groper Premium,MVM join:2004-09-04 Geneva, IL
·AT&T U-Verse
·AT&T Midwest
| reply to Daniel So how do you propose to allow only certain people to come to your gate (they still have to login), while presenting a completely firewalled appearance to the rest of the world? I think you have made the point very well. This is all about appearances, rather than about real 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: 
| said by nwrickert :So how do you propose to allow only certain people to come to your gate (they still have to login), while presenting a completely firewalled appearance to the rest of the world? I think you have made the point very well. This is all about appearances, rather than about real security. You misunderstand; I do think it offers real security. -- dmiessler.com -- grep understanding knowledge |
|
  nwrickert sand groper Premium,MVM join:2004-09-04 Geneva, IL
·AT&T U-Verse
·AT&T Midwest
| You misunderstand; I do think it offers real security. I do understand that you think it provides real security.
I am thinking about this in terms of the servers I manage. Suppose I set up portknocking for SSH.
Option 1: I publish the sequence of magic port knocks. There goes any added security down the drain.
Option 2: I build a client that knows the sequence of magic port knocks. That's tantamount to publishing, so see option 1.
Option 3: I have to manually weave my way through this maze every time I need to use SSH. There goes my security. I have made it too inconvenient to push security updates to each of the servers. So I don't update them. The security risk of this is greater than the imagined risk of a possible zero-day ssh exploit showing up. Also, I probably stop monitoring my servers from home, because I have made it too inconvenient to login to them. The loss of monitoring is another increased security risk. -- AT&T dsl; Westell 2200 modem/router; SuSE 10.1; firefox 1.5.0.10 |
|
  Name Game Premium join:2002-07-07 North Myrtle Beach, SC
| said by nwrickert :You misunderstand; I do think it offers real security. I do understand that you think it provides real security. I am thinking about this in terms of the servers I manage. Suppose I set up portknocking for SSH. Option 1: I publish the sequence of magic port knocks. There goes any added security down the drain. Option 2: I build a client that knows the sequence of magic port knocks. That's tantamount to publishing, so see option 1. Option 3: I have to manually weave my way through this maze every time I need to use SSH. There goes my security. I have made it too inconvenient to push security updates to each of the servers. So I don't update them. The security risk of this is greater than the imagined risk of a possible zero-day ssh exploit showing up. Also, I probably stop monitoring my servers from home, because I have made it too inconvenient to login to them. The loss of monitoring is another increased security risk. And that of course is part of the "KEY" Daniel can not understand..unattended access..additional third party apps installed insdie to make it all happen..and you trust the code to work as advertised...Then you force the rest of your security to allow it to happen. -- Gladiator Security Forum »www.gladiator-antivirus.com/ Missing Kids »www.missingkids.com/ |
|
  captain_clue_bit
@foebud.org
from: Daniel 
| reply to nwrickert WOW, you guys have the craziest views of reality.
said by nwrickert :Option 1: I publish the sequence of magic port knocks. There goes any added security down the drain. Right, because service scanners always read published info about a target. It's the nmap option of --check-for-published-portknocker-data
said by nwrickert :Option 2: I build a client that knows the sequence of magic port knocks. That's tantamount to publishing, so see option 1. Absolutely, because most scanners download specific client software for every host they scan. It's the --download-special-ssh-client-and-extract-portknocking-sequence flag to nmap.
said by nwrickert :Option 3: I have to manually weave my way through this maze every time I need to use SSH. There goes my security. I have made it too inconvenient to push security updates to each of the servers. So I don't update them. The security risk of this is greater than the imagined risk of a possible zero-day ssh exploit showing up. Also, I probably stop monitoring my servers from home, because I have made it too inconvenient to login to them. The loss of monitoring is another increased security risk. You think that's bad, have you seen the whole PKI authentication model?? They actually expect you to always have a file present on a system in order to log into others. Man, what a hassle. Those systems must not've been patched in years.
said by nwrickert :And that of course is part of the "KEY" Daniel can not understand..unattended access..additional third party apps installed insdie to make it all happen..and you trust the code to work as advertised...Then you force the rest of your security to allow it to happen. SSH on *any* system is third party. Since you haven't audited or written your operating system, you trust that *all* of your software works as advertised.
Face it gents, it's a real security layer. Every security layer can be defeated, it's just a matter of how hard it is or how long it takes. |
|
  Daniel Premium,MVM join:2000-06-26 Pleasanton, CA clubs: 
4 edits | reply to nwrickert said by nwrickert :You misunderstand; I do think it offers real security. Option 1: I publish the sequence of magic port knocks. There goes any added security down the drain. Option 2: I build a client that knows the sequence of magic port knocks. That's tantamount to publishing, so see option 1. You keep using this word "publish". I don't think it means what you think it means. Let's try a real-world attack scenario:
Case:
You have deployed a port-knocking technology so that your firewall is opened just for SSH (which users still have to authenticate to using keys or passwords) once they authenticate via port-knocking sequence. The software was installed by your IT team on the laptops of your engineers in the field (we'll say you have 100 such engineers/laptops. And your employees know, of course, that if their laptop were to be stolen, they would need to report it. The way they use the software is by simply invoking the SSH client, which is configured to knock before attempting, which yields you your login prompt as normal.
Now, somewhere in the Ukraine, an organized crime syndicate has procured, through their extensive network of young crackers, a brand-new OpenSSH exploit that yields a root shell to the attacker. It's time now to begin using the exploit. The first thing these people need is a set of targets. They may already have a few high-profile targets in mind, but the way they'll build a victim list is by scanning for SSH. My questions to you (nwcricket and Name Game) are these:
Questions
1. How do you think this small group of guys in charge of doing the SSH scans (maybe one or two guys) are going to somehow magically procure the cryptographic knock sequence that's on the laptops of your engineers?
2. Ok, now that you realize that it's virtually impossible for that to happen, realize that the attackers, when they scanned your company's network range, DIDN'T SEE YOUR SSH SERVER. There are only two lists that result from these scans: the first is people that ARE running SSH exposed on the Internet, and the second are the people NOT running SSH exposed on the Internet. Most of those people are not running it at all, but some are running it with tight ACLs, some are running it internally with no firewall rules passing into it, etc. Either way, ALL THOSE PEOPLE go on the list of those NOT running SSH. To an attacker, they're all the same because they can't be attacked.
3. Now, after all that...realize that even if the ultimate, highly unlikely scenario were to take place, i.e. a super-elite Ukranian female hottie spy were to have infiltrated your organization and seduced one of your engineers. She now has your portknocking software!
Oh no! Game over, right?
No. No game over. All they've done is make YOUR SSH daemon the same as everyone else's, i.e. they either still have to login (they don't have the password still), or use an exploit. Meanwhile, for all the other THOUSANDS of attackers scanning your systems on a constant basis, are simply out of luck. They have essentially 0% chance of every compromising your SSH server because to them it ISN'T THERE.
--
So I ask you, gentlemen, please explain to me how this isn't a security layer. -- dmiessler.com -- grep understanding knowledge |
|
  nwrickert sand groper Premium,MVM join:2004-09-04 Geneva, IL
·AT&T U-Verse
·AT&T Midwest
| 1. How do you think this small group of guys in charge of doing the SSH scans (maybe one or two guys) are going to somehow magically procure the cryptographic knock sequence that's on the laptops of your engineers? They already have a copy of the SSH client that does this, because they have trojanized one or more of those laptops and installed a keylogger. -- 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 | said by nwrickert :1. How do you think this small group of guys in charge of doing the SSH scans (maybe one or two guys) are going to somehow magically procure the cryptographic knock sequence that's on the laptops of your engineers? They already have a copy of the SSH client that does this, because they have trojanized one or more of those laptops and installed a keylogger. I see, so any security layer that can be defeated by having full root access via trojaned system fails to be called a security layer? I think you may be out of your element, my friend. Layers aren't layers because they can't be defeated.
Your argument says that police shouldn't wear bullet proof vests because someone was rumored to have an anti-tank weapon in town. And of course, if someone were to shoot the officer wearing the vest with an anti-tank weapon...well what good would the vest do?
You're saying the same thing about the port-knocking layer. The fact that it can be defeated by full root control of the system means nothing. It can also be defeated if the engineer becomes insane and starts posting the username, password, and knocking sequence hundreds of hacker IRC channels. This doesn't make it any less effective as a layer.
Why? Because none of those things are, in the grand scheme of things, likely to happen. Remember, the machine wouldn't just have to be trojaned; it would have to be trojaned by THAT specific group -- of which there are thousands.
Get real, dude. -- dmiessler.com -- grep understanding knowledge |
|
  nwrickert sand groper Premium,MVM join:2004-09-04 Geneva, IL
·AT&T U-Verse
·AT&T Midwest
| I see, so any security layer that can be defeated by having full root access via trojaned system fails to be called a security layer? I never said nor implied that.
Your argument says that police shouldn't wear bullet proof vests because someone was rumored to have an anti-tank weapon in town. I never said nor implied that either.
It's a known fact police find these vests hot, sweaty and cumbersome. Some of them choose to go without. And that is closer to the problem I was raising. When you add a layer (whether security or obscurity), you have to consider the possibility that people will set up ways of bypassing it, with the result that your security might actually be worse.
It can also be defeated if the engineer becomes insane and starts posting the username, password, and knocking sequence hundreds of hacker IRC channels. The risk of that may well be greater than the risk of the zero-day exploit that so concerns you. The risk that one of your users will have is laptop trojanized should be of far greater concern.
You are adding complexity in order to prevent a very unlikely problem, while you disregard the far more likely problem that some of your users will have their machines trojanized. -- 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 | When you add a layer (whether security or obscurity), you have to consider the possibility that people will set up ways of bypassing it, with the result that your security might actually be worse. With all due respect, you're not grasping the basics here. What you just said illustrates that you don't understand what a "layer" actually is. If you have 5 layers of protection, and you add an additional layer on top of it, how many do you have?
Right, 6. So what happens if the 6th layer gets compromised? Do you now have 4? No. You still have 5. You see, we haven't lowered our security anywhere, we've only raised it. So in the HIGHLY unlikely event that this one additional barrier were to be breached, we would be back at the previous layer, i.e. SSH authentication.
Oh, by the way, that's the layer your at now. -- dmiessler.com -- grep understanding knowledge |
|
  nwrickert sand groper Premium,MVM join:2004-09-04 Geneva, IL
·AT&T U-Verse
·AT&T Midwest
| If you have 5 layers of protection, and you add an additional layer on top of it, how many do you have? Well, okay. If you have to accuse those who disagree of being unable to count, then I'll take that as evidence that you don't have much in the way of good arguments.
The French added an extra layer of security, to ensure that they could not be invaded by Germany. That extra layer was known as the Maginot line. As history demonstrates, it isn't as simple as just counting layers. -- 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: 
| said by nwrickert :If you have 5 layers of protection, and you add an additional layer on top of it, how many do you have? Well, okay. If you have to accuse those who disagree of being unable to count, then I'll take that as evidence that you don't have much in the way of good arguments. I wasn't implying that you didn't know 5 + 1 = 6. I was implying that you didn't realize that removing the 1 doesn't equal less than 5, which is precisely what you've been arguing all along. -- dmiessler.com -- grep understanding knowledge |
|
  Daniel Premium,MVM join:2000-06-26 Pleasanton, CA clubs: 
2 edits | reply to nwrickert The French added an extra layer of security, to ensure that they could not be invaded by Germany. That extra layer was known as the Maginot line. As history demonstrates, it isn't as simple as just counting layers. 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.
A LAYER means you have real, strong security sitting behind it (like SSH authentication, for example). Stupidity, on the other hand, is when you don't have any real security and you spend your time implementing something that won't work, and/or can be bypassed very easily. Let's review:
1. Portknocking works great and CAN be implemented easily -- even so that it stands up to observational attacks via cryptography.
2. Worst case scenario is that your SSH daemon remains as strong as it is today.
--
Do the right thing and admit you were mistaken on this one. Seriously.
-- dmiessler.com -- grep understanding knowledge |
|
  nwrickert sand groper Premium,MVM join:2004-09-04 Geneva, IL
·AT&T U-Verse
·AT&T Midwest
| 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 |
|
  Daniel Premium,MVM join:2000-06-26 Pleasanton, CA clubs: 
| 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 |
|
  EGeezer Go Bobcats Premium join:2002-08-04 Country!
·Callcentric
·RoadRunner Cable
·AT&T CallVantage
| 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... |
|