new tool: openportd

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

new tool: openportd

Steffen Wendzel
hi,

I wrote a new tool I call OpenPortd for my linux distribution
but since I my linux distribution is still under development
and I want to release the tool, I wrote an OpenBSD version
too, you maybe like it.

It is like a port knocking service but a little bit different:

Normaly a port knocking service uses TCP/UDP, but openportd
uses ICMP echo response packets because they are not so easy
to send like echo requests or TCP/UDP port tests (kiddies could
simply use ping or nmap for this job).

You can define keys and actions in /etc/openportd.conf. If a
key is received, an action is executed. Here are examples:

04t3904jg034 reboot
0987654321   pkill sshd
1234567890   /usr/sbin/sshd
40tg340503n5 pf/iptables (load some other rules or whatever)

You can download the tgz file here:
http://files.doomed-reality.org/Projects/openportd/

There is currently no client available. But you can for example
use my vstt[1] and send data via FIFO to vstt using icmp
tunneling mode.

regards
steffen

[1] http://www.ploetner-it.de/~dr/site/index.php?id=70

Reply | Threaded
Open this post in threaded view
|

Re: new tool: openportd

Nick Guenther
On 10/21/06, Steffen Wendzel <[hidden email]> wrote:

> hi,
>
> I wrote a new tool I call OpenPortd for my linux distribution
> but since I my linux distribution is still under development
> and I want to release the tool, I wrote an OpenBSD version
> too, you maybe like it.
> [...]
> You can define keys and actions in /etc/openportd.conf. If a
> key is received, an action is executed. Here are examples:
>
> 04t3904jg034 reboot
> 0987654321   pkill sshd
> 1234567890   /usr/sbin/sshd
> 40tg340503n5 pf/iptables (load some other rules or whatever)
>

So this is like an insecure version of SSH?

-Nick

Reply | Threaded
Open this post in threaded view
|

Re: new tool: openportd

Antti Harri
On Sat, 21 Oct 2006, Nick Guenther wrote:

> On 10/21/06, Steffen Wendzel <[hidden email]> wrote:
>> 40tg340503n5 pf/iptables (load some other rules or whatever)
>>
>
> So this is like an insecure version of SSH?

If you configure it to behave like that, probably.
But if you configure it to open a port for
a client that knows the key, no.


--
Antti Harri

Reply | Threaded
Open this post in threaded view
|

Re: new tool: openportd

Steffen Wendzel
In reply to this post by Nick Guenther
On Sat, 21 Oct 2006 20:57:39 -0400 "Nick Guenther" <[hidden email]> wrote:

: On 10/21/06, Steffen Wendzel <[hidden email]> wrote:
: > hi,
: >
: > I wrote a new tool I call OpenPortd for my linux distribution
: > but since I my linux distribution is still under development
: > and I want to release the tool, I wrote an OpenBSD version
: > too, you maybe like it.
: > [...]
: > You can define keys and actions in /etc/openportd.conf. If a
: > key is received, an action is executed. Here are examples:
: >
: > 04t3904jg034 reboot
: > 0987654321   pkill sshd
: > 1234567890   /usr/sbin/sshd
: > 40tg340503n5 pf/iptables (load some other rules or whatever)
: >
:
: So this is like an insecure version of SSH?

it has nothing todo with SSH. And of course it isn't very secure
BUT it adds security where normaly no security is, thats the point.

You normaly have different open ports, but with this tool you can
open/close them on demand. This is at least a little bit more secure
than to have them open all the time.

--steffen

Reply | Threaded
Open this post in threaded view
|

Re: new tool: openportd

Kian Mohageri-2
On 10/22/06, Steffen Wendzel <[hidden email]> wrote:
>
>
> You normaly have different open ports



pf(4) makes this a minor issue.  No offense, but what you have there (in the
example specifically) is no better than a "limited" (if you consider ability
to reboot or kill ssh "limited") version of rexec/rsh.  The way you
authenticate is obscured a bit, but not secured.

A neat project, I'll give you that.  But I don't recommend it on a
production server.

--
Kian Mohageri

Reply | Threaded
Open this post in threaded view
|

Re: new tool: openportd

Clint M. Sand
On Sun, Oct 22, 2006 at 03:55:39AM -0700, Kian Mohageri wrote:

