Re: [leaf-user] Need Help Debugging Firewall Rules - Dachstein
Vintage wrote: > > Michael - many thanks for the help - that did the trick. Just one question, > is there any danger to having these two rules at the top of my firewall > rules list? (See bottom of my note for output of "ipchains -nvL" Actually, this is desirable. Look at it this way, ipchains are a set of sieves stacked one above the other. Packets enter the `chain' and drop through the sieves; and, those that come out the other end are those that you want inside your network. The main issue here is building an exhaustive list of packet characteristics the likes of which you do *not* want to see in your network. Once you know this, then you build your chains and go on with life. Fortunately for us, Charles has constructed a very favorable set of chains and stacked sieves. For sake of efficiency (read cpu cycles), it is best to eliminate packet types in decreasing order of their frequency/volume -- in that way, these high volume pests are eliminated by using the fewest possible cpu cycles. Bear in mind, it is not always possible, nor practical, to build it this way, and the more general set comes default in dcd. [ snip ] > Output of "ipchains -nvL" (also, I am not sure why I am blocking 66.26.39.63 > or how that rule got there, but not a big deal...): [ snip ] > 0 0 DENY all l- 0xFF 0x00 eth0 > 192.168.1.0/24 0.0.0.0/0 n/a > 0 0 DENY all l- 0xFF 0x00 eth0 > 66.26.39.63 0.0.0.0/0 n/a > 0 0 REJECT all l- 0xFF 0x00 eth0 > 0.0.0.0/0127.0.0.0/8 n/a [ snip ] I do not know where this comes from; but, you probably should figure that out; unless, of course, you will never be interested in what rdu26-39-063.nc.rr.com has to say ;> Sequence of that rule makes me wonder whether or not somebody has diddled with your /etc/ipfilter.conf file . . . hth -- Best Regards, mds mds resource 888.250.3987 Dare to fix things before they break . . . Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
RE: [leaf-user] Need Help Debugging Firewall Rules - Dachstein
520 -> * 0 0 RETURN tcp -- 0xFF 0x00 * 0x1 0.0.0.0/00.0.0.0/0 * -> 179 0 0 RETURN tcp -- 0xFF 0x00 * 0x1 0.0.0.0/00.0.0.0/0 179 -> * 0 0 RETURN tcp -- 0xFF 0x00 * 0x1 0.0.0.0/00.0.0.0/0 * -> 53 0 0 RETURN tcp -- 0xFF 0x00 * 0x1 0.0.0.0/00.0.0.0/0 53 -> * 10 636 RETURN udp -- 0xFF 0x00 * 0x1 0.0.0.0/00.0.0.0/0 * -> 53 4 836 RETURN udp -- 0xFF 0x00 * 0x1 0.0.0.0/00.0.0.0/0 53 -> * 0 0 RETURN tcp -- 0xFF 0x00 * 0x2 0.0.0.0/00.0.0.0/0 * -> 23 0 0 RETURN tcp -- 0xFF 0x00 * 0x2 0.0.0.0/00.0.0.0/0 23 -> * 0 0 RETURN tcp -- 0xFF 0x00 * 0x2 0.0.0.0/00.0.0.0/0 * -> 22 0 0 RETURN tcp -- 0xFF 0x00 * 0x2 0.0.0.0/00.0.0.0/0 22 -> * -Vintage -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Michael D. Schleif Sent: Monday, June 03, 2002 11:40 AM Cc: [EMAIL PROTECTED] Subject: Re: [leaf-user] Need Help Debugging Firewall Rules - Dachstein Vintage wrote: > > I have searched the FAQs and mail archives but could not find the solution. > I am currently running Dachstein (CD version) on the Road Runner cable > network. As might be expected on a cable network, my logs quickly overfill > with the following noise: > > Every few seconds - > > Jun 3 10:50:30 firewall kernel: Packet log: input DENY eth0 PROTO=17 > 10.40.32.1:67 255.255.255.255:68 L=333 S=0x80 I=31378 F=0x T=255 (#9) > > Every three minutes - > > Jun 3 10:49:58 firewall kernel: Packet log: input DENY eth0 PROTO=2 > 192.168.100.1:65535 224.0.0.1:65535 L=28 S=0xC0 I=0 F=0x T=1 (#11) > > Thus, I added the following two rules to my Network.conf file. > > > ## > #Ignored Traffic: > > ## > > SILENT_DENY="17_10.40.32.1_68" > SILENT_DENY="all_224.0.0.0/4" > > > ## [ snip ] First off, by declaring SILENT_DENY twice (2x), the second cancels, or overwrites, the first. Consider this: SILENT_DENY="17_10.40.32.1_68 all_224.0.0.0/4" However, this is not all of your problem ;> Notice the format for SILENT_DENY: Format: protocol_srcip[/mask][_dstport] `srcip' means, literally, source ip address -- you have used the _destination_ address for your second instantiation. Unfortunately, SILENT_DENY cannot, yet, deal with destinations. You are going to need to use the constructs that immediately follow in /etc/network.conf: IPCH_IN=/etc/ipchains.input IPCH_FWD=/etc/ipchains.forward IPCH_OUT=/etc/ipchains.output Actually, since the errors that you want to ignore are both input entries; so, you will need to create a /etc/ipchains.input -- and backup when you are done. You might want to be specific, like the following, or broaden the protocol to `all' and/or broaden the destination to 224.0.0.0/4: $IPCH -I input -j DENY -p 2 -s 0/0 -d 224.0.0.1 -i $EXTERN_IF hth -- Best Regards, mds mds resource 888.250.3987 Dare to fix things before they break . . . Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Need Help Debugging Firewall Rules - Dachstein
Vintage wrote: > > I have searched the FAQs and mail archives but could not find the solution. > I am currently running Dachstein (CD version) on the Road Runner cable > network. As might be expected on a cable network, my logs quickly overfill > with the following noise: > > Every few seconds - > > Jun 3 10:50:30 firewall kernel: Packet log: input DENY eth0 PROTO=17 > 10.40.32.1:67 255.255.255.255:68 L=333 S=0x80 I=31378 F=0x T=255 (#9) > > Every three minutes - > > Jun 3 10:49:58 firewall kernel: Packet log: input DENY eth0 PROTO=2 > 192.168.100.1:65535 224.0.0.1:65535 L=28 S=0xC0 I=0 F=0x T=1 (#11) > > Thus, I added the following two rules to my Network.conf file. > > > ## > #Ignored Traffic: > > ## > > SILENT_DENY="17_10.40.32.1_68" > SILENT_DENY="all_224.0.0.0/4" > > > ## [ snip ] First off, by declaring SILENT_DENY twice (2x), the second cancels, or overwrites, the first. Consider this: SILENT_DENY="17_10.40.32.1_68 all_224.0.0.0/4" However, this is not all of your problem ;> Notice the format for SILENT_DENY: Format: protocol_srcip[/mask][_dstport] `srcip' means, literally, source ip address -- you have used the _destination_ address for your second instantiation. Unfortunately, SILENT_DENY cannot, yet, deal with destinations. You are going to need to use the constructs that immediately follow in /etc/network.conf: IPCH_IN=/etc/ipchains.input IPCH_FWD=/etc/ipchains.forward IPCH_OUT=/etc/ipchains.output Actually, since the errors that you want to ignore are both input entries; so, you will need to create a /etc/ipchains.input -- and backup when you are done. You might want to be specific, like the following, or broaden the protocol to `all' and/or broaden the destination to 224.0.0.0/4: $IPCH -I input -j DENY -p 2 -s 0/0 -d 224.0.0.1 -i $EXTERN_IF hth -- Best Regards, mds mds resource 888.250.3987 Dare to fix things before they break . . . Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
