Port Knocking on openBSD?

[Mathieu Parent]

Hi everyone, I was wondering if anyone knows of a working implementation of
port knocking (with pf of course) on openBSD? Damn I really hope I won't
have to dig out the old perl books for this one :)

Any on going projects?
Any working projects?


Thanks in advance,

Jd

_________________________________________________________________
Learn how to choose, serve, and enjoy wine at Wine @ MSN.
http://wine.msn.com/

[stan]

Post by Mathieu Parent
Hi everyone, I was wondering if anyone knows of a working implementation of
port knocking (with pf of course) on openBSD? Damn I really hope I won't
have to dig out the old perl books for this one :)
Any on going projects?
Any working projects?

Been reading Slashdot huh?

Did you try the example perl code they pointed to?

[Richard P. Koett]

Post by stan

Post by Mathieu Parent
Hi everyone, I was wondering if anyone knows of a working
implementation of port knocking (with pf of course) on openBSD?
Damn I really hope I won't have to dig out the old perl books for
this one :)
Any on going projects?
Any working projects?

Been reading Slashdot huh?

Or maybe SysAdmin magazine, June 2003. I haven't looked at any other
links but the one in that article now points to
http://www.portknocking.org

[Rick Wash]

Post by Mathieu Parent
Hi everyone, I was wondering if anyone knows of a working implementation
of port knocking (with pf of course) on openBSD? Damn I really hope I
won't have to dig out the old perl books for this one :)
Any on going projects?
Any working projects?

OpenBSD has a much better and more secure solution to this problem. Its
called AuthPF.

Rick

[Edward Paul Wehrwein]

Post by Rick Wash

Post by Mathieu Parent
Hi everyone, I was wondering if anyone knows of a working implementation
of port knocking (with pf of course) on openBSD? Damn I really hope I
won't have to dig out the old perl books for this one :)
Any on going projects?
Any working projects?

OpenBSD has a much better and more secure solution to this problem. Its
called AuthPF.
Rick

That might be the most ignorant thing I've ever heard.

Paul

[Magnus Bodin]

Post by Rick Wash
OpenBSD has a much better and more secure solution to this problem. Its
called AuthPF.

authpf is fine. I use it.

But if you don't want to expose any tcp-ports at all, that includes port 22 as
well. And if you are on the move and cannot guarantee that ah/esp et al is even
transported then one alternative is to hide.

I personally don't like the "port-knocking" way of doing it and the
implementation itself so I wrote a simple script myself that

1. use Net::Pcap and listen for ICMP echo req.
2. if a valid combination of uid + one time password
flies by in the PAYLOAD of the ICMP, then insert ip in
a special pf-table (so she will get access to tcp/22).
3. check regulary for table-entries that has had no valid connection
for a couple of minutes and remove them from the table.

Pretty trivial and effective and a good complement to authpf, actually.
If any is interested I can wrap it up in a package.

I trust OpenSSH as I trust my ASSA Twin-lock on my house, but only those who
walk upfront my yard will be able to test their lock-picking abilities to it.

If it's possible to hide my tcp/22-port from occasional portscan-kiddies,
that would be a way of lowering the risk even more.

[Adam Skutt]

Post by Magnus Bodin
But if you don't want to expose any tcp-ports at all, that includes port 22 as
well. And if you are on the move and cannot guarantee that ah/esp et al is even
transported then one alternative is to hide.

Why should I care about exposed ports? Security arises not out of how
many ports are being shown or not shown, but rather how secure the
servicse behind them are. It doesn't matter if all my ports are open if
the services running them have no security flaws ( a pipe dream, but
illustrates the point).

Post by Magnus Bodin
I personally don't like the "port-knocking" way of doing it and the
implementation itself so I wrote a simple script myself that
1. use Net::Pcap and listen for ICMP echo req.
2. if a valid combination of uid + one time password
flies by in the PAYLOAD of the ICMP, then insert ip in
a special pf-table (so she will get access to tcp/22).
3. check regulary for table-entries that has had no valid connection
for a couple of minutes and remove them from the table.
Pretty trivial and effective and a good complement to authpf, actually.
If any is interested I can wrap it up in a package.

This is a far smarter idea then a port-knock ( a poor idea at
masquerading at a port scan), but still has the same problem: its just
obscuring things, and it may draw more attention then just making an SSH
connection. Why? Because a ping packet large enough to contain a
username and a one-time password are larger than most, and any one
monitoring your network, looking for a way in, will see that as a big
red flag.

