Re: kern/77570: [PATCH] ipfw: Multiple rules may have the same number.
The following reply was made to PR kern/77570; it has been noted by GNATS. From: Yar Tikhiy <[EMAIL PROTECTED]> To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: Subject: Re: kern/77570: [PATCH] ipfw: Multiple rules may have the same number. Date: Sat, 2 Jul 2005 14:51:17 +0400 Folks, Sorry, I haven't looked at how the discussion on freebsd-ipfw is going on ;-) but I can tell for myself that I consider having this "bug" in ipfw very useful. I use it often when I have to add some rules to a firewall temporarily and then remove them after a while. I add the temporary rules with the same rule number and then just type "ipfw d " once instead of having to remove each rule separately, which would be the case if the "bug" were "fixed". OTOH, thou shouldst abstain from messing with ipfw while having the morning cloudiness in thy mind and tremor in thy hands ;-))) Therefore I vote for closing this PR after making sure the current behaviour is well documented on the ipfw(8) manpage. -- Yar ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re[2]: kern/77570: [PATCH] ipfw: Multiple rules may have the same number.
Hello Yar, Saturday, July 2, 2005, 3:00:18 PM, you wrote: YT> The following reply was made to PR kern/77570; it has been noted by GNATS. YT> From: Yar Tikhiy <[EMAIL PROTECTED]> YT> To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] YT> Cc: YT> Subject: Re: kern/77570: [PATCH] ipfw: Multiple rules may have the same number. YT> Date: Sat, 2 Jul 2005 14:51:17 +0400 YT> Folks, YT> Sorry, I haven't looked at how the discussion on freebsd-ipfw is YT> going on ;-) but I can tell for myself that I consider having this YT> "bug" in ipfw very useful. agree with this.. -- Best regards, dawnshademailto:[EMAIL PROTECTED] ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/77570: [PATCH] ipfw: Multiple rules may have the same number.
Synopsis: [PATCH] ipfw: Multiple rules may have the same number. State-Changed-From-To: open->closed State-Changed-By: maxim State-Changed-When: Sat Jul 2 12:49:16 GMT 2005 State-Changed-Why: The proposed ipfw behaviour will hurt, break POLA, induce tsunami, pandemics, economic disasters, nuclear war and end with the Armageddon. http://www.freebsd.org/cgi/query-pr.cgi?pr=77570 ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Improvements to ipfw code (followup)
Hello, Back in 1997, an email was sent to hackers@ about some substantial firewall code improvements, along with a patch, by Julian Assange <[EMAIL PROTECTED],suburbia.net}>. A PR (misc/2386) was then filled, but marked 'closed' shortly after submission due to 'Misfiled PR' reason. It seems to never raise any interest afterwards, despite the fact that this work definitely worth considering. I will forward original mail at the end for those who's interested. My particular interest in this comes from a fact that uid/gid-based IPFW filtering only works for outgoing connections, which is a neat thing of course. However, to be able to provide any service, I need to allow incoming connections as well, and this is where I got somewhat disappointed: I cannot control who's bind()'ing to whatever port (if outside setup connections are allowed), and if, say, for whatever reason my cvsupd (or ircd, or quaked) exits, any malicious user process can issue bind() to the [freed] unprivileged port. One might say this is not a big deal, since servers tend to restart themselves in case of any failure, however, for example, FTP passive mode requires setup connections allowed in certain port range, and I really want only ftp user to be able to bind() to those ports. At present, there is no way in IPFW to open ports for specific user/group only, while Julian's patch seems to solve the problem. Time to revise this stuff again? :-) The URL Julian gives in his email is no longer valid, but his patches are in PR misc/2386, and also can be found at ftp://regency.nsu.ru/tmp/ipfw.diff. Sincerely, Alexey Dokuchaev -- Forwarded message -- Date: Tue, 7 Jan 1997 07:01:16 +1100 (EST) From: [EMAIL PROTECTED] To:[EMAIL PROTECTED], [EMAIL PROTECTED] Subject: new firewall code [uid/gid/bind() etc] Message-ID: <[EMAIL PROTECTED]> I tried posting the patches but, at 55k, it seems majordumbo has (silently) rejected them. You may find them at: ftp://suburbia.net/tmp/ipfw.diff My "socket credentials" patches allow you to: punch wormholes, or restrict access to the IPPORT_RESERVED space, or restrict access to bind() altogether based on: (a) uid (b) gid (including secondary groups) (c) port (d) protocol (e) interface And more importantly: Restrict access to packets being sent/received on any socket based on: (a) the packet (per normal ipfw rules) (b) uid (c) gid (including secondary groups) The former permits constructs like: /* let uid sendmail bind to port 25 */ # ipfw add accept wormhole on tcp from any 25 to any uid sendmail bind /* only let inetd bind - we presume inetd still needs to run as root for uid switching when forking off clients */ # addgroup inetd # chgrp inetd /usr/sbin/inetd # chmod 2700 /usr/sbin/inetd # killall inetd # ipfw add accept all from any to any bind gid inetd uid root # /* default policy is to deny bind */ /* keep those without security clearance out of secret network */ # ipfw add accept all from any to any via ed0 gid secret # ipfw add deny all from any to any via ed0 gid any Loging has also been enhanced: # ipfw add 6 accept log all from any to any bind /* example of named starting up */ ipfw: 5000 Allow TCP 0.0.0.0:53 0.0.0.0:0 uid 67 gid 0 pid 1280 bind ipfw: 5000 Allow UDP 203.4.184.222:53 0.0.0.0:0 via ed0 uid 67 gid 0 pid 1280 bind ipfw: 5000 Allow UDP 203.4.184.217:53 0.0.0.0:0 via ppp0 uid 67 gid 0 pid 1280 bind ipfw: 5000 Allow UDP 127.0.0.1:53 0.0.0.0:0 via lo0 uid 67 gid 0 pid 1280 bind ipfw: 5000 Allow UDP 0.0.0.0:53 0.0.0.0:0 uid 67 gid 0 pid 1280 bind Cheers, Julian <[EMAIL PROTECTED]> -- End of forwarded message -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-arch" in the body of the message ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Improvements to ipfw code (followup)
Just as a slight follow-up I should have included in my earlier e-mail: the merging of ucred and pcred should make this patch now be able to support real and saved uids/gids as well as effective uids/gids, meaning that it can be used to also restrict setuid applications such as ping. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services On Tue, 19 Feb 2002, Alexey Dokuchaev wrote: > Hello, > > Back in 1997, an email was sent to hackers@ about some substantial firewall > code improvements, > along with a patch, by Julian Assange <[EMAIL PROTECTED],suburbia.net}>. A > PR (misc/2386) was then > filled, but marked 'closed' shortly after submission due to 'Misfiled PR' > reason. It seems to > never raise any interest afterwards, despite the fact that this work > definitely worth considering. > > I will forward original mail at the end for those who's interested. My > particular interest in > this comes from a fact that uid/gid-based IPFW filtering only works for > outgoing connections, > which is a neat thing of course. However, to be able to provide any service, > I need to allow > incoming connections as well, and this is where I got somewhat disappointed: > I cannot control > who's bind()'ing to whatever port (if outside setup connections are allowed), > and if, say, for > whatever reason my cvsupd (or ircd, or quaked) exits, any malicious user > process can issue bind() > to the [freed] unprivileged port. One might say this is not a big deal, > since servers tend to > restart themselves in case of any failure, however, for example, FTP passive > mode requires setup > connections allowed in certain port range, and I really want only ftp user to > be able to bind() > to those ports. At present, there is no way in IPFW to open ports for > specific user/group only, > while Julian's patch seems to solve the problem. > > Time to revise this stuff again? :-) > > The URL Julian gives in his email is no longer valid, but his patches are in > PR misc/2386, and > also can be found at ftp://regency.nsu.ru/tmp/ipfw.diff. > > Sincerely, > Alexey Dokuchaev > > -- Forwarded message -- > Date: Tue, 7 Jan 1997 07:01:16 +1100 (EST) > From: [EMAIL PROTECTED] > To:[EMAIL PROTECTED], [EMAIL PROTECTED] > Subject: new firewall code [uid/gid/bind() etc] > Message-ID: <[EMAIL PROTECTED]> > > I tried posting the patches but, at 55k, it seems majordumbo has > (silently) rejected them. You may find them at: > > ftp://suburbia.net/tmp/ipfw.diff > > My "socket credentials" patches allow you to: > > punch wormholes, or restrict access to the IPPORT_RESERVED space, or > restrict access to bind() altogether based on: > > (a) uid > (b) gid (including secondary groups) > (c) port > (d) protocol > (e) interface > > And more importantly: > > Restrict access to packets being sent/received on any socket based on: > > (a) the packet (per normal ipfw rules) > (b) uid > (c) gid (including secondary groups) > > The former permits constructs like: > > /* let uid sendmail bind to port 25 */ > # ipfw add accept wormhole on tcp from any 25 to any uid sendmail bind > > /* only let inetd bind - we presume inetd still needs to run as root >for uid switching when forking off clients */ > > # addgroup inetd > # chgrp inetd /usr/sbin/inetd > # chmod 2700 /usr/sbin/inetd > # killall inetd > # ipfw add accept all from any to any bind gid inetd uid root > # /* default policy is to deny bind */ > > /* keep those without security clearance out of secret network */ > # ipfw add accept all from any to any via ed0 gid secret > # ipfw add deny all from any to any via ed0 gid any > > Loging has also been enhanced: > > # ipfw add 6 accept log all from any to any bind > /* example of named starting up */ > > ipfw: 5000 Allow TCP 0.0.0.0:53 0.0.0.0:0 uid 67 gid 0 pid 1280 bind > ipfw: 5000 Allow UDP 203.4.184.222:53 0.0.0.0:0 via ed0 uid 67 gid 0 pid 1280 > bind > ipfw: 5000 Allow UDP 203.4.184.217:53 0.0.0.0:0 via ppp0 uid 67 gid 0 pid > 1280 bind > ipfw: 5000 Allow UDP 127.0.0.1:53 0.0.0.0:0 via lo0 uid 67 gid 0 pid 1280 bind > ipfw: 5000 Allow UDP 0.0.0.0:53 0.0.0.0:0 uid 67 gid 0 pid 1280 bind > > Cheers, > Julian <[EMAIL PROTECTED]> > > -- End of forwarded message -- > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-arch" in the body of the message ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Improvements to ipfw code (followup)
On Tue, Feb 19, 2002 at 11:40:03AM -0500, Robert Watson wrote: > Just as a slight follow-up I should have included in my earlier e-mail: > the merging of ucred and pcred should make this patch now be able to > support real and saved uids/gids as well as effective uids/gids, meaning > that it can be used to also restrict setuid applications such as ping. Cool! Right now I am cleaning up this 5-year old patch to catch up with current IPFW code, fixing possible bugs, and separating optimizations and features stuff for easier reviewing and testing. I like the idea of supporting real and saved uids/gids as well as effective ones, I think I will include this functionality as soon as I get the whole thing working with current -CURRENT. Regs, Alexey Dokuchaev To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-arch" in the body of the message ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/71366: "ipfw fwd" sometimes rewrites destination mac address when it's not necessary (packet must not meet the rule)
Synopsis: "ipfw fwd" sometimes rewrites destination mac address when it's not necessary (packet must not meet the rule) Responsible-Changed-From-To: freebsd-bugs->ipfw Responsible-Changed-By: linimon Responsible-Changed-When: Sat Sep 11 23:24:30 GMT 2004 Responsible-Changed-Why: Over to mailing list. http://www.freebsd.org/cgi/query-pr.cgi?pr=71366 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw and ipsec processing order for outgoing packets wrong
Hi, The counters for queue 1 keeps increasing when I do a ftp out even for non-ACK packets but the other counters for queue 2-4 doesn't move at all so it seems like everything is going out one queue instead of what the rules actually say. I have one pipe configured as 480Kbit/sec which is what rules 63005-63008 does. Are you using IPsec ? Ari S. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw and ipsec processing order for outgoing packets wrong
On Mon, 1 Nov 2004 14:20:10 +0200, Ari Suutari <[EMAIL PROTECTED]> wrote: > > The counters for queue 1 keeps increasing when I do a ftp out even for > > non-ACK packets but the other counters for queue 2-4 doesn't move at > > all so it seems like everything is going out one queue instead of what > > the rules actually say. I have one pipe configured as 480Kbit/sec > > which is what rules 63005-63008 does. > >Are you using IPsec ? > >Ari S. Nope... As you can see, I'm just using ipfw2 with dummynet for pipe/queue just for traffic shaping. Cheers, Vince ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw and ipsec processing order for outgoing packets wrong
Hi, I don't know how to explain my problem but it goes something like this... [EMAIL PROTECTED] [2:05am][/home/vince] >> ipfw show 00049 1557131244839199 skipto 100 ip from 208.201.244.224/29 to any 00050 12072800468 917651580916 divert 8668 ip from any to any via xl0 00100 69518 8548222 allow ip from any to any via lo0 00200 00 deny ip from any to 127.0.0.0/8 00300 00 deny ip from 127.0.0.0/8 to any 63000 00 allow ip from any to 10.0.0.0/8 out 63001 00 allow ip from any to 172.16.0.0/12 out 63002 31216048 allow ip from any to 192.168.0.0/16 out 63003 24237 2952214 allow ip from any to 208.201.244.224/29 out 63004 667879129410867 queue 1 tcp from any to any tcpflags ack out 63005 1 40 queue 2 tcp from any to any dst-port 22,23 out 63006 38782 3364689 queue 2 udp from any to any not dst-port 80,443 out 63007 43021 2194871 queue 3 ip from any to any dst-port 80,443 out 630085467 405319 queue 4 ip from any to any out 65000 1795325424479044 allow ip from any to any 65535 00 deny ip from any to any The counters for queue 1 keeps increasing when I do a ftp out even for non-ACK packets but the other counters for queue 2-4 doesn't move at all so it seems like everything is going out one queue instead of what the rules actually say. I have one pipe configured as 480Kbit/sec which is what rules 63005-63008 does. ipfw pipe show and ipfw queue show would seem normal except the Source IP and Destination IP is stuck with the first processed queues information while only the counters for queue 1 updates. [EMAIL PROTECTED] [2:12am][/home/vince] >> ipfw pipe show 1: 480.000 Kbit/s0 ms 50 sl. 0 queues (1 buckets) droptail mask: 0x00 0x/0x -> 0x/0x q1: weight 100 pipe 1 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x/0x -> 0x/0x BKT Prot ___Source IP/port Dest. IP/port Tot_pkt/bytes Pkt/Byte Drp 0 tcp 208.201.244.226/3748 205.188.179.233/5190 673549 137223155 00 2303 q2: weight 66 pipe 1 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x/0x -> 0x/0x BKT Prot ___Source IP/port Dest. IP/port Tot_pkt/bytes Pkt/Byte Drp 0 udp 208.201.244.225/1026 208.201.224.11/5340022 3470523 00 0 q3: weight 33 pipe 1 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x/0x -> 0x/0x BKT Prot ___Source IP/port Dest. IP/port Tot_pkt/bytes Pkt/Byte Drp 0 tcp 208.201.244.226/3750 199.181.132.105/8043058 2196795 00 0 q4: weight 1 pipe 1 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x/0x -> 0x/0x BKT Prot ___Source IP/port Dest. IP/port Tot_pkt/bytes Pkt/Byte Drp 0 tcp 208.201.244.226/3748 205.188.179.233/5190 5492 407173 00 0 [EMAIL PROTECTED] [2:12am][/home/vince] >> ipfw queue show q1: weight 100 pipe 1 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x/0x -> 0x/0x BKT Prot ___Source IP/port Dest. IP/port Tot_pkt/bytes Pkt/Byte Drp 0 tcp 208.201.244.226/3748 205.188.179.233/5190 673550 137223195 00 2303 q2: weight 66 pipe 1 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x/0x -> 0x/0x BKT Prot ___Source IP/port Dest. IP/port Tot_pkt/bytes Pkt/Byte Drp 0 udp 208.201.244.225/1026 208.201.224.11/5340025 3470881 00 0 q3: weight 33 pipe 1 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x/0x -> 0x/0x BKT Prot ___Source IP/port Dest. IP/port Tot_pkt/bytes Pkt/Byte Drp 0 tcp 208.201.244.226/3750 199.181.132.105/8043058 2196795 00 0 q4: weight 1 pipe 1 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x/0x -> 0x/0x BKT Prot ___Source IP/port Dest. IP/port Tot_pkt/bytes Pkt/Byte Drp 0 tcp 208.201.244.226/3748 205.188.179.233/5190 5493 407225 00 0 I don't know how else I would test this. Cheers, Vince On Mon, 1 Nov 2004 09:35:58 +0200, Ari Suutari <[EMAIL PROTECTED]> wrote: > >I am experiencing the same problem as well when I updated from a March > > 6, 2004 -CURRENT to the October 19, 2004 -CURRENT. The problem still > > exists with the October 27, 2004 -CURRENT. I'm using ipfw/dummynet > > for outgoing queues with the ACK packets having the highest priority > > in it's own queue. However, it seems like while the queues are there, > > the information on ipfw queue show doesn't update at all as the Source > > and Destination IP is still the same as the first packet after bootup > > while the counters change but the ACK packets are not sent on it's own > > queue but rather with all other packets. I know
[PATCH] testers wanted
I have generated a patch which appears to solve the lock ordering issues associated with ucred based filtering which results in hard locks (while mpsafenet=1). This patch basically implements a shared locking mechanism. http://people.freebsd.org/~csjp/ip_fw2.c.1099500281.diff It would be appriciated if interested parties could download it, load a large number of rules and try to manipulate (delete/add) rules under high loads. Thanks! -- Christian S.J. Peron [EMAIL PROTECTED] FreeBSD Committer ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
