Re: Suggestion for a new feature, port code

[Johan Söderberg]

Henning Brauer  openbsd.org> writes:

> we will never let that shit even remotely close to our tree. period.

we don't need you to tell us that as that shit already works. full stop.

Re: Suggestion for a new feature, port code

[Henning Brauer]

we will never let that shit even remotely close to our tree. period.

* Johan Söderberg  [2011-03-04 15:00]:
> In my mind this is not security by obscurity, no more than one-time 
> passwords. 
> The ports can be compared to the keys of a keyboard when typing a password.
> As with passwords, the implementation is not a secret. 
> The port that is protected is not hidden, it is locked.
> It adds security and do not add attack vectors as it is implemented as a 
> simple 
> ruleset for pf, protecting sshd. It can also be combined with authpf.
> Why waste energy on spammed logs with scans and attacks, banning and luring 
> with 
> honeypots on the outside?
> Why give sshd unnecessary exposure as it may have weaknesses?
> 
> http://en.wikipedia.org/wiki/Security_through_obscurity
> http://stackoverflow.com/questions/4486171/isnt-a-password-a-form-of-security-
> through-obscurity
> http://security.stackexchange.com/questions/1194/port-knocking-is-it-a-good-idea

-- 
Henning Brauer, h...@bsws.de, henn...@openbsd.org
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting

Re: Suggestion for a new feature, port code

[Johan Söderberg]

2011/2/28, Karl O. Pinc:
> If you want it to be secure you make the knock code a ome-time-pad.

2011/3/1, me:
> If I change the knock ports every time I log in, I should be fine, right?

Nah, still vulnerable to MITM.
Just intercept and stop the knocks from reaching, and replay them yourself.
But it needs to be planned. So it's still worth changing knocks.

Re: Suggestion for a new feature, port code

[Johan Söderberg]

spamassassinexception

Thank you so much for your input!
If I change the knock ports every time I log in, I should be fine, right?
Please comment on my ruleset, brain fart again?

knock1 = "1"
knock2 = "2"
open = "22"

block drop in all

block drop quick on $extif inet proto tcp \
from any to $extaddr port $knock1 \
tag knock1

block drop quick on $extif inet proto tcp \
from any to $extaddr port != $knock2 \
tagged knock1 tag knock

block drop quick log on $extif inet proto tcp \
from any to $extaddr port $knock2 \
tagged knock1 tag knock2

block drop quick log on $extif inet proto tcp \
from any to $extaddr port != $open \
tagged knock2 tag knock

pass in quick log on $extif inet proto tcp \
from any to $extaddr port $open \
modulate state (max 1) \
tagged knock2

Re: Suggestion for a new feature, port code

[Daniel Staal]

On Mon, February 28, 2011 10:17 am, Johan Söderberg wrote:
> A ridiculously simple idea. Protect your port, say ssh, by adding a code
> to access it. Ok, that's nothing new, but maybe how it's done.
>
> For a client to connect to a service, it need to unlock the port with a
> code. The code is made of predefined blocked ports, that makes pf
> trigger. If the first code port is triggered, IP address enters a state
> with timestamp. If the next port that the address triggers, matches the
> next code port within a timeframe, let it enter new state, else lose
> state. When all code ports have been triggered in the right order, allow
>  address to pass.
>
> Sure it's not safe from MITM, but it protects from scans, and allows you
> to connect from dynamic IP addresses. There are 65536 ports, that gives
> you 65536^n possible combinations where n is the number of ports in your
> code. So you probably won't need more than 2-3 ports in your code.
>
> Say what you think! And if you like my brain fart, would you want to
> implement it?

Also known as 'Port Knocking':


I recall it was discussed here a while back.  I can't recall what the
exact arguments were, but I don't suppose it'd be hard to write a userland
daemon to implement it using anchors.

Daniel T. Staal

---
This email copyright the author.  Unless otherwise noted, you
are expressly allowed to retransmit, quote, or otherwise use
the contents for non-commercial purposes.  This copyright will
expire 5 years after the author's death, or in 30 years,
whichever is longer, unless such a period is in excess of
local copyright law.
---