Post by Magnus Bodin
I trust OpenSSH as I trust my ASSA Twin-lock on my house, but only those who
walk upfront my yard will be able to test their lock-picking abilities to it.

Living back in the woods (which is what your little thing does), but it
doesn't make it that much harder to find you house, if I have any desire
to get in.

Post by Magnus Bodin
If it's possible to hide my tcp/22-port from occasional portscan-kiddies,
that would be a way of lowering the risk even more.

How? What risk does it lower? What do you lose from a portscan,
besides a tiny bit of network traffic? You still haven't explained how
this increases teh security of your box.

-- Adam

[Greg Thomas]

Scenario: I need to be able to SSH into a box from anywhere in the world but not very often, a new exploit of SSH comes out. What's the better solution than port knocking to protect yourself from the exploit?

Just curious as it's interesting to think this stuff through and I'm not very knowledgable here.

Greg

Post by Magnus Bodin
But if you don't want to expose any tcp-ports at all, that includes port 22 as
well. And if you are on the move and cannot guarantee that ah/esp et al is even
transported then one alternative is to hide.

Why should I care about exposed ports? Security arises not out of how
many ports are being shown or not shown, but rather how secure the
servicse behind them are. It doesn't matter if all my ports are open if
the services running them have no security flaws ( a pipe dream, but
illustrates the point).

[Dom De Vitto]

Exactly, there is no silver bullet to security.

Excluding port knocking is like excluding packet filtering - after all
any packet filter is useless if appropriate packets can be generated
to pass it, it's just security though obscurity that the attacker does
know the ruleset.

I would say that embedding usernames/passwords into pings is _not_
such a good idea, simply because of the risk if that user/password
also being similar other you may own, e.g. your ssh credentials.

The bottom line is that security through obscurity is flawed, as long
as you understand the flaws, it's better than nothing.

Dom
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Dom De Vitto Tel. [phone]
http://www.devitto.com mailto:***@devitto.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-----Original Message-----
From: owner-***@openbsd.org [mailto:owner-***@openbsd.org] On Behalf Of
Greg Thomas
Sent: Friday, February 06, 2004 5:53 PM
To: ***@openbsd.org
Subject: Re: Port Knocking on openBSD?

Scenario: I need to be able to SSH into a box from anywhere in the world
but not very often, a new exploit of SSH comes out. What's the better
solution than port knocking to protect yourself from the exploit?

Just curious as it's interesting to think this stuff through and I'm not
very knowledgable here.

Greg

Post by Magnus Bodin
But if you don't want to expose any tcp-ports at all, that includes
port 22 as well. And if you are on the move and cannot guarantee that
ah/esp et al is even transported then one alternative is to hide.

Why should I care about exposed ports? Security arises not out of how many
ports are being shown or not shown, but rather how secure the servicse
behind them are. It doesn't matter if all my ports are open if the services
running them have no security flaws ( a pipe dream, but illustrates the
point).

[Nick Holland]

Post by Greg Thomas
Scenario: I need to be able to SSH into a box from anywhere in the world but not very often, a new exploit of SSH comes out. What's the better solution than port knocking to protect yourself from the exploit?

Same as the answer to "What's the protection if your port knocking
system has an exploit?"

Post by Greg Thomas
Just curious as it's interesting to think this stuff through and I'm not very knowledgable here.

One idea: have one box you keep "safe" and up to date and able to fix
quickly. New SSH exploit comes out, you fix that box first. Your
other systems are filtered to only accept ssh traffic from that one
box (actually, for redundancy purposes, have TWO boxes on totally
different locations/service providers)

Out at a random location? ssh into your "hub" machine, then from
there to the remote system you need to maintain.

Nick.
--
http://www.holland-consulting.net

[Henning Brauer]

Post by Nick Holland

Post by Greg Thomas
Scenario: I need to be able to SSH into a box from anywhere in the world but not very often, a new exploit of SSH comes out. What's the better solution than port knocking to protect yourself from the exploit?

Same as the answer to "What's the protection if your port knocking
system has an exploit?"

isn't it funny that ppl try to protect themselves from bugs in software
by adding even more software?

[Greg Thomas]

Post by Nick Holland

Post by Greg Thomas
Scenario: I need to be able to SSH into a box from anywhere in the
world but not very often, a new exploit of SSH comes out. What's the
better solution than port knocking to protect yourself from the
exploit?

Same as the answer to "What's the protection if your port knocking
system has an exploit?"

Aren't layers good?