> On 10/22/06, Steffen Wendzel <[hidden email]> wrote:
> >
> >
> > You normaly have different open ports
>
>
>
> pf(4) makes this a minor issue.  No offense, but what you have there (in the
> example specifically) is no better than a "limited" (if you consider ability
> to reboot or kill ssh "limited") version of rexec/rsh.  The way you
> authenticate is obscured a bit, but not secured.
>
> A neat project, I'll give you that.  But I don't recommend it on a
> production server.
>
> --
> Kian Mohageri

Not to mention anyone on your network can sniff the "key", replay
attacks, oh and running a daemon that is able to listen on all ports
that is not from openbsd base...

Authpf would allow you only open connections only to people who can
authenticate, which cannot be easiliy sniffed and replayed such as with
"port knocking".

Reply | Threaded
Open this post in threaded view
|

Re: new tool: openportd

Inigo T. A.
In reply to this post by Steffen Wendzel
El dom, 22-10-2006 a las 12:40 +0200, Steffen Wendzel escribis:
> On Sat, 21 Oct 2006 20:57:39 -0400 "Nick Guenther" <[hidden email]> wrote:

> :
> : So this is like an insecure version of SSH?
>
> it has nothing todo with SSH. And of course it isn't very secure
> BUT it adds security where normaly no security is, thats the point.
>
> You normaly have different open ports, but with this tool you can
> open/close them on demand. This is at least a little bit more secure
> than to have them open all the time.

?why?

If you have a security problem with a service, the only "more secure"
action is to fix it, don't to open it eventually.

Regards

--
.-------------------------.
|  Inigo Tejedor Arrondo  |
|   [hidden email]    |
|  [hidden email]   |
'-------------------------'

Reply | Threaded
Open this post in threaded view
|

Re: new tool: openportd

Steffen Wendzel-2
On Sun, 22 Oct 2006 14:42:18 +0200 "Inigo T. A." <[hidden email]> wrote:

: El dom, 22-10-2006 a las 12:40 +0200, Steffen Wendzel escribis:
: > On Sat, 21 Oct 2006 20:57:39 -0400 "Nick Guenther" <[hidden email]> wrote:
:
: > :
: > : So this is like an insecure version of SSH?
: >
: > it has nothing todo with SSH. And of course it isn't very secure
: > BUT it adds security where normaly no security is, thats the point.
: >
: > You normaly have different open ports, but with this tool you can
: > open/close them on demand. This is at least a little bit more secure
: > than to have them open all the time.
:
: ?why?
:
: If you have a security problem with a service, the only "more secure"
: action is to fix it, don't to open it eventually.
:

this isn't correct. Every service had some security problems in the
past. Imagin that your service X is vulnerable (only since a few h
by a zero day exploit or so) and someone tries to exploit it at 2:00 in
the morning.

