IRC Networks
Irc Logs Stats
Start date: 2007-09-27 02:48:27
Last update: 2008-10-24 20:19:38
Channels: 41
Logged Lines: 6230436
Size: 1834.70 MB
Powered by
Channel Info
Network: freenodeChannel: #iptables |
Search in www.irclog.org
Log from #iptables at freenode 2006-07-15
[17:50]<[lyguw]>lol
[17:51]<mrrynfmr>unless you have something turned off
[17:52]<[lyguw]>i havent
[17:52]<rlraxne>thats what they all say ;)
[17:53]<[lyguw]>lol
[17:53]<[lyguw]>i added it to autoload at bootup
[17:54]<[lyguw]>ok bye :)
[19:16]<rlraxne>any of you who have a hint of a ruleset regarding filtering bad packets ? somewhat how the module unclean was supposed to be used until netfilter decided to remove it from the kernel for odd reasons ?
[19:53]<vyrn-vnzsr>Apachez: something like -p ALL -m state --state INVALID -j DROP ?
[20:07]<rlraxne>yeah
[20:07]<rlraxne>but also including bad bitmasks of the flags
[20:07]<rlraxne>like ehh syn + push + ack or whatever "illegal" combinations there are
[20:16]<vyrn-vnzsr>Apachez: for port scan blocking?
[20:32]<rlraxne>yeah
[20:32]<rlraxne>i think pf's "scrub in all" checks like 7-8 different "illegal" states
[20:33]<rlraxne>states= flag combinaitons
[20:36]<rlraxne>right now I currently use:
[20:36]<rlraxne>iptables -A BADPACKET -m state --state INVALID -j BADPACKET_DROP
[20:36]<rlraxne>iptables -A BADPACKET -p tcp ! --syn -m state --state NEW -j BADPACKET_DROP
[20:46]<rnmrsqn66n>the ones that match most here are: --tcp-flags ALL NONE
[20:46]<rnmrsqn66n>all others don't really care (<10% of "illegal" states)
[20:47]<rlraxne>hmm
[20:48]<rlraxne>since i have among other suggestions also found http://www.tbg.nu/temp.txt
[20:49]<rlraxne>so the question in my case is if there are some "official" list of bad flags ?
[20:50]<rnmrsqn66n>that's almost the list I'm using.
[20:52]<rlraxne>mind sharing your list ? :P
[20:54]<cjcjcjw>quick question NAT is protocol?
[20:54]<rlraxne>nope
[20:54]<rlraxne>nat is a ehh functionality
[20:54]<rlraxne>network address translation
[20:55]<rlraxne>basically changing source ip into the external ip
[20:55]<cjcjcjw>are yoi usure?
[20:55]<cjcjcjw>sure*
[20:55]<rlraxne>and then have a track so when a reply comes specially with stateful inspection the wall knows that "ahh this is legit packet, send it through"
[20:57]<rlraxne>http://www.cisco.com/en/US/products/hw/switches/ps708/products_command_reference_chapter09186a008035054c.html
[20:57]<rlraxne>here you have a list of protocols
[20:57]<cjcjcjw>http://tcpipguide.com/free/t_IPNetworkAddressTranslationNATProtocol.htm
[20:58]<rnmrsqn66n>(3623 pkts) $IPT -t mangle -A PREROUTING -p tcp --tcp-flags ALL FIN,URG,PSH -j DROP
[20:58]<rnmrsqn66n>(20 pkts) $IPT -t mangle -A PREROUTING -p tcp --tcp-flags ALL ALL -j DROP
[20:58]<rnmrsqn66n>(16 pkts) $IPT -t mangle -A PREROUTING -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP
[20:58]<rnmrsqn66n>(118M! pkts) $IPT -A [INPUT|FORWARD] -p tcp --tcp-flags ALL NONE -j REJECT
[20:58]<rnmrsqn66n>(300 pkts) $IPT -t mangle -A PREROUTING -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
[20:58]<rnmrsqn66n>(353 pkts) $IPT -t mangle -A PREROUTING -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
[20:58]<rnmrsqn66n>(7567 pkts) $IPT -t mangle -A PREROUTING -p tcp --tcp-flags FIN,ACK FIN -j DROP
[20:59]<rlraxne>aedAS24679: thanks
[20:59]<rlraxne>two questions... how come you have that in -t mangle ?
[20:59]<rlraxne>and seoncd... -A [INTPUT|FORWARD] is that the way to create one rule which will match in two different chains ?
[20:59]<rlraxne>or is it -A INPUT,FORWARD ?
[21:01]<rnmrsqn66n>a) I don't need to put that in INPUT *and* FORWARD; b) it don't need to traverse other rules.
[21:02]<rnmrsqn66n>-A [INPUT|FORWARD] - dunno, just have two separate rules.
[21:02]<rlraxne>oki tnx
[21:03]<rlraxne>a small follow up on the first answer... wouldnt that make also apply to OUTPUT aswell since its prerouting ?
[21:03]<rlraxne>or does mangling on occur before INPUT and FORWARD ?
[21:04]<rlraxne>on=only
[21:04]<rnmrsqn66n>hmm, oh, really good question. I'm not sure - may apply to OUTPUT as well... dunno.
[21:35]<rlraxne>aedAS24679: once you are back... what do you think of http://lists.netfilter.org/pipermail/netfilter/2004-November/057155.html ?
[21:53]<rnmrsqn66n>looks good, but for my estimation a little bit too many rules.
[21:53]<rnmrsqn66n>As you see on my list, there's only one single rule matching ~ 90 % of all "invalid" packets.
[21:53]<rlraxne>yup
[21:56]<rlraxne>do you have something like iptables -A BADPACKET -m state --state INVALID -j BADPACKET_DROP in your rules and if so do you perhaps have a counter on that ?
[21:56]<rlraxne>i was thinking of if i should place the invalid thingy first or last in my badpacket chain
[21:56]<rlraxne>because the ALL NONE looks like a winner for the pole position in that chain :P
[21:58]<rlraxne>another thing
[21:58]<rlraxne>I have checked your rules against some other suggestions and found one "major" difference
[21:58]<rlraxne> /sbin/iptables -A BADTCP -p tcp --tcp-flags ALL FIN -j PSCAN
[21:58]<rlraxne>(7567 pkts) $IPT -t mangle -A PREROUTING -p tcp --tcp-flags FIN,ACK FIN -j DROP
[21:59]<rlraxne>is the first one wider in its detection ?
[22:41]<rlraxne>an estimate to the cost of a ruleset is to simply just count number of rows which needs to be examined for a specific packet... but does a -j RETURN also cost like a regular rule ?
[22:54]<rlraxne>http://www.tbg.nu/iptables.txt i have now updated the badpacket rules...
[22:54]<rlraxne>in case someone is interrested :P







