Posted by
timothy
on Sun Aug 01, '04 02:50 AM from the belt-and-suspenders-and-tape-and-elastic dept. michaelrash writes "Port knocking implementations are on the rise. I have just released fwknop; (the Firewall Knock Operator) at DEF CON 12.
Fwknop implements both shared and encrypted knock sequences, but with a
twist; it combines knock sequences with passive operating system
fingerprints derived from p0f.
This makes it possible to allow, say, only Linux systems to connect to
your SSH daemon. Fwknop is based entirely around iptables log messages
and so does not require a separate packet capture library. Also, at the
Black Hat Briefings, David Worth has released a cryptographic port knock implementation based around one-time pads."
There is absolutely nothing wrong with using something a bit obscure to help fend off attacks.
The only time that "security through obscurity" is wrong is if that is your entire approach to security.
Even
if you have the latest and greatest copy of the most secure software
written to perform some service, there is always a possibility that
there is something exploitable that is yet unknown.
Port
knocking is an excellent way to greatly reduce the probability that
someone will be able to use a newly discovered exploit from using it
against your server before an update is available to fix the exploit.
Of
course, if someone is in the right place and can monitor the network
traffic from another computer somewhere along the path, they can
discover the port knocking sequence. For that reason, you still need
your normal security and you still need to keep the patches up to date.
But the result will still be a vastly improved possibility of avoiding an attack when a vulnerability is found.
The
primary purpose of port knocking is to hide the fact that you have open
ports to begin with. You don't want to have those ports unprotected
once the right knock sequence is in place. You want both
password/challenge AND port knocking so no active scanner detects your
open ports.
I use portsentry for protection against scans. The result is that all
my ISP scanners are now in hosts.deny and consequenlty I can run any
server I want and they will never know and can't complain about it...
With a large port knock routine say 20 ports or more, can't you be sure
it's YOUR box that's comming in? More defense and limitations are good,
sure, but why filter by OS? Is it in case someone gets by the knock?
Because the next step is to generate 'fake' OS fingerprints for the
client computer, thus insuring not only must someone reply with the
right sequence, but also send back the nuances of a specific OS to do
so... kinda like recieving a callback to which you must reply in the
proper accent before you'll be allowed in:)
The above is completely conjecture, but it sure does sound cool;p
Well, as another poster pointed out, if someone sniffs what ports
you're connecting to, then it would be simple to replay that knock.
That's the reason you need a security level underneath it, and
shouldn't rely on port knocking unless it's a changing sequence (like
the one-time pad idea also mentioned in the post).
I'm
not quite sure how the OS detection is supposed to help. Maybe you
could customize things for different OSes? As long as port knocking
schemes are implemented on two OSes, you could let the port knocker
determine which OS you're connecting from, and connect to a specific
service depending upon it. I don't really see any other use for the
OS-dependent port knocking, but it's something that's cool, and not
been done before, so I guess it's news-worthy.
1. TCPWrappers (has to be be right IP and/or daemon) 2. Portknocking (has to have the right sequence) 3. Passive Fingerprinting (only Linux and BSD systems can connect) 4. Keys Only (you must have the correct DSA private key)
Usually unnecessary, yet very interesting - much like Slashdot itself....
Re:Layers by archen (Score:1) Sunday August 01, @10:43AM
Re:Layers by burns210 (Score:2) Sunday August 01, @05:35PM
Re:Layers by danielrm26 (Score:2) Sunday August 01, @08:03PM
Re:Layers by voixderaison (Score:1) Friday August 06, @09:55AM
the bigger is the chance of screwing up. The point of port knocking is
to have a simple and therefore less bug prone layer around real
authentication systems like ssh, so that when a bug in ssh is found,
portscanners don't find your vulnerable service. Complicated port
knocking systems defeat the purpose of port knocking.
While port knocking is by now an established technique, I do not think
OS fingerprinting adds anything useful, because the ease of static
replay attacks is left unchanged by OS fingerprinting. Though
not that easy, OS spoofing is not remarkably labour intensive, and
setting up a "OS generator" who will replay the static attack with
every known OS is a distinct possibility. In other words, though a nice intellectual possibility, it is perhaps of rather limited application. Now, mixing instead knocking and a cryptographic application seems to me instead more promising.
are techniques I've seen appearing for the last 10 years that are
designed to compartment sections of the net. They make me sad, because
that's definitely not what the net was intended to be, i.e. a global
interconected network of machines to freely communicate. Instead, the
net is slowly being segregated, and you'll soon have to show some sort
of proof of identity to do anything other than HTTP. If you don't
believe me, just consider how hard it is to do something as mundane as
a DCC CHAT on IRC today, as opposed to, say, in 1994.
I
realize the need for these things, basically forced upon us by the
combination of commercial interests, shitty insecure OS, script kiddies
and greedy crackers (not hackers), but all the same, I can't help
realize that the internet of today is a far cry from what it was
intended to be in terms of freedom of communication...
I agree with your points, but surely you must see that this commentary
of yours applies to pretty much every invention known to man that is
both powerful and started out being free and open.
Look
at air travel - there you have spend a ton of time just getting on a
plane because of very few bad people. The Wright brothers didn't want
this, I'm sure, but it doesn't mean the invention is being perverted in
any way; it only says that our world is hostile and that we must
protect ourselves from ourselves. Anything useful and completely open these days is ripe for exploitation.
Never under-estimate the power of stupid people in large groups.
I
can't help realize that the internet of today is a far cry from what it
was intended to be in terms of freedom of communication
Um...wasn't
the internet born at the department of defense? Awfully nice of them,
to make this huge network for freedom of communication.
Oh,
wait, that's not what it was intended for. It was intended to be a
network of communication, built to survive outages of several large
nodes, in case of a nuclear attack. It's only been as more and more
people began romaticising it, that we've come up with this free
communications thing.
While I'm not apposed to it, I am
realistic about it. Would you leave your car, complete with keys,
parked in a stadium parking lot, with an open door, and a sign stuck on
the steering wheel saying, "Please don't take"? That's essentially what
you do with your computer when you go online without any sort of
protection ( short of the sign, mind you ).
I'm not a history buff but I can't recall anything I've read about
ARPAnet being created with the intention of complete access to all
connected machines.
I
think the majority of people - geeks included, but not to the exclusion
of everyone else - think the internet, on the whole, is performing
fairly reasonably. Just like in reality, when you have a small group of
people working together, issues of trust are much easier to deal with
compared to working with hundreds of millions of people.
Blaming "commercial interests, shitty insecure OS,..."
are symptoms of having a ton of people connected. Assuming the internet
would be perfect if those bad people didn't exist, there'd be a new
group people didn't like: spammers, NET SENDers, etc. Once they are
gone, we'd be left with people that use software we don't like, or
people from a country we don't like.
Soon enough, the Internet would be compartmentalized exactly the way you fear - into groups of like-minded people instead.
The
Internet isn't supposed to be utopia. It was about making resources
easier to access and it does that job amazingly well, given the
imperfect people using it.
Not more - not less. All that portknocking does is shifting the security to a layer where it doesn't belong.
And
even if you don't want others to see that there are services running on
your host there are better solutions. e.g. sending a special string to
some UDP port.
If someone can sniff your traffic and he knows
about portknocking it's trivial for him to detect it. If someone can't
sniff your traffic there's no advantage in using portknocking.
Port knocking has one specific and reasonable purpose: It hides open
ports from port scanners. Yes, it's security by obscurity, but as it's
supposed to be another layer, it can increase security if, and only if it's simple
enough that there is a near-zero chance of introducing new exploitable
bugs into the system. Passive monitoring is not necessarily
unexploitable. There are bugs in packet capture tools. There will be
exploitable bugs in complicated port knocking daemons. Keep port
knocking simple and it can be a valuable security enhancement. Make it
complicated and it becomes another thing that can break.
Port
knocking buys you the time between a new ssh exploit and the fix. It
significantly reduces the chance of being found by portscanners and
therefore of being hacked. You still have to fix ssh though.
People who make blanket statements like "Security through obscurity is bad" really annoy me. What a load of crap.
Secuirty
through obscurity is bad when it's the only form of security. However,
what is bad about using it to enhance existing security? What is bad
about making things that little bit more difficult for a hacker?
No
where in this has the author said you should replace your existing
security models with this. All it's done is add another layer to help
disguise your existing security making it that much harder to crack. No
one has "shifted" the security anywhere.
I agree that UDP could be used similarly to port knocking. Both methods
will serve equally well when the attacker is unaware of the method you
choose to use. (true security through obsecurity). I also agree that
both methods are equally vulnerable if the attacker can sniff your
network traffic, and they can get in by replaying the requests.
However,
lets assume that the security daemons are *not* vulnerable to replay
type attacks becuase we use one time pads, or computed keys or
something. In this case, sniffing will tell the attacker what method is
in use, but it won't allow them to get in by simply repeating a
successful login sequence. Are the methods still equivalent?
I
would think that port knocking would still be safer of the two. The
port knocking monitor is still sitting behind the firewall, isolated
from the network traffic. It would be more difficult to induce a
failure in the monitor. Even if the monitor failed, the security would
revert to the firewall -- which means you don't get in.
On the
other hand, your UDP daemon would have to be written just as carefully
as the services you are trying to protect. A buffer overflow, or any
similar flaws in your daemon could allow someone to break in through
your daemon. And such a flaw could be exploited blindly too -- all the
attacker would have to suspect is that you are using a flawed daemon.
Not more - not less. All that portknocking does is shifting the security to a layer where it doesn't belong.
Yes,
but that's exactly the point. Portknocking is a steganographic
application: it doesn't protect the message, but hides the existence of
the message. It does so precisely because it interferes at a layer
where it doesn't belong.
And even if you don't want others to
see that there are services running on your host there are better
solutions. e.g. sending a special string to some UDP port.
No,
because having a server listen on a UDP port clearly signals the
expectation of meaningful communication. The equivalent of portknocking
would be a server that listens on a UDP port, but rather than looking
at the string it receives, looks at (say) the delay between each byte
received. Obviously network delays and other uncontrollable factors
make this impractical.
If someone can sniff your traffic and
he knows about portknocking it's trivial for him to detect it. If
someone can't sniff your traffic there's no advantage in using
portknocking.
It's not that simple. Even if somebody can
sniff traffic in principle, he can't sniff everybody's traffic all the
time. He has to evaluate which targets are likely to yield anything of
value. Since a system protected by portknocking does not give him any
clues of what he can expect to find, why would he sniff your traffic?
Am
I the only one to wonder why the author made a deamon that watches
iptable-logs and then modify the ruleset when a matching knock sequence
is found instead of implementing a iptables match module instead?
Same goes for psad [cipherdyne.org] (by same author) -- I thought the purpose of iptables was to allow plug-in modules to be COMBINED.
I always considered watching logs to be a very ugly and inelegant way
of doing port knocking. Netfilter is stateful, why not make use of it?
Use
the recent match module and something like the following for requiring
ports 1000, 2000 and 3000 to be knocked in order and within 30 seconds
before allowing ssh from a particular host:
Would this if further developed simply allow a company say, like
Microsoft to prevent people who are not using Windows to visit
websites?
If put on servers that would be trouble for many Linux users. Microsoft
could just try to shrug it off saying that its not a "trusted"
operating system.
Anyone using say, frontpage or Windows Server could effectively just by
using those products prevent "those dirty Open Source infidels" from
viewing big websites....just a thought.
The passive operating system fingerprints
are going to prove to be useless in preventing abuse. It boils down to
this -- you can't trust any information gained exclusively from the
user (even passively).
Writing software to spoof OS
characteristics won't prove to be a challenge, esp. when you know what
characteristics the other side is trying to detect. I just can't really
see this system as bringing any added value at all.
Would be to implement invisible port knocking, that is one where there
is no preceeding magic packet that would hint the attacker about the
presence of port knocker.
You
can encode plenty of bits of data into the initial sequence number,
TTL, window size, timestamp options and so forth (you can probably
stuff a TCP packet with up to 128 bits of data with no effort).
The
port knocking daemon could then only allow connections for which this
128 footprint matches the one-time cryptographically generated
password, silently dropping all other traffic.
I mean it seems cute and all, but what does it buy you that, for
example, sending a UDP packet with an access code in it (perhaps
specific to the time of day and other parameters) doesn't get you?
Also, at the Black Hat Briefings, David Worth has released a cryptographic port knock implementation based around one-time pads.
The summary is incorrect: David Worth's tool uses one-time
passwords, not one-time pads. That's a good thing, because one-time
pads would make the system really inconvenient to use.
But
for the BSD users out there, PF has support for a thing called 'AuthPF'
which allows people access to specific ports with IPSEC.
So you can drop all packets from whatever port/s unless the
client authenicates first, which can also be used in conjunction with
fingerprints/Altq etc etc. This is more secure then just port
knocking+Fingerprints and can also be used for a more secure way to
authenticate your WIFI AP's then 802.11* WAP.
All trademarks and copyrights on this
page are owned by their respective owners. Comments
are owned by the Poster.
The Rest © 1997-2004