Request to change /etc/pf.conf default permissions from 755 to 600.
This will prevent local user or webscript attacker to read PF ruleset.
Note that at the moment this is the only way a normal user could gather
information on PF ruleset, infact using pfctl need root permissions to open
/dev/pf.
Request to modify PF skip-steps code to upgrade to magic-jumps
Currently PF uses skip-steps to move towards rules that couldn't match.
It uses to look for the next rule with a different value for the option that
didn't match.
Example:
1) pass in quick on rl0 inet proto tcp from $ip1 port 80 to a
Hello,
> I was recently pointed to a paper on the internet that talked about the
> speed improvments of iptables vs pf. UNfortunatelly the paper is no
> longer there. The paper was linked from deadly.org here
> http://www.deadly.org/article.php3?sid=20020617203813
I think you are talking about t
On Wed, Feb 05, 2003 at 07:28:24PM +0100, Ed White wrote:
> Request to change /etc/pf.conf default permissions from 755 to 600.
>
> This will prevent local user or webscript attacker to read PF ruleset.
> Note that at the moment this is the only way a normal user could gather
> information on PF
Hey,
"A Technique for Counting NATted Hosts", Steven M. Bellovin
http://www.research.att.com/~smb/papers/fnat.pdf
Section IV Privacy and correctness issues suggest the following:
* The simplest case, though, is if the DF (Don't Fragment) bit is set in
the IP header of the incoming packet. In such
On Thu, 6 Feb 2003, jolan wrote:
> On Thu, Feb 06, 2003 at 12:33:25AM +0100, Dries Schellekens wrote:
> > * Using a random IPidfield has its own challenges to uniqueness. While
> > linear congruential generators have a maximal cycle length, such
> > generators are easily cryptanalyzed. A keyed gen
On Thu, Feb 06, 2003 at 11:15:22AM +0100, Dries Schellekens wrote:
> benzedrine.cx was temporary unreachable. The problem seems to be solved
> now (because this mailing list seems to work again).
Wednesday 6:15pm, uplink dies. Router says PPP authentication fails. Of
course, all staff of the 'ISP
On Thu, Feb 06, 2003 at 11:15:22AM +0100, Dries Schellekens wrote:
>[...] but iptable doesn't do proper
> statefull firewalling. [...]
Any info/URL about that ?
przemol
On Thu, Feb 06, 2003 at 01:12:37PM +0100, [EMAIL PROTECTED] wrote:
> Any info/URL about that ?
http://www.sns.ias.edu/~jns/security/iptables/iptables_conntrack.html
http://www.netfilter.org/documentation/HOWTO/netfilter-extensions-HOWTO-5.html#ss5.10
http://marc.theaimsgroup.com/?l=netfilter-deve
On Thu, Feb 06, 2003 at 01:09:01PM +0100, Ed White wrote:
> Obviously adding checks will slow down the whole thing, but IMHO it's better a
> higher time for optimizing, that's made before using a ruleset, if it brings
> better performance every time a packet is evaluated.
> This will be felt by
On Thursday 06 February 2003 11:29, Daniel Hartmeier wrote:
> The question is whether it's worth the additional cost of trying to jump
> further down. I did benchmarks with other versions, like evaluating all
> parameters of the rule (not aborting on the first mismatch), then
> finding the largest
On Thu, 2003-02-06 at 13:20, Daniel Hartmeier wrote:
> On Thu, Feb 06, 2003 at 01:12:37PM +0100, [EMAIL PROTECTED] wrote:
>
> > Any info/URL about that ?
>
> http://www.sns.ias.edu/~jns/security/iptables/iptables_conntrack.html
> http://www.netfilter.org/documentation/HOWTO/netfilter-extensions-H
On Thursday 06 February 2003 11:14, jolan wrote:
> if you have users and a running http daemon with scripts capable of
> reading system wide files on your firewall, i think you have bigger
> problems to worry about.
I'm not talking about a firewall setup only.
Think at a classic webserver with Apa
On Thu, Feb 06, 2003 at 01:17:24PM +0100, Ed White wrote:
> However the fact is that I would like OpenBSD to be careful at details like
> this.
> If most root/admin manually change this permission, why don't make it by
> default ?
There are many other places for more restrictive permissions by d
On Thu, Feb 06, 2003 at 01:42:45PM +0100, Emmanuel Fleury wrote:
> But, I wonder why they are faster than pf !
> Because, there is no obvious relation between the fact that pf is more
> secure and the fact that it is slow (I might be wrong!!!).
You can't really use the pf paper and come to this c
On Thu, Feb 06, 2003 at 01:42:45PM +0100, Emmanuel Fleury wrote:
> But, I wonder why they are faster than pf !
> Because, there is no obvious relation between the fact that pf is more
> secure and the fact that it is slow (I might be wrong!!!).
pf is not close to beeing slow. in fact, it's bleedin
On Thu, 2003-02-06 at 14:13, Daniel Hartmeier wrote:
>
> You can't really use the pf paper and come to this conclusion. It's
> mostly brought up by people who didn't read the text but were looking
> only at the graphs.
>
> The text explains what the two test consisted of exactly, and what
> reaso
On Thu, Feb 06, 2003 at 03:22:35PM +0100, Emmanuel Fleury wrote:
> Stateful is not a solution because it introduces a strong flaw inside
> your firewall... The connection table (used to remember the state of
> each connection) is using a limited ressource of the kernel: memory.
this is pretty irre
On Thu, 2003-02-06 at 15:37, Henning Brauer wrote:
>
> of course, "optimized representation" is such a meaningless word that
> everything can be claimed to fit ;-)
I was meaning this sort of representation:
http://www.brics.dk/RS/02/43/BRICS-RS-02-43.ps.gz
Regards
--
Emmanuel Fleury
Computer Sc
On Thu, Feb 06, 2003 at 03:22:35PM +0100, Emmanuel Fleury wrote:
> What are the arguments in favor of having two separate interfaces better
> than one forward chain ?
It gives the admin more options to express a filter policy. You can
decide what interfaces a forwarded connection may arrive in th
On Thu, 2003-02-06 at 08:09, Henning Brauer wrote:
> On Thu, Feb 06, 2003 at 01:42:45PM +0100, Emmanuel Fleury wrote:
> > But, I wonder why they are faster than pf !
> > Because, there is no obvious relation between the fact that pf is more
> > secure and the fact that it is slow (I might be wrong!
On Thu, 2003-02-06 at 06:19, Dries Schellekens wrote:
> OpenBSD hosts use random IPids. But PF doesn't rewrite IPids when NATting.
> So hosts behind the NAT (running a different OS) will not have randomized
> IPids and thus this counting trick will detect these hosts.
It's my understanding that t
On Thu, 6 Feb 2003, Daniel Hartmeier wrote:
> > Stateful is not a solution because it introduces a strong flaw inside
> > your firewall... The connection table (used to remember the state of
> > each connection) is using a limited ressource of the kernel: memory.
>
> Of course. See
>
> http://ww
On Thu, Feb 06, 2003 at 07:05:26PM +0100, Dries Schellekens wrote:
> Does PF protect against the "Crikey CRC Flood" (described in
> http://www.kb.cert.org/vuls/id/539363)? I know that protection against
> p60-0x0c.txt was add; does this protect against this C2 Flood as well?
A "C2 flood" is nothi
Hello,
Can I change IP-Header Options, or filter based on them? I have not
found any point about that in the current man page, so I belive it's not
possible.
Is it a good idea to filter packages, as a example with "source routing",
or is it not nessesary and I ask a stupid question?
Thanks and
Maik Kuendig wrote:
Is it a good idea to filter packages, as a example with "source routing",
or is it not nessesary and I ask a stupid question?
I personally would *love* to be able to use PF to *insert* source routing
on some outgoing packets
Cedric
On Thu, Feb 06, 2003 at 08:53:26AM -0500, Jason Dixon wrote:
> On Thu, 2003-02-06 at 08:09, Henning Brauer wrote:
> > On Thu, Feb 06, 2003 at 01:42:45PM +0100, Emmanuel Fleury wrote:
> > > But, I wonder why they are faster than pf !
> > > Because, there is no obvious relation between the fact that
Hallo
Cedric Berger <[EMAIL PROTECTED]> schrieb:
> >Is it a good idea to filter packages, as a example with "source routing",
> >or is it not nessesary and I ask a stupid question?
> I personally would *love* to be able to use PF to *insert* source routing
> on some outgoing packets
May on
If what you are looking for is to have PF block source-routed packets,
there's an easy solution. OpenBSD has a sysctl option which can be set
to allow or disallow routing of source-routed packets.
Maik Kuendig wrote:
Hello,
Can I change IP-Header Options, or filter based on them? I have no
> i have a good idea, how about an obfuscated pf.conf contest?
I have a better idea. How about an unobfuscated pf.conf contest.
Clearest ruleset style wins. I'll buy the beer.
-kj
On Thu, Feb 06, 2003 at 09:23:06PM +0100, Maik Kuendig wrote:
> Can I change IP-Header Options, or filter based on them? I have not
> found any point about that in the current man page, so I belive it's not
> possible.
By default, pf blocks all packets with IP options. You can pass them per
rule
On Thu, 6 Feb 2003, Daniel Hartmeier wrote:
> On Thu, Feb 06, 2003 at 07:05:26PM +0100, Dries Schellekens wrote:
>
> > Does PF protect against the "Crikey CRC Flood" (described in
> > http://www.kb.cert.org/vuls/id/539363)? I know that protection against
> > p60-0x0c.txt was add; does this protect
32 matches
Mail list logo