Re: Suggestion for a new feature, port code

[Peter N. M. Hansteen]

Johan Söderberg  writes:

> For a client to connect to a service, it need to unlock the port with a code.
> The code is made of predefined blocked ports, that makes pf trigger.

You have just described 'port knocking'.  It's been discussed in PF
contexts before (I forget which lists, could have been openbsd-misc or
here), and the conclusion was roughly that it doesn't add much in
terms of security, certainly not worth the potential added complexity.
The enthusiasts tend to live on Linux, IIRC.

> There are 65536 ports, that gives you 65536^n possible combinations
> where n is the number of ports in your code.
> So you probably won't need more than 2-3 ports in your code.

That's almost like saying, "my password's written with unicode, so 2-3
characters is fine".  To my mind, that's all the added security you
get, roughly equivalent to a password.  It's a well known fact that
industrial-scale password guessing is going on right now, so once the
bad guys figure out the obvious, the machinery to crack your box is
ready to go. Add to that the typical implementation scenario with a
deamon that reads your firewall logs for your secret sequence and all
its possible failure modes (a full disk will brick your box, as will
any exploitable bug that with a potential to kill your daemon, and so
forth).

Oh well, that's just a small sample of what the sceptics here will
say.  I've been meaning to get around to a proper treatment of port
knocking in a blog post or article, and that may still happen given
enough round tuits.  In the meantime, the main points have already
been presented.

- Peter
-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Re: Suggestion for a new feature, port code

[Kelley Reynolds]

A quick google on 'pf port knocking' turned up the following that might be of 
interest.

http://www.lazyscripter.com/2010/04/port-knocking-with-pf/


On Feb 28, 2011, at 10:17 AM, Johan Söderberg wrote:

> A ridiculously simple idea.
> Protect your port, say ssh, by adding a code to access it.
> Ok, that's nothing new, but maybe how it's done.
> 
> For a client to connect to a service, it need to unlock the port with a code.
> The code is made of predefined blocked ports, that makes pf trigger.
> If the first code port is triggered, IP address enters a state with timestamp.
> If the next port that the address triggers, matches the next code port
> within a timeframe, let it enter new state, else lose state.
> When all code ports have been triggered in the right order, allow
> address to pass.
> 
> Sure it's not safe from MITM, but it protects from scans, and allows
> you to connect from dynamic IP addresses.
> There are 65536 ports, that gives you 65536^n possible combinations
> where n is the number of ports in your code.
> So you probably won't need more than 2-3 ports in your code.
> 
> Say what you think! And if you like my brain fart, would you want to
> implement it?
> 
> Kind regards, Johan Söderberg

Re: Suggestion for a new feature, port code

[Karl O. Pinc]

On 02/28/2011 09:17:25 AM, Johan Söderberg wrote:
> A ridiculously simple idea.
> Protect your port, say ssh, by adding a code to access it.
> Ok, that's nothing new, but maybe how it's done.
> 
> For a client to connect to a service, it need to unlock the port with
> a code.
> The code is made of predefined blocked ports, that makes pf trigger.
> If the first code port is triggered, IP address enters a state with
> timestamp.
> If the next port that the address triggers, matches the next code 
> port
> within a timeframe, let it enter new state, else lose state.
> When all code ports have been triggered in the right order, allow
> address to pass.
> 
> Sure it's not safe from MITM, but it protects from scans, and allows
> you to connect from dynamic IP addresses.
> There are 65536 ports, that gives you 65536^n possible combinations
> where n is the number of ports in your code.
> So you probably won't need more than 2-3 ports in your code.
> 
> Say what you think! And if you like my brain fart, would you want to
> implement it?

Your idea is called port knocking, and it's pointless security by
obscurity -- and can be sniffed.  If you want it to be 
secure you make the knock code a
ome-time-pad.  In which case you may as well use skey for your
one-time-pad and be done with it.

