Re: rc.order wrong (ipfw)
On Fri, Mar 16, 2007 at 08:33:01PM -0300, JoaoBR wrote: On Friday 16 March 2007 18:50, Jeremy Chadwick wrote: Okay, imagine this order: 1) Kernel starts 2) Network driver is loaded 3) Link is brought up 4) Interface is configured for IP (manually or via DHCP) 5) Firewall rules (ipfw or pf) are applied Do you realise that between steps #4 and steps #5 there is a small window of time where someone may be able to send packets to your machine and get responses which would normally be blocked by ipfw/pf? nono that is not exactly how it works unless you change ipfw's default behaviour which is deny all from any to an y, nothing goes to this machine because by default everything is blocked until you permit it You're absolutely correct, however your original post seems to have taken many of us by surprise, causing some of us (at least me!) to assume that you've changed the default method to allow. I'm obviously misunderstanding, so I apologise for that, but I hope you can see the reasoning behind my comments with what I knew at the time. :) ipfw needs to be before networking or router discovery fails for IPv6. http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/108589 -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rc.order wrong (ipfw)
On Saturday 17 March 2007 03:58, Mark Andrews wrote: nothing goes to this machine because by default everything is blocked until you permit it You're absolutely correct, however your original post seems to have taken many of us by surprise, causing some of us (at least me!) to assume that you've changed the default method to allow. I'm obviously misunderstanding, so I apologise for that, but I hope you can see the reasoning behind my comments with what I knew at the time. :) ipfw needs to be before networking or router discovery fails for IPv6. http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/108589 as default any network connection will fail so long as you do not permit it If rtsol fails or is called to early it is an rtsol problem and not an ipfw problem I guess as another example, what if you set a ifconfig_nic0=inet hostname instead of IP address and this hostname is not in /etc/hosts and ipfw is still not up and named is far away to start, then, according to your idea we need to start named and ipfw before netif? -- João A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rc.order wrong (ipfw)
On Saturday 17 March 2007 03:58, Mark Andrews wrote: nothing goes to this machine because by default everything is blocked until you permit it You're absolutely correct, however your original post seems to have taken many of us by surprise, causing some of us (at least me!) to assume that you've changed the default method to allow. I'm obviously misunderstanding, so I apologise for that, but I hope you can see the reasoning behind my comments with what I knew at the time. :) ipfw needs to be before networking or router discovery fails for IPv6. http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/108589 as default any network connection will fail so long as you do not permit it If rtsol fails or is called to early it is an rtsol problem and not an ipfw problem I guess as another example, what if you set a ifconfig_nic0=inet hostname instead o f IP address and this hostname is not in /etc/hosts and ipfw is still not up and named is far away to start, then, according to your idea we need to start If you do that then the address must be in /etc/hosts. named and ipfw before netif? ip6fw is before networking. ipfw is supposed to be taking over from ip6fw. ipfw and ip6wf should be started at a similar time. rtsol is approximately the equivalent to DHCP. The machine is requesting a address from the network. It doesn't matter if it is a router or a DHCP server that is suppling the address. DHCP only works because it bypasses the firefall. Mark -- João A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rc.order wrong (ipfw)
Mark, You've raised some good points here. I'm going to start a new thread on -net and -rc to see if we can't sort out how this _should_ work. Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
rc.order wrong (ipfw)
since some time now it seems ipfw starts first of all, I think that is not correct rcorder: file `/etc/rc.d/ipfw' is before unknown provision `NETWORKING' rcorder: requirement `ppp' in file `/etc/rc.d/ipfw' has no providers. /etc/rc.d/ipfw I changed the order for my needs but it might be a good idea to fix this problem. -- João A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rc.order wrong (ipfw)
JoaoBR [EMAIL PROTECTED] wrote: since some time now it seems ipfw starts first of all, I think that is not correct No, it starts after networking is up, which is the correct behaviour, I think. rcorder: file `/etc/rc.d/ipfw' is before unknown provision `NETWORKING' rcorder: requirement `ppp' in file `/etc/rc.d/ipfw' has no providers. That sounds like you have accidentally deleted the files /etc/rc.d/NETWORKING and /etc/rc.d/ppp (or forgot to run mergemaster properly after an update). Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd C++ is the only current language making COBOL look good. -- Bertrand Meyer ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rc.order wrong (ipfw)
On Friday 16 March 2007 07:51, Oliver Fromme wrote: JoaoBR [EMAIL PROTECTED] wrote: since some time now it seems ipfw starts first of all, I think that is not correct No, it starts after networking is up, which is the correct behaviour, I think. it should rcorder: file `/etc/rc.d/ipfw' is before unknown provision `NETWORKING' rcorder: requirement `ppp' in file `/etc/rc.d/ipfw' has no providers. That sounds like you have accidentally deleted the files /etc/rc.d/NETWORKING and /etc/rc.d/ppp (or forgot to run mergemaster properly after an update). noo, both are there even if working as supposed NETWORKING is ordered before syslogd and ipfw should better start after syslogd -- João A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rc.order wrong (ipfw)
JoaoBR [EMAIL PROTECTED] wrote: On Friday 16 March 2007 07:51, Oliver Fromme wrote: JoaoBR [EMAIL PROTECTED] wrote: since some time now it seems ipfw starts first of all, I think that is not correct No, it starts after networking is up, which is the correct behaviour, I think. it should Sorry, I made a typo there. Of course IPFW rules must be in effect as a prerequisite to NETWORKING. So I meant to say _before_, not after. rcorder: file `/etc/rc.d/ipfw' is before unknown provision `NETWORKING' rcorder: requirement `ppp' in file `/etc/rc.d/ipfw' has no providers. That sounds like you have accidentally deleted the files /etc/rc.d/NETWORKING and /etc/rc.d/ppp (or forgot to run mergemaster properly after an update). noo, both are there Then they are broken on your machine. Did you check the provide and require lines in them? The ordering works perfectly fine for me on all of my machines. even if working as supposed NETWORKING is ordered before syslogd and ipfw should better start after syslogd No, the packet filter and forwarding rules must be in effect as early as possible, i.e. before any network daemons are started (which includes syslogd). There- fore it must be a requirement of NETWORKING. If IPFW rules where loaded after daemons such as syslogd are started, that would break several of my machines. (And on some others which have default to accept it would even open a security hole by introducing a race- condition.) Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Python tricks is a tough one, cuz the language is so clean. E.g., C makes an art of confusing pointers with arrays and strings, which leads to lotsa neat pointer tricks; APL mistakes everything for an array, leading to neat one-liners; and Perl confuses everything period, making each line a joyous adventure wink. -- Tim Peters ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rc.order wrong (ipfw)
On Friday 16 March 2007 08:52, Oliver Fromme wrote: rcorder: file `/etc/rc.d/ipfw' is before unknown provision `NETWORKING' rcorder: requirement `ppp' in file `/etc/rc.d/ipfw' has no providers. That sounds like you have accidentally deleted the files /etc/rc.d/NETWORKING and /etc/rc.d/ppp (or forgot to run mergemaster properly after an update). noo, both are there Then they are broken on your machine. Did you check the provide and require lines in them? The ordering works perfectly fine for me on all of my machines. I checked yes, sure even if working as supposed NETWORKING is ordered before syslogd and ipfw should better start after syslogd No, the packet filter and forwarding rules must be in effect as early as possible, i.e. before any network daemons are started (which includes syslogd). There- fore it must be a requirement of NETWORKING. could you explain your opinion? I don't agree to what you say what sense does it make to have my forward rules up but natd still not? what sense does it makes logging while syslog is not up? If IPFW rules where loaded after daemons such as syslogd are started, that would break several of my machines. (And on some others which have default to accept it would even open a security hole by introducing a race- condition.) oops, so what would break there? I thought, the defaults are to support other defaults and not particular settings because freebsd's ipfw default is to deny all and not to accept the security hole you mention I can not see anywhere ipfw is not on by default so you say here that FreeBSD has a default security hole because it's default is having no ipfw rules? -- João A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rc.order wrong (ipfw)
JoaoBR wrote: I don't agree to what you say what sense does it make to have my forward rules up but natd still not? what sense does it makes logging while syslog is not up? What would it forward log when network isn't up? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rc.order wrong (ipfw)
On Friday 16 March 2007 10:40, Pertti Kosunen wrote: JoaoBR wrote: I don't agree to what you say what sense does it make to have my forward rules up but natd still not? what sense does it makes logging while syslog is not up? What would it forward log when network isn't up? man, starting ipfw after network does not mean that the network is not up -- João A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rc.order wrong (ipfw)
On Fri, Mar 16, 2007 at 06:00:30PM -0300, JoaoBR wrote: man, starting ipfw after network does not mean that the network is not up Okay, imagine this order: 1) Kernel starts 2) Network driver is loaded 3) Link is brought up 4) Interface is configured for IP (manually or via DHCP) 5) Firewall rules (ipfw or pf) are applied Do you realise that between steps #4 and steps #5 there is a small window of time where someone may be able to send packets to your machine and get responses which would normally be blocked by ipfw/pf? -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rc.order wrong (ipfw)
Date: Fri, 16 Mar 2007 15:40:44 +0200 From: Pertti Kosunen [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] JoaoBR wrote: I don't agree to what you say what sense does it make to have my forward rules up but natd still not? what sense does it makes logging while syslog is not up? What would it forward log when network isn't up? Hmm. Let's see. Maybe the stuff that happens between the start of the network and the start of ipfw? Remember that, by default, until ipfw starts, there is a default 65535 deny ip from any to any in the firewall, thus blocking everything until ipfw starts. You should either not build ipfw into the kernel or build with the IPFIREWALL_DEFAULT_TO_ACCEPT option if you want something to be able to pass through the network before ipfw starts. (Hint, if you run IPv6, you probably do.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgpHMtrJORwof.pgp Description: PGP signature
Re: rc.order wrong (ipfw)
On Friday 16 March 2007 18:50, Jeremy Chadwick wrote: On Fri, Mar 16, 2007 at 06:00:30PM -0300, JoaoBR wrote: man, starting ipfw after network does not mean that the network is not up Okay, imagine this order: 1) Kernel starts 2) Network driver is loaded 3) Link is brought up 4) Interface is configured for IP (manually or via DHCP) 5) Firewall rules (ipfw or pf) are applied Do you realise that between steps #4 and steps #5 there is a small window of time where someone may be able to send packets to your machine and get responses which would normally be blocked by ipfw/pf? nono that is not exactly how it works unless you change ipfw's default behaviour which is deny all from any to any, nothing goes to this machine because by default everything is blocked until you permit it -- João A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rc.order wrong (ipfw)
On Fri, Mar 16, 2007 at 08:33:01PM -0300, JoaoBR wrote: On Friday 16 March 2007 18:50, Jeremy Chadwick wrote: Okay, imagine this order: 1) Kernel starts 2) Network driver is loaded 3) Link is brought up 4) Interface is configured for IP (manually or via DHCP) 5) Firewall rules (ipfw or pf) are applied Do you realise that between steps #4 and steps #5 there is a small window of time where someone may be able to send packets to your machine and get responses which would normally be blocked by ipfw/pf? nono that is not exactly how it works unless you change ipfw's default behaviour which is deny all from any to any, nothing goes to this machine because by default everything is blocked until you permit it You're absolutely correct, however your original post seems to have taken many of us by surprise, causing some of us (at least me!) to assume that you've changed the default method to allow. I'm obviously misunderstanding, so I apologise for that, but I hope you can see the reasoning behind my comments with what I knew at the time. :) -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