Post by Nick Holland

Post by Greg Thomas
Just curious as it's interesting to think this stuff through and I'm
not very knowledgable here.

One idea: have one box you keep "safe" and up to date and able to fix
quickly. New SSH exploit comes out, you fix that box first. Your
other systems are filtered to only accept ssh traffic from that one
box (actually, for redundancy purposes, have TWO boxes on totally
different locations/service providers)
Out at a random location? ssh into your "hub" machine, then from
there to the remote system you need to maintain.

Yes, that's a great idea. But if you're a small shop you may have
trouble updating that one "safe" box.

Greg

[STeve Andre']

Post by Greg Thomas

Post by Nick Holland

Post by Greg Thomas
Scenario: I need to be able to SSH into a box from anywhere in the
world but not very often, a new exploit of SSH comes out. What's the
better solution than port knocking to protect yourself from the
exploit?

Same as the answer to "What's the protection if your port knocking
system has an exploit?"

Aren't layers good?

Post by Nick Holland

Post by Greg Thomas
Just curious as it's interesting to think this stuff through and I'm
not very knowledgable here.

One idea: have one box you keep "safe" and up to date and able to fix
quickly. New SSH exploit comes out, you fix that box first. Your
other systems are filtered to only accept ssh traffic from that one
box (actually, for redundancy purposes, have TWO boxes on totally
different locations/service providers)
Out at a random location? ssh into your "hub" machine, then from
there to the remote system you need to maintain.

Yes, that's a great idea. But if you're a small shop you may have
trouble updating that one "safe" box.
Greg

Layers add complexity to the equation (whatever you are doing).
When you add complexity, you give rise to the "who owns the bug"
problem when sometihng goes wrong.

Yes, a small shop could have problems updating that one "safe"
box. But its a single point of failure, isn't it. And if you don't trust
SSH you shouldn't be using it. There are no guarantees in software,
but the OpenSSH team has produced an excellent system. It may
have problems from time to time, but thats the nature of the game,
isn't it. What I'm concerned with is how problems are dealt with.
The OpenBSD 3.1 era SSH problem was dealt with as well as I think
it could have been, and THAT is what matters--how bad problems
are dealt with.

Adding layers to "protect" yourself generally doesn't work, because
you have have several layers to worry about and deal with when
things go wonky...

--STeve Andre'

[Nick Holland]

...

Post by Greg Thomas

Post by Nick Holland
Same as the answer to "What's the protection if your port knocking
system has an exploit?"

Aren't layers good?

If they truly are layers between abuser and target, yes. If breaking
the first layer means you now have to work on the second layer, yes.

However, if the first layer has a root exploit: no.


If you look at privilege separation in OpenSSH, the defense there is
in layers -- privilege separation adds a layer of program protection
to the standard security systems of the SSH protocol. Find a hole in
the implementation, the privsep keeps you stuck, able to do almost
nothing. "Port knocking" at first looks like a layer of protection
before you get to SSH, but that's only when things work right. When
things work wrong, if the exploit is in the "port knocking" itself,
game over, they are in on just one layer -- an entryway into your
system that didn't even exist previously. Note that the "port
knocking" usually adjusts filter rules, that's typically a root-level
task.

Note the irony here: the GOOD GUYS go through layers, and because it
is more difficult for them, it sounds "safer". If the bad guys can
bust in at the first layer, they have reached their goal.

As Steve and Henning pointed out: this adds complexity. If people
spent time auditing code rather than adding code, I think the security
situation would improve much more than the added complexity improves
things.

Post by Greg Thomas

Post by Nick Holland

Post by Greg Thomas
Just curious as it's interesting to think this stuff through and I'm
not very knowledgable here.

One idea: have one box you keep "safe" and up to date and able to fix
quickly. New SSH exploit comes out, you fix that box first. Your
other systems are filtered to only accept ssh traffic from that one
box (actually, for redundancy purposes, have TWO boxes on totally
different locations/service providers)
Out at a random location? ssh into your "hub" machine, then from
there to the remote system you need to maintain.

Yes, that's a great idea. But if you're a small shop you may have
trouble updating that one "safe" box.

Depends on what kind of shop. I've had no problem convincing clients
to host a low-traffic machine of mine at their site. There are
benefits for them -- I'm often tracking down a network problem for
them before they even realize they are down ("Could you reset your
router?" "Why?" "You're down" "We are?? Oh, we are!"). Redundancy
here is key -- you don't want to have just one remote site, in case a
management change has you (and your computer) out on the curb one
morning... If you aren't supporting multiple sites, "partnerships"
between companies, "You host mine, I'll host yours" can work, too.

Nick.

[Dom De Vitto]

Key point Henning realised, we didn't.

Layers are good, but the portknocking is an inner layer:
- is it priv-sep'd ? No (I'm guessing), so an exploit *could* give root.

Which makes it more likely for bugs to be worth exploiting.
At least with SSH you've a limited amount of code which can be wrong
and give root.

Dom
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Dom De Vitto Tel. [phone]
http://www.devitto.com mailto:***@devitto.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Where do you want to go today? Same as every day.... Windows Update.
-----Original Message-----
From: owner-***@openbsd.org [mailto:owner-***@openbsd.org] On Behalf Of
Greg Thomas
Sent: Sunday, February 08, 2004 12:45 AM
To: ***@openbsd.org
Subject: Re: Port Knocking on openBSD?

Post by Nick Holland

Post by Greg Thomas
Scenario: I need to be able to SSH into a box from anywhere in the
world but not very often, a new exploit of SSH comes out. What's the
better solution than port knocking to protect yourself from the
exploit?

Same as the answer to "What's the protection if your port knocking
system has an exploit?"

Aren't layers good?

Post by Nick Holland

Post by Greg Thomas
Just curious as it's interesting to think this stuff through and I'm
not very knowledgable here.

One idea: have one box you keep "safe" and up to date and able to fix
quickly. New SSH exploit comes out, you fix that box first. Your
other systems are filtered to only accept ssh traffic from that one
box (actually, for redundancy purposes, have TWO boxes on totally
different locations/service providers)
Out at a random location? ssh into your "hub" machine, then from
there to the remote system you need to maintain.

Yes, that's a great idea. But if you're a small shop you may have trouble
updating that one "safe" box.

Greg

[Magnus Bodin]

Post by Dom De Vitto
Key point Henning realised, we didn't.
- is it priv-sep'd ? No (I'm guessing), so an exploit *could* give root.

