Re: IPF firewalling
If you compiled you kernel, and added options IPFILTER_DEFAULT_BLOCK, then you need to explicitly allow each service to leave the interface, as well as come in thru the interface. For example add: pass in quick proto tcp from any to any port = 53 keep state keep keep state frags pass in quick proto udp from any to any port = 53 keep state keep frags this allows the the computer to attempt to contact the DNS server upstream from it. Hope this helps, Alvaro Gurdián Jr. On Jan 16, 2005, at 10:35 AM, Kövesdán Gábor wrote: Hi, I have some trouble with the ipf configuration. I made the following ruleset: pass in quick on rl0 proto udp from any to any port = 68 keep state pass in quick proto udp from any to any port = 53 keep state keep frags pass in quick on rl0 proto tcp/udp from any to any port = 42 keep state keep frags pass in quick on rl0 proto tcp from any to any port = 22 flags S keep state pass in quick on rl0 proto tcp from any to any port = 25 keep state pass in quick on rl0 proto tcp from any to any port = 21 keep state pass in quick on rl0 proto tcp from any to any port = 20 keep state pass in quick on rl0 proto tcp from any to any port = 80 keep state block return-rst in log quick on rl0 proto tcp from any to any block return-icmp-as-dest(port-unr) in log quick on rl0 proto udp from any to any block in quick on rl0 all pass in quick on lo0 all pass out quick on lo0 all Everything seems okay, but the named. Neiher the ISP's nameserver (set by the dhcp) nor the local nameserver works. BIND 9 wrote this to /var/log/messages: Jan 16 13:59:35 server named[1028]: starting BIND 9.3.0 -u named -t /usr/local/named -c /etc/named.conf Jan 16 13:59:35 server named[1028]: could not listen on UDP socket: address in use Jan 16 13:59:35 server named[1028]: creating IPv4 interface re0 failed; interface ignored Jan 16 13:59:35 server named[1028]: could not listen on UDP socket: address in use Jan 16 13:59:35 server named[1028]: creating IPv4 interface lo0 failed; interface ignored Jan 16 13:59:35 server named[1028]: not listening on any interfaces Jan 16 13:59:35 server named[1028]: /etc/named.conf:14: couldn't add command channel 127.0.0.1#953: address in use Jan 16 13:59:35 server named[1028]: could not listen on UDP socket: permission denied Jan 16 13:59:35 server named[1028]: creating IPv4 interface re0 failed; interface ignored Jan 16 13:59:35 server named[1028]: could not listen on UDP socket: permission denied Jan 16 13:59:35 server named[1028]: creating IPv4 interface lo0 failed; interface ignored The rndc doesn't matter, I'm not going to use it, but the neither named can listen on the network and the loopback interface. Could You suggest me any solution for this trouble? Btw, this machine is going to be a web, dns, mail, etc. server and is being tested on an ordinary cable connection, that's why I'm using dhcp. Best regards, Gábor Kövesdán ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPF firewalling
correction, I meant pass out quick on rl0 proto tcp from any to any port = 53 keep state frags pass out quick on rl0 proto udp from any to any port = 53 keep state frags I did it in kind of a hurry. On Jan 17, 2005, at 3:33 PM, Alvaro J. Gurdián wrote: If you compiled you kernel, and added options IPFILTER_DEFAULT_BLOCK, then you need to explicitly allow each service to leave the interface, as well as come in thru the interface. For example add: pass in quick proto tcp from any to any port = 53 keep state keep keep state frags pass in quick proto udp from any to any port = 53 keep state keep frags this allows the the computer to attempt to contact the DNS server upstream from it. Hope this helps, Alvaro Gurdián Jr. On Jan 16, 2005, at 10:35 AM, Kövesdán Gábor wrote: Hi, I have some trouble with the ipf configuration. I made the following ruleset: pass in quick on rl0 proto udp from any to any port = 68 keep state pass in quick proto udp from any to any port = 53 keep state keep frags pass in quick on rl0 proto tcp/udp from any to any port = 42 keep state keep frags pass in quick on rl0 proto tcp from any to any port = 22 flags S keep state pass in quick on rl0 proto tcp from any to any port = 25 keep state pass in quick on rl0 proto tcp from any to any port = 21 keep state pass in quick on rl0 proto tcp from any to any port = 20 keep state pass in quick on rl0 proto tcp from any to any port = 80 keep state block return-rst in log quick on rl0 proto tcp from any to any block return-icmp-as-dest(port-unr) in log quick on rl0 proto udp from any to any block in quick on rl0 all pass in quick on lo0 all pass out quick on lo0 all Everything seems okay, but the named. Neiher the ISP's nameserver (set by the dhcp) nor the local nameserver works. BIND 9 wrote this to /var/log/messages: Jan 16 13:59:35 server named[1028]: starting BIND 9.3.0 -u named -t /usr/local/named -c /etc/named.conf Jan 16 13:59:35 server named[1028]: could not listen on UDP socket: address in use Jan 16 13:59:35 server named[1028]: creating IPv4 interface re0 failed; interface ignored Jan 16 13:59:35 server named[1028]: could not listen on UDP socket: address in use Jan 16 13:59:35 server named[1028]: creating IPv4 interface lo0 failed; interface ignored Jan 16 13:59:35 server named[1028]: not listening on any interfaces Jan 16 13:59:35 server named[1028]: /etc/named.conf:14: couldn't add command channel 127.0.0.1#953: address in use Jan 16 13:59:35 server named[1028]: could not listen on UDP socket: permission denied Jan 16 13:59:35 server named[1028]: creating IPv4 interface re0 failed; interface ignored Jan 16 13:59:35 server named[1028]: could not listen on UDP socket: permission denied Jan 16 13:59:35 server named[1028]: creating IPv4 interface lo0 failed; interface ignored The rndc doesn't matter, I'm not going to use it, but the neither named can listen on the network and the loopback interface. Could You suggest me any solution for this trouble? Btw, this machine is going to be a web, dns, mail, etc. server and is being tested on an ordinary cable connection, that's why I'm using dhcp. Best regards, Gábor Kövesdán ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: IPF firewalling
Hello, Now reading this - maybe you left out the default action at the top of the ruleset? - I only see pass rules and unless you compiled your kernel with default block, then default is pass, leaving your host with no effective firewall at all. Should suffice just to flush the rules, unless you compile your kernel with default block. Whatever default is, it is always a good idea for clarity to include a catch all rule. Also, make sure to add log and start ipmon, when something falls through or is blocked for other reasons, you have a log entry stating which rule blocked so you can debug your ruleset. - I see I left it out in the default rules I suggested, these rules should go at top of the file: block out log all block in log all Whatever falls through your ruleset will be logged so you can analyse it. When you flush your rulesets, the state table is not flushed, so you shouldn't loose your connection. Also, I recommend you reading rules into the inactive ruletable first. Then swap. This way you make sure your rules does not contain typos and you don't leave your firewall/host vulnerable. # ipf -IFa ipf -I -f rulefile ipf -s sleep 60 ipf -s lets you test the new ruleset 60 seconds, should you loose connection. If things work then # ipf -Ifa ipf -I -f rulefile ipf -s ipf -IFa I've resolved the problem with individual pass out rules for tcp, udp and icmp protocols. I don't know why pass out all was not okay, but it wasn't. Thus my ruleset starts with these lines: pass out quick on re0 proto tcp from any to any keep state keep frags pass out quick on re0 proto udp from any to any keep state keep frags pass out quick on re0 proto icmp from any to any keep state keep frags Anyway, thanks for your ideas, which were very useful for me. I'm using now the catch-all rules as You suggested. You also mentioned, there can be some problems with the ftp server. Could You tell me please, what You meant? Ftp hasn't been running yet, so I can't test it, but there will also be an ftp soon. Thanks, Gbor Kvesdn ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPF firewalling
Kvesdn Gbor wrote: Anyway, thanks for your ideas, which were very useful for me. I'm using now the catch-all rules as You suggested. You also mentioned, there can be some problems with the ftp server. Could You tell me please, what You meant? Ftp hasn't been running yet, so I can't test it, but there will also be an ftp soon. Setting up ftp-session is straight forward, it works as any other server, binds to port 21. The problem is ftp-data, you have active and passive. This is from the servers point of view and relates to who establishes the connection. In active mode the server will connect (so server is the active end) _to_ the client _from_ port 20. You had a rule for _in_ coming trafic _to_ port 20, this should be deleted. Instead you need: pass out proto tcp from any port = 20 to any port 1023 flags S \ keep state keep frags Now, since you allow any outgoing traffic you can skip this. The port 1023 could be left out also, but I prefer to be strict. In pasive mode the client will connect to some port, specified by the server (this is really complicated). The good thing is that normally you can configure the server to use a specific port interval. Typically the range port 49151 (dynamic range) is used. So you need something like this: pass in proto tcp from any to any port 49151 flags S keep state \ keep frags All this ftp-data has sometimes effect on what you would expect to be ordinary ftp-session, output from some commands like ls may be sent as ftp-data, so if ftp-data doesn't work, you may experience that you can change directory but not list content and other peculiar behaviour. I don't know how to configure this for the ftpd included in base, I use vsftpd which has a simple config. Hope this explains it, otherwise, I suggest you search the rfc's or firewall documentation. Also, keep in mind, that if you have a gateway with NAT you almost always need to setup some kind of ftp-proxy to let your clients on the LAN connect. Cheers, Erik -- Ph: +34.666334818 web: www.locolomo.org S/MIME Certificate: http://www.locolomo.org/crt/2004071206.crt Subject ID: A9:76:7A:ED:06:95:2B:8D:48:97:CE:F2:3F:42:C8:F2:22:DE:4C:B9 Fingerprint: 4A:E8:63:38:46:F6:9A:5D:B4:DC:29:41:3F:62:D3:0A:73:25:67:C2 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPF firewalling
Kvesdn Gbor wrote: pass in quick on rl0 proto udp from any to any port = 68 keep state pass in quick proto udp from any to any port = 53 keep state keep frags First I see that you have left out on rl0 in this line. pass in quick on rl0 proto tcp/udp from any to any port = 42 keep state keep frags you don't need this. dns uses port 53, both tcp and udp. pass in quick on rl0 proto tcp from any to any port = 22 flags S keep state pass in quick on rl0 proto tcp from any to any port = 25 keep state pass in quick on rl0 proto tcp from any to any port = 21 keep state pass in quick on rl0 proto tcp from any to any port = 20 keep state pass in quick on rl0 proto tcp from any to any port = 80 keep state use flags S for all tcp rules for your security. block return-rst in log quick on rl0 proto tcp from any to any block return-icmp-as-dest(port-unr) in log quick on rl0 proto udp from any to any block in quick on rl0 all pass in quick on lo0 all pass out quick on lo0 all Everything seems okay, but the named. Neiher the ISP's nameserver (set by the dhcp) nor the local nameserver works. BIND 9 wrote this to /var/log/messages: Jan 16 13:59:35 server named[1028]: starting BIND 9.3.0 -u named -t /usr/local/named -c /etc/named.conf Jan 16 13:59:35 server named[1028]: could not listen on UDP socket: address in use Jan 16 13:59:35 server named[1028]: creating IPv4 interface re0 failed; interface ignored Jan 16 13:59:35 server named[1028]: could not listen on UDP socket: address in use Jan 16 13:59:35 server named[1028]: creating IPv4 interface lo0 failed; interface ignored Jan 16 13:59:35 server named[1028]: not listening on any interfaces Jan 16 13:59:35 server named[1028]: /etc/named.conf:14: couldn't add command channel 127.0.0.1#953: address in use Jan 16 13:59:35 server named[1028]: could not listen on UDP socket: permission denied Jan 16 13:59:35 server named[1028]: creating IPv4 interface re0 failed; interface ignored Jan 16 13:59:35 server named[1028]: could not listen on UDP socket: permission denied Jan 16 13:59:35 server named[1028]: creating IPv4 interface lo0 failed; interface ignored The rndc doesn't matter, I'm not going to use it, but the neither named can listen on the network and the loopback interface. Could You suggest me any solution for this trouble? Btw, this machine is going to be a web, dns, mail, etc. server and is being tested on an ordinary cable connection, that's why I'm using dhcp. First, the named problem does not seem to relate with the firewall ruleset - try take the host off line, flush all rules and see if you can start named or get the same error. For your security, I suggest you use groups to organize the rules and write a default action explicitly, first lines: block in all block out all (no quick here). Then split according to interface, first let lo0 loose: pass in quick on lo0 all pass out quick on lo0 all follow with groups for each interface. Groups really helps you tracking down filter problems and staying sane. See the ipf-howto. Also be consistent using keep state keep frags and flags S everywhere. I see you have tried to setup ftp also in the above ruleset, ftp won't work with this, but it really requires understanding of ftp to get it right. Maybe keep it simple and remove ftp for a start. Cheers, Erik -- Ph: +34.666334818 web: www.locolomo.org S/MIME Certificate: http://www.locolomo.org/crt/2004071206.crt Subject ID: A9:76:7A:ED:06:95:2B:8D:48:97:CE:F2:3F:42:C8:F2:22:DE:4C:B9 Fingerprint: 4A:E8:63:38:46:F6:9A:5D:B4:DC:29:41:3F:62:D3:0A:73:25:67:C2 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: IPF firewalling
Hello, Thanks for your answer, I've modified my rules as You suggested, but I haven't made groups yet. Thus the new ruleset is: # I don't want to filter outgoing packets pass out quick all # The incoming packets for dhcp, dns, ssh, mail, ftp, www pass in quick on rl0 proto udp from any to any port = 68 keep state keep frags pass in quick on rl0 proto udp from any to any port = 53 keep state keep frags pass in quick on rl0 proto tcp from any to any port = 53 flags S keep state keep frags pass in quick on rl0 proto tcp from any to any port = 22 flags S keep state keep frags pass in quick on rl0 proto tcp from any to any port = 25 flags S keep state keep frags pass in quick on rl0 proto tcp from any to any port = 21 flags S keep state keep frags pass in quick on rl0 proto tcp from any to any port = 20 flags S keep state keep frags pass in quick on rl0 proto tcp from any to any port = 80 flags S keep state keep frags # Some advanced stuff - will be set later #block return-rst in log quick on rl0 proto tcp from any to any #block return-icmp-as-dest(port-unr) in log quick on rl0 proto udp from any to any #block in quick on rl0 all # Allow everything for the loopback interface pass in quick on lo0 all pass out quick on lo0 all I ran the ipf -Fa ipf -f /etc/ipf.rules2 command (ipf.rules2 is this ruleset) via ssh, but then my connection closed, and I was unable to reconnect via ssh until flushing the rules and loading this ruleset: pass in all pass out all Best wishes, Gbor Kvesdn ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPF firewalling
Kvesdn Gbor wrote: Thanks for your answer, I've modified my rules as You suggested, but I haven't made groups yet. Thus the new ruleset is: But did you resolve the named problem? # I don't want to filter outgoing packets pass out quick all # The incoming packets for dhcp, dns, ssh, mail, ftp, www pass in quick on rl0 proto udp from any to any port = 68 keep state keep frags pass in quick on rl0 proto udp from any to any port = 53 keep state keep frags pass in quick on rl0 proto tcp from any to any port = 53 flags S keep state keep frags pass in quick on rl0 proto tcp from any to any port = 22 flags S keep state keep frags pass in quick on rl0 proto tcp from any to any port = 25 flags S keep state keep frags pass in quick on rl0 proto tcp from any to any port = 21 flags S keep state keep frags pass in quick on rl0 proto tcp from any to any port = 20 flags S keep state keep frags pass in quick on rl0 proto tcp from any to any port = 80 flags S keep state keep frags # Some advanced stuff - will be set later #block return-rst in log quick on rl0 proto tcp from any to any #block return-icmp-as-dest(port-unr) in log quick on rl0 proto udp from any to any #block in quick on rl0 all # Allow everything for the loopback interface pass in quick on lo0 all pass out quick on lo0 all Now reading this - maybe you left out the default action at the top of the ruleset? - I only see pass rules and unless you compiled your kernel with default block, then default is pass, leaving your host with no effective firewall at all. I ran the ipf -Fa ipf -f /etc/ipf.rules2 command (ipf.rules2 is this ruleset) via ssh, but then my connection closed, and I was unable to reconnect via ssh until flushing the rules and loading this ruleset: pass in all pass out all Should suffice just to flush the rules, unless you compile your kernel with default block. Whatever default is, it is always a good idea for clarity to include a catch all rule. Also, make sure to add log and start ipmon, when something falls through or is blocked for other reasons, you have a log entry stating which rule blocked so you can debug your ruleset. - I see I left it out in the default rules I suggested, these rules should go at top of the file: block out log all block in log all Whatever falls through your ruleset will be logged so you can analyse it. When you flush your rulesets, the state table is not flushed, so you shouldn't loose your connection. Also, I recommend you reading rules into the inactive ruletable first. Then swap. This way you make sure your rules does not contain typos and you don't leave your firewall/host vulnerable. # ipf -IFa ipf -I -f rulefile ipf -s sleep 60 ipf -s lets you test the new ruleset 60 seconds, should you loose connection. If things work then # ipf -Ifa ipf -I -f rulefile ipf -s ipf -IFa Cheers, Erik -- Ph: +34.666334818 web: www.locolomo.org S/MIME Certificate: http://www.locolomo.org/crt/2004071206.crt Subject ID: A9:76:7A:ED:06:95:2B:8D:48:97:CE:F2:3F:42:C8:F2:22:DE:4C:B9 Fingerprint: 4A:E8:63:38:46:F6:9A:5D:B4:DC:29:41:3F:62:D3:0A:73:25:67:C2 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
