On Wed, Jul 28, 1999 at 04:17:57PM -0400, Brian F. Feldman wrote:
> > Brian, FreeBSD isn't your private playground for playing around, this is
> > a group project, and you gotta follow the rules, or you don't get to
> > play with the rest of the folks
>
> The rules don't say "leave the code th
On Wed, Jul 28, 1999 at 04:17:57PM -0400, Brian F. Feldman wrote:
> > Brian, FreeBSD isn't your private playground for playing around, this is
> > a group project, and you gotta follow the rules, or you don't get to
> > play with the rest of the folks
>
> The rules don't say "leave the code t
:On Wed, 28 Jul 1999, Nate Williams wrote:
:> >
:> > These were changes that were necessary to make ipfw readable enough that
:> > I could work with it in this area. They aren't just to clean it up, or
:> > just for change's sake. They need to stay in.
:>
:> C'mon now, re-ording the lines is *cer
:On Wed, 28 Jul 1999, Nate Williams wrote:
:> >
:> > These were changes that were necessary to make ipfw readable enough that
:> > I could work with it in this area. They aren't just to clean it up, or
:> > just for change's sake. They need to stay in.
:>
:> C'mon now, re-ording the lines is *ce
:> The code is *NO* more readable by you re-ordering lines and changes
:> whitespace.
:...
:
:.
Sounds like one of many arguments I've had with various people
who insist on nitpicking and critiqing to death tiny little
itsy bitsy inconsistancies that no normal person would car
On Wed, Jul 28, 1999 at 02:40:19PM -0600, Nate Williams wrote:
>
> Or is this Linux, where we don't give a rip and whatever the current
> patch does to the rest of the tree is fine, since the more code we have
> the better?
Nate, you know damn well that's not true. You're complaining about
three
On Wed, Jul 28, 1999 at 02:42:35PM -0600, Nate Williams wrote:
>
> The code is *NO* more readable by you re-ordering lines and changes
> whitespace.
It's white!
No, dammit, it's beige!
Fuck you, I said it's white!
Beige!
White!
I dunno, I guess for some people the distinction's actually
mea
:> The code is *NO* more readable by you re-ordering lines and changes
:> whitespace.
:...
:
:.
Sounds like one of many arguments I've had with various people
who insist on nitpicking and critiqing to death tiny little
itsy bitsy inconsistancies that no normal person would ca
On Wed, Jul 28, 1999 at 02:40:19PM -0600, Nate Williams wrote:
>
> Or is this Linux, where we don't give a rip and whatever the current
> patch does to the rest of the tree is fine, since the more code we have
> the better?
Nate, you know damn well that's not true. You're complaining about
thre
On Wed, Jul 28, 1999 at 02:42:35PM -0600, Nate Williams wrote:
>
> The code is *NO* more readable by you re-ordering lines and changes
> whitespace.
It's white!
No, dammit, it's beige!
Fuck you, I said it's white!
Beige!
White!
I dunno, I guess for some people the distinction's actually
me
> > > > In particular, the changes I pointed out are not 'cleanups', but style
> > > > changes.
> > >
> > > When you make code readable, it's a cleanup.
> >
> > The code is *NO* more readable by you re-ordering lines and changes
> > whitespace.
>
> This is so very objective.
That's why it consi
On Wed, 28 Jul 1999, Nate Williams wrote:
> > > > > > These were changes that were necessary to make ipfw readable enough
> > > > > > that
> > > > > > I could work with it in this area. They aren't just to clean it up,
> > > > > > or
> > > > > > just for change's sake. They need to stay in.
> >
On Wed, 28 Jul 1999, Nate Williams wrote:
> > > > *rant on*
> > > > Brian, FreeBSD isn't your private playground for playing around, this is
> > > > a group project, and you gotta follow the rules, or you don't get to
> > > > play with the rest of the folks
> > >
> > > The rules don't say "le
> > > > > These were changes that were necessary to make ipfw readable enough
> > > > > that
> > > > > I could work with it in this area. They aren't just to clean it up, or
> > > > > just for change's sake. They need to stay in.
> > > >
> > > > C'mon now, re-ording the lines is *certainly* not n
> > > *rant on*
> > > Brian, FreeBSD isn't your private playground for playing around, this is
> > > a group project, and you gotta follow the rules, or you don't get to
> > > play with the rest of the folks
> >
> > The rules don't say "leave the code that you work with in a bigger mess than
>
On Wed, 28 Jul 1999, Nate Williams wrote:
> > > > These were changes that were necessary to make ipfw readable enough that
> > > > I could work with it in this area. They aren't just to clean it up, or
> > > > just for change's sake. They need to stay in.
> > >
> > > C'mon now, re-ording the line
On Wed, 28 Jul 1999, Brian F. Feldman wrote:
> On Wed, 28 Jul 1999, Nate Williams wrote:
> > >
> > > These were changes that were necessary to make ipfw readable enough that
> > > I could work with it in this area. They aren't just to clean it up, or
> > > just for change's sake. They need to sta
> > > These were changes that were necessary to make ipfw readable enough that
> > > I could work with it in this area. They aren't just to clean it up, or
> > > just for change's sake. They need to stay in.
> >
> > C'mon now, re-ording the lines is *certainly* not necessary to work.
>
> That's t
On Wed, 28 Jul 1999, Nate Williams wrote:
> >
> > These were changes that were necessary to make ipfw readable enough that
> > I could work with it in this area. They aren't just to clean it up, or
> > just for change's sake. They need to stay in.
>
> C'mon now, re-ording the lines is *certainly*
> > > > In particular, the changes I pointed out are not 'cleanups', but style
> > > > changes.
> > >
> > > When you make code readable, it's a cleanup.
> >
> > The code is *NO* more readable by you re-ordering lines and changes
> > whitespace.
>
> This is so very objective.
That's why it cons
> > > @@ -302,14 +303,15 @@
> > > struct ifnet *rif, struct ifnet *oif)
> > > {
> > > if (ip) {
> > > + struct tcphdr *const tcp = (struct tcphdr *)((u_int32_t *)ip+ip->ip_hl);
> > > + struct udphdr *const udp = (struct udphdr *)((u_int32_t *)ip+ip->ip_hl);
> > > + struct icmp *const icmp =
On Wed, 28 Jul 1999, Nate Williams wrote:
> > Index: src/sys/netinet/ip_fw.c
> > ===
> > RCS file: /home/ncvs/src/sys/netinet/ip_fw.c,v
> > retrieving revision 1.114
> > diff -u -r1.114 ip_fw.c
> > --- ip_fw.c 1999/06/19 18:43:28
On Wed, 28 Jul 1999, Nate Williams wrote:
> > > > > > These were changes that were necessary to make ipfw readable enough that
> > > > > > I could work with it in this area. They aren't just to clean it up, or
> > > > > > just for change's sake. They need to stay in.
> > > > >
> > > > > C'mon no
> Index: src/sys/netinet/ip_fw.c
> ===
> RCS file: /home/ncvs/src/sys/netinet/ip_fw.c,v
> retrieving revision 1.114
> diff -u -r1.114 ip_fw.c
> --- ip_fw.c 1999/06/19 18:43:28 1.114
> +++ ip_fw.c 1999/07/28 06:29:07
> @@ -106,6
I need help finishing it. The ipfw.8 manpage isn't quite fixed yet. When
someone will do that, it will be Ready :) But I've attached it!
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
gr...@freebsd.org _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!
On Wed, 28 Jul 1999, Nate Williams wrote:
> > > > *rant on*
> > > > Brian, FreeBSD isn't your private playground for playing around, this is
> > > > a group project, and you gotta follow the rules, or you don't get to
> > > > play with the rest of the folks
> > >
> > > The rules don't say "l
> > > > > These were changes that were necessary to make ipfw readable enough that
> > > > > I could work with it in this area. They aren't just to clean it up, or
> > > > > just for change's sake. They need to stay in.
> > > >
> > > > C'mon now, re-ording the lines is *certainly* not necessary t
> > > *rant on*
> > > Brian, FreeBSD isn't your private playground for playing around, this is
> > > a group project, and you gotta follow the rules, or you don't get to
> > > play with the rest of the folks
> >
> > The rules don't say "leave the code that you work with in a bigger mess than
On Wed, 28 Jul 1999, Nate Williams wrote:
> > > > These were changes that were necessary to make ipfw readable enough that
> > > > I could work with it in this area. They aren't just to clean it up, or
> > > > just for change's sake. They need to stay in.
> > >
> > > C'mon now, re-ording the lin
On Wed, 28 Jul 1999, Brian F. Feldman wrote:
> On Wed, 28 Jul 1999, Nate Williams wrote:
> > >
> > > These were changes that were necessary to make ipfw readable enough that
> > > I could work with it in this area. They aren't just to clean it up, or
> > > just for change's sake. They need to st
> > > > Implementing it is the easy part, making sure it's the right thing to do
> > > > is the hard part.
> > >
> > > Well, the easy part is done, except for raising limits. Look:
> > > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0
> > > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via l
On Wed, 28 Jul 1999, Nate Williams wrote:
> > > Implementing it is the easy part, making sure it's the right thing to do
> > > is the hard part.
> >
> > Well, the easy part is done, except for raising limits. Look:
> > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0
> > ipfw: 1 Deny ICMP:8.
> > > These were changes that were necessary to make ipfw readable enough that
> > > I could work with it in this area. They aren't just to clean it up, or
> > > just for change's sake. They need to stay in.
> >
> > C'mon now, re-ording the lines is *certainly* not necessary to work.
>
> That's
On Wed, 28 Jul 1999, Nate Williams wrote:
> >
> > These were changes that were necessary to make ipfw readable enough that
> > I could work with it in this area. They aren't just to clean it up, or
> > just for change's sake. They need to stay in.
>
> C'mon now, re-ording the lines is *certainly
> > > @@ -302,14 +303,15 @@
> > > struct ifnet *rif, struct ifnet *oif)
> > > {
> > > if (ip) {
> > > + struct tcphdr *const tcp = (struct tcphdr *)((u_int32_t *)ip+ip->ip_hl);
> > > + struct udphdr *const udp = (struct udphdr *)((u_int32_t *)ip+ip->ip_hl);
> > > + struct icmp *const icmp
On Tue, 27 Jul 1999, Brian F. Feldman wrote:
> If it will get ALL of you to give it a rest, how about:
> per-rule logging limits
This has been needed for some time now. Also, please don't forget
the oft-repeated request to have seperate accounting and logging counters
so that you ca
On Wed, 28 Jul 1999, Nate Williams wrote:
> > Index: src/sys/netinet/ip_fw.c
> > ===
> > RCS file: /home/ncvs/src/sys/netinet/ip_fw.c,v
> > retrieving revision 1.114
> > diff -u -r1.114 ip_fw.c
> > --- ip_fw.c 1999/06/19 18:43:28
> Index: src/sys/netinet/ip_fw.c
> ===
> RCS file: /home/ncvs/src/sys/netinet/ip_fw.c,v
> retrieving revision 1.114
> diff -u -r1.114 ip_fw.c
> --- ip_fw.c 1999/06/19 18:43:28 1.114
> +++ ip_fw.c 1999/07/28 06:29:07
> @@ -106,
I need help finishing it. The ipfw.8 manpage isn't quite fixed yet. When
someone will do that, it will be Ready :) But I've attached it!
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
[EMAIL PROTECTED] _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!
> > > > Implementing it is the easy part, making sure it's the right thing to do
> > > > is the hard part.
> > >
> > > Well, the easy part is done, except for raising limits. Look:
> > > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0
> > > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via
On Wed, 28 Jul 1999, Nate Williams wrote:
> > > Implementing it is the easy part, making sure it's the right thing to do
> > > is the hard part.
> >
> > Well, the easy part is done, except for raising limits. Look:
> > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0
> > ipfw: 1 Deny ICMP:8
On Tue, 27 Jul 1999, Brian F. Feldman wrote:
> If it will get ALL of you to give it a rest, how about:
> per-rule logging limits
This has been needed for some time now. Also, please don't forget
the oft-repeated request to have seperate accounting and logging counters
so that you c
> > Implementing it is the easy part, making sure it's the right thing to do
> > is the hard part.
>
> Well, the easy part is done, except for raising limits. Look:
> ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0
> ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0
> ipfw: limit 2 reach
> And then ... securelevel == 3 I think it is better NOT to permit
> 'sysctl -w', 'ipfw *' AND a logging limmit, just process the logfile
> faster to avoid DoS
The real issue we are dealing with is what happens at securelevel == 3.
What you are saying is that people shouldn't be allowed to modify
On Tue, 27 Jul 1999, Julian Elischer wrote:
> a system wide limit and each rule's logging counter individually resetable
> back to 0.
> > So, what's your vote?
> > ... Joe
I vote for this too.
Henk.
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the
On Wed, 28 Jul 1999, Brian F. Feldman wrote:
> > > If it will get ALL of you to give it a rest, how about:
> > > per-rule logging limits
> > > logging limit raising
> > > logging limit resetting
> > > Which would all NOT affect the statistics?
Separate statistics/logging counters is fine, b
> > Implementing it is the easy part, making sure it's the right thing to do
> > is the hard part.
>
> Well, the easy part is done, except for raising limits. Look:
> ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0
> ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0
> ipfw: limit 2 reac
> And then ... securelevel == 3 I think it is better NOT to permit
> 'sysctl -w', 'ipfw *' AND a logging limmit, just process the logfile
> faster to avoid DoS
The real issue we are dealing with is what happens at securelevel == 3.
What you are saying is that people shouldn't be allowed to modify
On Tue, 27 Jul 1999, Julian Elischer wrote:
> a system wide limit and each rule's logging counter individually resetable
> back to 0.
> > So, what's your vote?
> > ... Joe
I vote for this too.
Henk.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the bod
On Wed, 28 Jul 1999, Brian F. Feldman wrote:
> > > If it will get ALL of you to give it a rest, how about:
> > > per-rule logging limits
> > > logging limit raising
> > > logging limit resetting
> > > Which would all NOT affect the statistics?
Separate statistics/logging counters is fine,
On Tue, 27 Jul 1999, Nate Williams wrote:
> > If it will get ALL of you to give it a rest, how about:
> > per-rule logging limits
> > logging limit raising
> > logging limit resetting
> > Which would all NOT affect the statistics?
>
> We need more input from people who use the code, t
On Tue, 27 Jul 1999, Nate Williams wrote:
> > If it will get ALL of you to give it a rest, how about:
> > per-rule logging limits
> > logging limit raising
> > logging limit resetting
> > Which would all NOT affect the statistics?
>
> We need more input from people who use the code,
> If it will get ALL of you to give it a rest, how about:
> per-rule logging limits
> logging limit raising
> logging limit resetting
> Which would all NOT affect the statistics?
We need more input from people who use the code, to make sure they don't
depend on the current 'featu
> If it will get ALL of you to give it a rest, how about:
> per-rule logging limits
> logging limit raising
> logging limit resetting
> Which would all NOT affect the statistics?
We need more input from people who use the code, to make sure they don't
depend on the current 'feat
If it will get ALL of you to give it a rest, how about:
per-rule logging limits
logging limit raising
logging limit resetting
Which would all NOT affect the statistics?
I am, yes, suggesting I will implement it.
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
If it will get ALL of you to give it a rest, how about:
per-rule logging limits
logging limit raising
logging limit resetting
Which would all NOT affect the statistics?
I am, yes, suggesting I will implement it.
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
> I'd like to see people other than you, I, and Matt discussing this.
> Other people who use this feature of IPFW that have an opinion one way
> or the other should speak up.
I must admit being a bad boy - I'm using ipfw for firewalling and
accounting: "log" rules for catching bad guys (and I'm no
a system wide limit and each rule's logging counter individually resetable
back to 0.
On Tue, 27 Jul 1999, Joe Greco wrote:
>
> 1) Set a global VERBOSE_LIMIT mechanism and:
> a) allow your logging counter to be reset, or
> b) allow your limit to be raised to re-enable logging
> 2
> > > > > Again, it's not a fix, it's a feature. Not being able to mess with
> > > > > counters (logging or otherwise) is a feature. It may be a feature
> > > > > that
> > >
> > > > > you can do without, but that decision is not to be made lightly.
> > > >
> >
> > > > Again, it's not a fix, it's a feature. Not being able to mess with
> > > > counters (logging or otherwise) is a feature. It may be a feature that
> >
> > > > you can do without, but that decision is not to be made lightly.
> > >
> > > I'm _saying_ to cr
> > > Again, it's not a fix, it's a feature. Not being able to mess with
> > > counters (logging or otherwise) is a feature. It may be a feature that
>
> > > you can do without, but that decision is not to be made lightly.
> >
> > I'm _saying_ to create a compl
> > > > I like the ability at secure level 3 to only reset the counters
> > > > forward..
> > > > It fits in with such things as the "append only" flag.
> > >
> > > Then we'd have to implement per-rule counters that default to
> > > IPFW_VERBOSE_LIMIT but that could be changed to anything. That'
> > Again, it's not a fix, it's a feature. Not being able to mess with
> > counters (logging or otherwise) is a feature. It may be a feature that
> > you can do without, but that decision is not to be made lightly.
>
> I'm _saying_ to create a completely separa
> > > > > One could argue that accounting numbers in a firewall shouldn't be
> > > > > trusted, but I won't argue that point since the firewall is often the
> > > > > most 'natural' place to stick network accounting software.
> > > >
> > > > If you can't trust something in the kernel, then you jus
> I'd like to see people other than you, I, and Matt discussing this.
> Other people who use this feature of IPFW that have an opinion one way
> or the other should speak up.
I must admit being a bad boy - I'm using ipfw for firewalling and
accounting: "log" rules for catching bad guys (and I'm n
a system wide limit and each rule's logging counter individually resetable
back to 0.
On Tue, 27 Jul 1999, Joe Greco wrote:
>
> 1) Set a global VERBOSE_LIMIT mechanism and:
> a) allow your logging counter to be reset, or
> b) allow your limit to be raised to re-enable logging
>
> > > I like the ability at secure level 3 to only reset the counters forward..
> > > It fits in with such things as the "append only" flag.
> >
> > Then we'd have to implement per-rule counters that default to
> > IPFW_VERBOSE_LIMIT but that could be changed to anything. That's a very
> > differ
> > > > One could argue that accounting numbers in a firewall shouldn't be
> > > > trusted, but I won't argue that point since the firewall is often the
> > > > most 'natural' place to stick network accounting software.
> > >
> > > If you can't trust something in the kernel, then you just can't tr
> > > > > Again, it's not a fix, it's a feature. Not being able to mess with
> > > > > counters (logging or otherwise) is a feature. It may be a feature that
> > >
> > > > > you can do without, but that decision is not to be made lightly.
> > > >
> > > > I'm _
> > > > Again, it's not a fix, it's a feature. Not being able to mess with
> > > > counters (logging or otherwise) is a feature. It may be a feature that
> >
> > > > you can do without, but that decision is not to be made lightly.
> > >
> > > I'm _saying_ to c
> > > Again, it's not a fix, it's a feature. Not being able to mess with
> > > counters (logging or otherwise) is a feature. It may be a feature that
>
> > > you can do without, but that decision is not to be made lightly.
> >
> > I'm _saying_ to create a comp
> > > How do you figure? Currently, the kernel will quit 'logging' denied
> > > packets when the counter reaches a specific (compiled-in) number.
> > ^
> > Then what is
> >
> > net.inet.ip.fw.verbose_limit: 0
>
> Well I'll be. You learn
> > I like the ability at secure level 3 to only reset the counters forward..
> > It fits in with such things as the "append only" flag.
>
> Then we'd have to implement per-rule counters that default to
> IPFW_VERBOSE_LIMIT but that could be changed to anything. That's a very
> different setup th
> > > > I like the ability at secure level 3 to only reset the counters forward..
> > > > It fits in with such things as the "append only" flag.
> > >
> > > Then we'd have to implement per-rule counters that default to
> > > IPFW_VERBOSE_LIMIT but that could be changed to anything. That's a very
> > > You get *better* information on per-rule limits than on a global limit.
> >
> > No, you simply get a finer-grained ability to select.
>
> Which is almost always better.
>
> > > > If I'm an admin, I'm going to think "Well lets see, I want to store a
> > > > month of bad packets in it.
> > >
> > Again, it's not a fix, it's a feature. Not being able to mess with
> > counters (logging or otherwise) is a feature. It may be a feature that
> > you can do without, but that decision is not to be made lightly.
>
> I'm _saying_ to create a completely separ
> > > > > One could argue that accounting numbers in a firewall shouldn't be
> > > > > trusted, but I won't argue that point since the firewall is often the
> > > > > most 'natural' place to stick network accounting software.
> > > >
> > > > If you can't trust something in the kernel, then you ju
> > > I like the ability at secure level 3 to only reset the counters forward..
> > > It fits in with such things as the "append only" flag.
> >
> > Then we'd have to implement per-rule counters that default to
> > IPFW_VERBOSE_LIMIT but that could be changed to anything. That's a very
> > diffe
> > > > One could argue that accounting numbers in a firewall shouldn't be
> > > > trusted, but I won't argue that point since the firewall is often the
> > > > most 'natural' place to stick network accounting software.
> > >
> > > If you can't trust something in the kernel, then you just can't t
> > > How do you figure? Currently, the kernel will quit 'logging' denied
> > > packets when the counter reaches a specific (compiled-in) number.
> > ^
> > Then what is
> >
> > net.inet.ip.fw.verbose_limit: 0
>
> Well I'll be. You learn
> > I like the ability at secure level 3 to only reset the counters forward..
> > It fits in with such things as the "append only" flag.
>
> Then we'd have to implement per-rule counters that default to
> IPFW_VERBOSE_LIMIT but that could be changed to anything. That's a very
> different setup t
> > > You get *better* information on per-rule limits than on a global limit.
> >
> > No, you simply get a finer-grained ability to select.
>
> Which is almost always better.
>
> > > > If I'm an admin, I'm going to think "Well lets see, I want to store a
> > > > month of bad packets in it.
> >
> > (Another thing I just thought of is that this could cause DoS attacks on
> > the system if a user compromised root and then set the limit to a very
> > high number.)
>
> If you have someone going berzerk as "root" on a firewall you're definitely
> going to have a completely different set of he
On Tue, Jul 27, 1999 at 11:15:11AM -0600, Nate Williams wrote:
> Then we'd have to implement per-rule counters that default to
> IPFW_VERBOSE_LIMIT but that could be changed to anything.
*falling on my knees* If you're going to do that what would it cost me (in
chocolate bars or sushi) to get you
> > How do you figure? Currently, the kernel will quit 'logging' denied
> > packets when the counter reaches a specific (compiled-in) number.
> ^
> Then what is
>
> net.inet.ip.fw.verbose_limit: 0
Well I'll be. You learn something new ev
On Tue, Jul 27, 1999 at 11:12:25AM -0600, Nate Williams wrote:
> How do you figure? Currently, the kernel will quit 'logging' denied
> packets when the counter reaches a specific (compiled-in) number.
^
Then what is
net.inet.ip.fw.verbose_
:I just thought of a bad thing. If you allowed the counters to be zero'd
:(or advanced) at securelevel == 3, then a 'malicious user' could write a
:cronjob to continually reset them and cause a DoS attack on the system
:(or in the case of advance, reset them to ridiculously high values),
:thus fil
> ipfw allows you to clear counters. It is a feature that already exists.
>
> However, it does not allow you to do it if you are sitting at secure
> level 3.
>
> Why not? I can't think of any good reason why clearing the counters
> should be disallowed when sitting at a hig
> I like the ability at secure level 3 to only reset the counters forward..
> It fits in with such things as the "append only" flag.
Then we'd have to implement per-rule counters that default to
IPFW_VERBOSE_LIMIT but that could be changed to anything. That's a very
different setup than what we c
> :That doesn't mean we shouldn't allow people to have an unsophisticated setup,
> :just because a sophisticated one is available. It would be useful to have
> :a per-firewall-rule counter, decrement it on each match if logging and
> :set, and be able to reset to something higher.
> :
> : Brian Fun
> :Instead of zeroing it, how about raising the logging limit to (current +
> :whatever the limit was)
> :
> : Brian Fundakowski Feldman _ __ ___ ___ ___ ___
> : gr...@freebsd.org _ __ ___ | _ ) __| \
>
> The way I see it either some piece of software is monit
> > (Another thing I just thought of is that this could cause DoS attacks on
> > the system if a user compromised root and then set the limit to a very
> > high number.)
>
> If you have someone going berzerk as "root" on a firewall you're definitely
> going to have a completely different set of h
> > You get *better* information on per-rule limits than on a global limit.
>
> No, you simply get a finer-grained ability to select.
Which is almost always better.
> > > If I'm an admin, I'm going to think "Well lets see, I want to store a
> > > month of bad packets in it.
> >
> > If you're an
On Tue, Jul 27, 1999 at 11:15:11AM -0600, Nate Williams wrote:
> Then we'd have to implement per-rule counters that default to
> IPFW_VERBOSE_LIMIT but that could be changed to anything.
*falling on my knees* If you're going to do that what would it cost me (in
chocolate bars or sushi) to get you
> > How do you figure? Currently, the kernel will quit 'logging' denied
> > packets when the counter reaches a specific (compiled-in) number.
> ^
> Then what is
>
> net.inet.ip.fw.verbose_limit: 0
Well I'll be. You learn something new e
On Tue, Jul 27, 1999 at 11:12:25AM -0600, Nate Williams wrote:
> How do you figure? Currently, the kernel will quit 'logging' denied
> packets when the counter reaches a specific (compiled-in) number.
^
Then what is
net.inet.ip.fw.verbose
:But it might be hiding a real security threat/attack or a real breakin.
:Say I've spent all night trying to hack into your machine and finally get in.
:If I can reset all of ipfw's counters back to zero, and this is
:something your security checking scripts are checking, you might not
:think
:I just thought of a bad thing. If you allowed the counters to be zero'd
:(or advanced) at securelevel == 3, then a 'malicious user' could write a
:cronjob to continually reset them and cause a DoS attack on the system
:(or in the case of advance, reset them to ridiculously high values),
:thus fi
> ipfw allows you to clear counters. It is a feature that already exists.
>
> However, it does not allow you to do it if you are sitting at secure
> level 3.
>
> Why not? I can't think of any good reason why clearing the counters
> should be disallowed when sitting at a hi
> I like the ability at secure level 3 to only reset the counters forward..
> It fits in with such things as the "append only" flag.
Then we'd have to implement per-rule counters that default to
IPFW_VERBOSE_LIMIT but that could be changed to anything. That's a very
different setup than what we
1 - 100 of 136 matches
Mail list logo