"portknocking" is not an interactive protocol per se. It is listening to
filtered packets and if a well defined packet content flies by or in the
original port knocking scheme, a specific order of probes occurs, then a
pf-table is populated to give access to a specific port.

If such a program crashes you could not give root. Or any shell.
A sigificant risk would be that someone may DoS the "portknocking
service".

Other speculations about having userid and ssh credentials in the
portknocking packets is just dumb of course. What should be used is one
time passwords or similar that cannot be reused or guessed.

It should in addition be run on a transparent bridge, making it just a
gatekeeper. And thus making it a true layer.

"Portknocking" is of course just the most obscure and "less secure" way
of convincing the gatekeeper that you are allowed over the brigde. Other
offline ways is one-time-passwords sent to a specific GSM-number hooked
up to the bridge, touch-tone gateways, etc.

[Dom De Vitto]

Bzzzzt.
Q. What listening for these messages?
A. A program.
Q. Does this program run as root?
A. Yup.
Q. Do programs have bugs?
A. Yup.
Q. What happens if it's got a weird overflow or shell expansion bug?
A. Bad things.
Q. What happens if it can be tricked into putting bad stuff into
your pf.conf?
A. Bad things.
Q. Do you want root doing bad things on your firewall?
A. Nope! That was the idea in the first place!
Q. What do you trust more, the portknocker, or OpenSSH?
A. [obvious]

Dom
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Dom De Vitto Tel. [phone]
http://www.devitto.com mailto:***@devitto.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Where do you want to go today? Same as every day.... Windows Update.

-----Original Message-----
From: Magnus Bodin [mailto:***@bodin.org]
Sent: Sunday, February 08, 2004 1:51 PM
To: Dom De Vitto
Cc: ***@openbsd.org
Subject: Re: Port Knocking on openBSD?

Post by Dom De Vitto
Key point Henning realised, we didn't.
- is it priv-sep'd ? No (I'm guessing), so an exploit *could* give root.

"portknocking" is not an interactive protocol per se. It is listening to
filtered packets and if a well defined packet content flies by or in the
original port knocking scheme, a specific order of probes occurs, then a
pf-table is populated to give access to a specific port.

If such a program crashes you could not give root. Or any shell.
A sigificant risk would be that someone may DoS the "portknocking service".

Other speculations about having userid and ssh credentials in the
portknocking packets is just dumb of course. What should be used is one time
passwords or similar that cannot be reused or guessed.