If you want to "protect the port" redirect repeat offenders off
into a honeypot.

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Suggestion for a new feature, port code

[Johan Söderberg]

A ridiculously simple idea.
Protect your port, say ssh, by adding a code to access it.
Ok, that's nothing new, but maybe how it's done.

For a client to connect to a service, it need to unlock the port with a code.
The code is made of predefined blocked ports, that makes pf trigger.
If the first code port is triggered, IP address enters a state with timestamp.
If the next port that the address triggers, matches the next code port
within a timeframe, let it enter new state, else lose state.
When all code ports have been triggered in the right order, allow
address to pass.

Sure it's not safe from MITM, but it protects from scans, and allows
you to connect from dynamic IP addresses.
There are 65536 ports, that gives you 65536^n possible combinations
where n is the number of ports in your code.
So you probably won't need more than 2-3 ports in your code.

Say what you think! And if you like my brain fart, would you want to
implement it?

Kind regards, Johan Söderberg

Re: New Feature(s) Ideas

[Stanislaw Halik]

On Wed, Dec 20, 2006, Rob wrote:
> It seems that the memory limitations related to the current table
> implementation are due to the fact that all the records are stored in
> memory [...]

> The second more outlandish feature I call "The Decider" which would be
> similar to read only tables but would communicate with an external
> program

Neither of these is feasible for the kernel land, where pf resides.

-- 
Unix stuff  :: http://tehran.lain.pl
Yet Another RBL :: http://rbl.lain.pl

Re: New Feature(s) Ideas

[Travis H.]

On Wed, Dec 20, 2006 at 10:24:16AM -0800, Rob wrote:
> I'd like to get some feedback on the feasibility of some new features for pf
> and the feasibility of them being implemented by the current pf hackers.
> 
> For large table support, what do people think of the idea of "read only" 
> external tables. For instance, using CDB

Interesting... I can't think of an example where I'd want a large high-speed
table that rarely changes, but I'm sure they exist.

> The second more outlandish feature I call "The Decider" which would be 
> similar to read only tables but would communicate with an external program
> which could use more complex criteria to decide if that packet was part of
> the dynamic table or not.
> Basically, a process driven dynamic table lookup:
> 
> decider  127.0.0.1:2727 400ms:no
> 
> block drop quick log on $ext_if from {}
> 
> pf would pass the packet details and the parameter after the decider_name:
> and would get a yes/no response, maybe an optional timeout is included in 
> the decider
> declaration and if it is exceeded it defaults to whatever is specified.
> Of course, this would be painfully slow and when misused would cause people
> to bitch about pf being slow.

I have no idea if pf can hang onto a packet, especially incoming, long enough
for a call to userland, but I think anything we can do to make pf more
flexible (or to reduce the need to be skilled in kernelspace coding) would
be beneficial.

Another alternative is to upload the code into kernelspace into a sandbox.
If people are interested in this, it can be done with x86 code by re-writing
and incurs something like a < 20% penalty.  The paper describing this won
best paper award recently by Usenix.
-- 
A: No.
Q: Should I include quotations after my reply?
http://www.subspacefield.org/~travis/> -><-


pgp4ZhmHrmVyo.pgp
Description: PGP signature

New Feature(s) Ideas

[Rob]

I'd like to get some feedback on the feasibility of some new features for pf
and the feasibility of them being implemented by the current pf hackers.

For large table support, what do people think of the idea of "read only" 
external
tables. For instance, using CDB [http://www.corpit.ru/mjt/tinycdb.html is a pd
implementation of djb's cdb (since the license for the original wouldn't be 
acceptable)]
or perhaps Judy arrays http://judy.sourceforge.net/ [but this is LGPL] ?

It seems that the memory limitations related to the current table 
implementation are
due to the fact that all the records are stored in memory and statistics are 
maintained
for each entry. Similar stats (except for aging) can be had by using a separate 
rule
for each table and using the per rule stats:

table  persist file "/etc/ssh_brutes.txt"  {}
table  persist file "/etc/bogons-cidr-all.txt" {}
table  persist file "/etc/spammers.txt"  {}