but if you run some port knocking service (and your attacker does not
know the port combination/secrect key or even does not know about a
running port knocking system, he can not attack your service.

if you only need the service for administration, you could do such a
"hiding" of the service. you only would need to open the port by the
portknocking service a few min while you use it to do some administration.

Reply | Threaded
Open this post in threaded view
|

Re: new tool: openportd

Darrin Chandler
On Sun, Oct 22, 2006 at 04:41:17PM +0200, Steffen Wendzel wrote:

>
> this isn't correct. Every service had some security problems in the
> past. Imagin that your service X is vulnerable (only since a few h
> by a zero day exploit or so) and someone tries to exploit it at 2:00 in
> the morning.
>
> but if you run some port knocking service (and your attacker does not
> know the port combination/secrect key or even does not know about a
> running port knocking system, he can not attack your service.
>
> if you only need the service for administration, you could do such a
> "hiding" of the service. you only would need to open the port by the
> portknocking service a few min while you use it to do some administration.

This recently came up on another mailing list. Someone had a portknocker
similar to the one you have. It even had some interesting features that
yours doesn't have. So they felt secure.

They felt so secure that they were in no hurry to update the system and
left a very old, unpatched sshd on the box, guarded by the portknocker.
Imagine what happened. Yes, when they had the port opened someone hacked
the computer. Real life story, bad consequences.

Did the port knocker create this problem? Nooooo, but. If you realize
exactly what security you're getting (almost none) then you behave
differently and keep your box secure. If you think you're uber-secure
when you're not then you're asking for trouble. Are there people out
there with sshd using password auth and poor passwords thinking they're
safe because of a port knocker? Sure there are.

I don't use a port knocker, and I never have. I have friends that do,
and I warn them to keep their system patched anyway. If you have an
up-to-date system, using a port knocker doesn't hurt security and can
provide some small benefits like not being visible to ssh-scanning
script kiddies and therefore saving a bit of writing to /var/log.

--
Darrin Chandler            |  Phoenix BSD Users Group
[hidden email]   |  http://bsd.phoenix.az.us/
http://www.stilyagin.com/  |

Reply | Threaded
Open this post in threaded view
|

Re: new tool: openportd

polarapfel
In reply to this post by Steffen Wendzel-2
Hi,

On Oct 22, 2006, at 4:41 PM, Steffen Wendzel wrote:

> this isn't correct. Every service had some security problems in the
> past. Imagin that your service X is vulnerable (only since a few h
> by a zero day exploit or so) and someone tries to exploit it at  
> 2:00 in
> the morning.
>
> but if you run some port knocking service (and your attacker does not
> know the port combination/secrect key or even does not know about a
> running port knocking system, he can not attack your service.

This is security by obscurity.

> if you only need the service for administration, you could do such a
> "hiding" of the service. you only would need to open the port by the
> portknocking service a few min while you use it to do some  
> administration.

The thing about running a port knocking service to "protect" or  
"hide" other services just adds another point of failure. Can you  
promise that this port knocking service which is running with root  
privileges, is not vulnerable to some overflow problem that could  
allow attackers to just send a knocking sequence that opens up the  
whole box?! No thanks. I'll stick with what I've got.

If you're so worried about 0-day exploits for OpenBSD services then  
just jail these services you're running with systrace. With Linux you  
can use SELinux or AppArmor.

The idea of port knocking is nice at first view but given the extra  
complexity it adds and the extra risk it's just not worth it, sorry.

just my thoughts about this,

Tobias W.

Reply | Threaded
Open this post in threaded view
|

Re: new tool: openportd

ropers
In reply to this post by Steffen Wendzel-2
On 22/10/06, Steffen Wendzel <[hidden email]> wrote:

> On Sun, 22 Oct 2006 14:42:18 +0200 "Inigo T. A." <[hidden email]>
> wrote:
>
> : El dom, 22-10-2006 a las 12:40 +0200, Steffen Wendzel escribis:
> : > On Sat, 21 Oct 2006 20:57:39 -0400 "Nick Guenther" <[hidden email]>
> wrote:
> :
> : > :
> : > : So this is like an insecure version of SSH?
> : >
> : > it has nothing todo with SSH. And of course it isn't very secure
> : > BUT it adds security where normaly no security is, thats the point.
> : >
> : > You normaly have different open ports, but with this tool you can
> : > open/close them on demand. This is at least a little bit more secure
> : > than to have them open all the time.
> :
> : ?why?
> :
> : If you have a security problem with a service, the only "more secure"
> : action is to fix it, don't to open it eventually.
> :
>
> this isn't correct. Every service had some security problems in the
> past. Imagin that your service X is vulnerable (only since a few h
> by a zero day exploit or so) and someone tries to exploit it at 2:00 in
> the morning.
>
> but if you run some port knocking service (and your attacker does not
> know the port combination/secrect key or even does not know about a
> running port knocking system, he can not attack your service.
>
> if you only need the service for administration, you could do such a
> "hiding" of the service. you only would need to open the port by the
> portknocking service a few min while you use it to do some administration.

Just in case not everyone here may be totally familiar with port
knocking, I'd like to weigh in, by way of explanation.
Or rather, I'd like to quote Captain Crunch, who gave a very eloquent
explanation of what this "knock-knock principle" is:

(from http://www.the-fifth-hope.org/mp3/draper-spam.mp3 ,
cf. http://www.the-fifth-hope.org/hoop/5hope_speakers.khtml )

``I believe there's approximately five hundred thousand to seven
hundred-fifty thousand infected hosts out there on the Internet.
Well, these infected hosts of course are being controlled by a small group
of people (...)
A lot of them are sophisticated spammers, and hackers who use these
infected hosts use a rather interesting way of hiding the fact that the
machine is infected. And this is done through what they call the
knock-knock principle. The way this works is, normally the listener is
turned off. So when you do a port scan, they don't show up. It's totally
invisible. However, if you send it a series of specially crafted pings
with special port numbers and a certain sequence, well, guess what: you
open up a port, the listener activates and you now can control that proxy.
That then becomes a master controller proxy, it then controls all the
rest. So it's almost virtually impossible to catch this level of spamming
and hacking, and these are how all of the dDoS attacks have happened as
well.''

I'd like to emphasize that I am a stong believer in the neutrality of
information and technology. I am NOT trying to accuse anyone of
anything here. Just because a majority of sophisticated spammers and
botnet controllers may use the knock-knock principle (=port knocking)
and *you* may be using the same tool or principle, that doesn't mean
you are a black hat. Whether you are ethical or not obviously depends
on what you're up to with your use of openportd.

I could see the use of openportd as an ADDITIONAL layer of security,
though I would caution that *part* of that extra security is "security
through obscurity" (which prolly most of us frown upon). To explain:

If you port-scan a default OpenBSD firewall, it's likely to show, say,
at least SMTP and SSH ports. (If you're incredibly lame and lazy, and
if this is your pf/NAT firewall through which you're surfin the Net,
you could even use this site to have it port scan yourself:
https://www.grc.com/x/ne.dll?bh0bkyd2 -- click Proceed -- All Service
Ports. That is, IFF you can see past the hyperbole, and don't mind
prompting an outside party to get ahold of your port scanning
profile.) Anyway.

So your machine. while well protected by all the safeguards built into
OpenBSD, is not totally invisible. An attacker can see that there's an
SSH daemon listening -- and if you've got password authentication on,
an attacker could start brute forcing your password.

Now let's assume you're running openportd. You probably still can't
close down the SMTP ports (25 UDP+TCP) if you want to directly receive
email, but in case you don't need to have an SMTPD listening, you
could probably close all ports entirely.

Now in order to access your box from the outside, you would need to be
able to run some kind of openport-client (or any other software that
you can use to send your specially crafted pings) on whatever
*outside* box you're trying to access your firewall *from*. So you
send your specially crafted pings (which serve as a weak
authentication mechanism and which CAN be sniffed and CAN be used in
replay attacks), and in response to you sending your specially crafted
pings, your firewall, for a limited time window, opens up the SSH
ports (22 UDP+TCP).
Now you can proceed to log on via SSH, **with full SSH security**.

Yes, a determined attacker might sniff your traffic and your use of
openportd might not be much of a hurdle to them.
No, you should never use openportd as your single authentication
mechanism (and killing services on your box purely based on the pings
openportd receives would be suicidally insecure).
But if the attacker doesn't know where you are, they might be
dramatically less likely to find you, if you're using openportd
**AND** SSH, because they would have to be listening somewhere along
the path your packets are taking to your box **at the same time** that
you're using the knock-knock protocol to open up your SSH port -- only
to then find themselves with the not in any way diminished challenge
of brute forcing your SSH password.

And that's my two Eurocents.
"Use the knowledge for good; that's what I would ask."

Cheers,
--ropers

PS:
All that said, if you were asking me whether or not openportd should
be included with OpenBSD (as I think was asked about earlier on), I
wouldn't comment on that. I don't have any say in such decisions and I
don't *want* any say in such decisions because I'm not qualified
enough to even give a properly informed opinion in such a decision.
Please don't interpret my above statements one way or another, and
please don't say anything like, "ropers was for this/against this as
well", because I'm not.

Reply | Threaded
Open this post in threaded view
|

Re: new tool: openportd

Nick Holland
In reply to this post by Steffen Wendzel-2
Steffen Wendzel wrote:
> On Sun, 22 Oct 2006 14:42:18 +0200 "Inigo T. A." <[hidden email]> wrote:
...
> : If you have a security problem with a service, the only "more secure"
> : action is to fix it, don't to open it eventually.
> :
>
> this isn't correct. Every service had some security problems in the
> past. Imagin that your service X is vulnerable (only since a few h
> by a zero day exploit or so) and someone tries to exploit it at 2:00 in
> the morning.

to correct a hypothetical flaw in service X, you are introducing a
service Y...

> but if you run some port knocking service (and your attacker does not
> know the port combination/secrect key or even does not know about a
> running port knocking system, he can not attack your service.

...what if there is a vulnerability in service Y?

Making things more complex rarely actually improves either security or
reliability.

> if you only need the service for administration, you could do such a
> "hiding" of the service. you only would need to open the port by the
> portknocking service a few min while you use it to do some administration.

I like to think of "physical" analogies.  I think this one is pretty
accurate for this case:

You have a building (computer), you don't fully trust the lock
(security) on the front door (service).

You could:
  Move the front door to the side of the building (change port number)
  Paint the front door purple (change the banner shown by the app)
  Drape a canvas tarp over the front door (port knocking)
  Throw away all your tools in the building so they can't be used
    against you (deleting compilers)
Or...
  You could fix the dang lock or replace the lock (security system) or
the entire door (service) with one that is more trusted.

Guess which one is the OpenBSD way?


There are some scary things in that analogy...
1) It is horrifying how trivial some things that people think improve
security really are...similar steps done for physical security on
buildings would be typically not even noticed by your average
drug-addicted street criminal on the way to score a little cash for his
next hit.

2) Amazingly, in the world of computers, those trivial changes actually
may deflect some attacks.  This shows the incredible low level of skill
these script kiddies really possess (or the number of softer targets).


If you just don't want to see evidence of people trying to twist your
doorknob, and you offer nothing more "interesting" than yet another
platform to attack from, ok, sure, some of this stuff may actually
"help" you withstand the continual attack of mindless "bots", HOWEVER,
if you really have something you are really protecting, this kind of
stuff should not be part of your security plan, as all it does is give
you a false sense of security.  None of this stuff withstands a
determined attacker.

Supposedly, when asked why he robbed banks, Willie Sutton said, "that's
where the money is".  Why do people crack computers?  Historically, it
was because "That's where the fame is".  They got in, they showed their
friends and competitors, and that was about it.  As Internet-exposed
computers get used for more business-involved tasks, the motivation is
changing to Sutton's, "that's where the money is".  Armoring yourself
believing that script kiddies and their pea-shooters, and their
ten-second attention span are your attackers is fighting a war of a few
years ago...in a business environment, you have a new enemy, someone who
doesn't want the fame of 0wn3n1ng your computer (he'd prefer not to be
noticed, in fact!), but rather, wants a copy of (or wishes to alter)
what you are protecting, and wants to profit from that.  And he's
packing a lot more than a pea-shooter, and the payoff is worth a bit of
effort on their part.

Nick.

Reply | Threaded
Open this post in threaded view
|

Re: new tool: openportd

Jan Stary
In reply to this post by Steffen Wendzel
> It is like a port knocking service but a little bit different:
>
> Normaly a port knocking service uses TCP/UDP, but openportd
> uses ICMP echo response packets because they are not so easy
> to send like echo requests or TCP/UDP port tests (kiddies could
> simply use ping or nmap for this job).
>
> You can define keys and actions in /etc/openportd.conf. If a
> key is received, an action is executed. Here are examples:
>
> 04t3904jg034 reboot
> 0987654321   pkill sshd
> 1234567890   /usr/sbin/sshd
> 40tg340503n5 pf/iptables (load some other rules or whatever)

This sounds like authpf done on a trip.
And do you really mean to kill sshd upon receiving an ICMP packet?!

Reply | Threaded
Open this post in threaded view
|

Re: new tool: openportd

Lars Hansson
In reply to this post by Steffen Wendzel-2
On Sunday 22 October 2006 22:41, you wrote:
> this isn't correct. Every service had some security problems in the
> past. Imagin that your service X is vulnerable (only since a few h
> by a zero day exploit or so) and someone tries to exploit it at 2:00 in
> the morning.
Good thing there cant be any bugs in the port knocking program, right?

> if you only need the service for administration, you could do such a
> "hiding" of the service. you only would need to open the port by the
> portknocking service a few min while you use it to do some administration.

Yeah, because running SSH and only allowing pubkey authentication or s/key
surely isn't a better solution...
Of course, thats only with SSH but I'm yet to see any other use for port
knocking than "protecting" SSH.

---
Lars Hansson