It should in addition be run on a transparent bridge, making it just a
gatekeeper. And thus making it a true layer.

"Portknocking" is of course just the most obscure and "less secure" way of
convincing the gatekeeper that you are allowed over the brigde. Other
offline ways is one-time-passwords sent to a specific GSM-number hooked up
to the bridge, touch-tone gateways, etc.

[Darren Reed]

Post by Dom De Vitto
Bzzzzt.
Q. What listening for these messages?
A. A program.
Q. Does this program run as root?
A. Yup.
Q. Do programs have bugs?
A. Yup.
Q. What happens if it's got a weird overflow or shell expansion bug?
A. Bad things.
Q. What happens if it can be tricked into putting bad stuff into
your pf.conf?
A. Bad things.
Q. Do you want root doing bad things on your firewall?
A. Nope! That was the idea in the first place!
Q. What do you trust more, the portknocker, or OpenSSH?
A. [obvious]

The last answer is not obvious.

OpenSSH is an extremely complex progam.
A portknocker needs to be quite simple by comparison.

You should be able to code up a portknocker that is easily
verifably safe from buffer overflows, etc. Verifably safe
in a way that you could never do as easily with OpenSSH.

That said, you probably won't believe it until someone codes
one up.

Darren

[Magnus Bodin]

Post by Adam Skutt
Why should I care about exposed ports? Security arises not out of how

Every now and then there has been an exploit for SSH.
Last time it happened it took me 6 hours to 1. know about this. 2. Get to a
network. 3. Fix this. The "port blinds" provided at least a protection against
the youngsters in the "wrong" time zone which jumps on new exploits immediately
and runs scanssh for targets.

Post by Adam Skutt
Why? Because a ping packet large enough to contain a username and a
one-time password are larger than most, and any one monitoring your
network, looking for a way in, will see that as a big red flag.

Not true.
A normal ping packet generated by "/sbin/ping" is big enough to include 16
bytes. If you use -p you can provide those 16 bytes on the commandline.
No change in size.

The big red flag however would be an opened ssh-connection to the box.

But that should not be a problem as openssh is safe, right?

Yes. Listening to ICMP echo requests has limitations and vulnerabilities and is
of course not a reason to *postpone* upgrades and patches. It is an addition,
complement, etc.

[Tim Kornau]

Post by Magnus Bodin

Post by Rick Wash
OpenBSD has a much better and more secure solution to this problem. Its
called AuthPF.

authpf is fine. I use it.
But if you don't want to expose any tcp-ports at all, that includes port 22 as
well. And if you are on the move and cannot guarantee that ah/esp et al is even
transported then one alternative is to hide.
I personally don't like the "port-knocking" way of doing it and the
implementation itself so I wrote a simple script myself that
1. use Net::Pcap and listen for ICMP echo req.
2. if a valid combination of uid + one time password
flies by in the PAYLOAD of the ICMP, then insert ip in
a special pf-table (so she will get access to tcp/22).
3. check regulary for table-entries that has had no valid connection
for a couple of minutes and remove them from the table.
Pretty trivial and effective and a good complement to authpf, actually.
If any is interested I can wrap it up in a package.
I trust OpenSSH as I trust my ASSA Twin-lock on my house, but only those who
walk upfront my yard will be able to test their lock-picking abilities to it.
If it's possible to hide my tcp/22-port from occasional portscan-kiddies,
that would be a way of lowering the risk even more.

i guess you will have to read the source but this one is a goodie

http://cmn.listprojects.darklab.org/

opti

--
Darksun rising over blood red sea

[demime 0.98d removed an attachment of type application/pgp-signature]

[Claus Assmann]

Post by Dom De Vitto
Bzzzzt.
Q. What listening for these messages?
A. A program.
Q. Does this program run as root?
A. Yup.

Bad design.

Post by Dom De Vitto
Q. Do programs have bugs?
A. Yup.
Q. What happens if it's got a weird overflow or shell expansion bug?
A. Bad things.
Q. What happens if it can be tricked into putting bad stuff into
your pf.conf?

Bad design.

Use two programs.

The program that listens on ports doesn't need to run as root.
The program that modifies pf.conf doesn't need to be able to
put anything but one line into it. You might even have it only
copy one of two files in place and reload the rules.

[Sebastian Benoit]

Post by Claus Assmann
The program that listens on ports doesn't need to run as root.
The program that modifies pf.conf doesn't need to be able to
put anything but one line into it. You might even have it only
copy one of two files in place and reload the rules.

You only have to add an address to a table.

/B.