block drop quick log on $ext_if from {}
block drop quick log on $ext_if proto icmp from {}
block drop quick log on $ext_if proto udp from {}
block drop quick log on $ext_if proto tcp from {} to port != 25
block drop quick log on $ext_if from {}

@0 block drop log quick on dc0 from  to any
  [ Evaluations: 1415858   Packets: 414   Bytes: 24376   States: 0 ]
@1 block drop log quick on dc0 proto icmp from  to any
  [ Evaluations: 315126Packets: 0 Bytes: 0   States: 0 ]
@2 block drop log quick on dc0 proto udp from  to any
  [ Evaluations: 302219Packets: 12Bytes: 936 States: 0 ]
@3 block drop log quick on dc0 proto tcp from  to any port != 
smtp
  [ Evaluations: 13587 Packets: 362   Bytes: 18469   States: 0 ]
@4 block drop log quick on dc0 from  to any
  [ Evaluations: 314752Packets: 0 Bytes: 0   States: 0 ]

By eliminating the need to maintain age/stats on individual entries, the read 
only table
feature can use efficient in memory structures, files, databases, etc for a 
simple lookup
but not use the memory required for tracking active table entries. Something 
like:

table  ro cdb "/etc/sshbrutefrc.cdb"

Obviously, then all aging and maintenance of the table would fall to external 
programs.

The second more outlandish feature I call "The Decider" which would be similar 
to
read only tables but would communicate with an external program which could use 
more
complex criteria to decide if that packet was part of the dynamic table or not.
Basically, a process driven dynamic table lookup:

decider  127.0.0.1:2727 400ms:no

block drop quick log on $ext_if from {}

pf would pass the packet details and the parameter after the decider_name:
and would get a yes/no response, maybe an optional timeout is included in the 
decider
declaration and if it is exceeded it defaults to whatever is specified.
Of course, this would be painfully slow and when misused would cause people
to bitch about pf being slow.

Thanks for any ideas/feedback.

Re: new feature

[Jon Simola]

On Fri, 28 Jan 2005 10:37:44 -0800, Gustavo A. Baratto
<[EMAIL PROTECTED]> wrote:

> Is it (or will be) possible to set different state timeouts for different
> rules?

Like this?
pass in  on vlan101 from vlan101:network to any keep state (max 5000,
source-track rule, max-src-states 50, tcp.established 60, tcp.closing
5)

Re: new feature

[Jason Opperisano]

On Fri, Jan 28, 2005 at 10:37:44AM -0800, Gustavo A. Baratto wrote:
> hello all,
> 
> Is it (or will be) possible to set different state timeouts for different 
> rules?
> 
> For example, if I'm using http, and I need to keep the state for 10 minutes 
> because of an e-commerce session, and I dont want to keep the state for 
> smtp for more than 30 seconds.
> 
> Something like:
> -
> set timeout 60  #default timeout
> 
> # http rule
> pass out on fxp0 proto tcp from any to any port www keep state timeout 600
> 
> # smtp rule
> pass out on fxp0 proto tcp from any to any port smtp keep state timeout 30

you can do that today:

  pass out on fxp0 proto tcp from any to any port = www \
keep state (tcp.established 600)

  pass out on fxp0 proto tcp from any to any port = smtp \
keep state (tcp.established 30)

man 5 pf.conf for more details.

-j

--
"Asleep at the switch?  I wasn't asleep, I was drunk!"
--The Simpsons

new feature

[Gustavo A. Baratto]

hello all,
Is it (or will be) possible to set different state timeouts for different 
rules?

For example, if I'm using http, and I need to keep the state for 10 minutes 
because of an e-commerce session, and I dont want to keep the state for smtp 
for more than 30 seconds.

Something like:
-
set timeout 60  #default timeout
# http rule
pass out on fxp0 proto tcp from any to any port www keep state timeout 600
# smtp rule
pass out on fxp0 proto tcp from any to any port smtp keep state timeout 30

Cheers ;)