Thanks a lot Rob Now is clear for me Have a nice weekend and happy New Christmas 80))) 2017-12-22 20:25 GMT-02:00 Robert White <rwhite@xxxxxxxxx>: > On 12/22/2017 08:52 PM, paulo bruck wrote: >> thanks Robert >> >> My bad 8( I choose a wrong example. >> >> Changing to kbytes now I see traffic throw rule. >> What I'm trying to understand is the sequence and meaning of limit >> taking different positions inside a rule. >> >> >> counter packets 7077 bytes 690164 limit rate 10 kbytes/minute counter >> packets 0 bytes 0 tcp sport http counter packets 0 bytes 0 log prefix >> "acesso a porta 80" flags all counter packets 0 bytes 0 >> >> If I use limit + tcp + log as above means: > > You are thinking about it too hard. > > Each rule is evaluated left-to-right. Every element has a "truth" value, > a boolean pass-fail. So things like "counter" and "log" are "always > true" (it has no "test-like action"). > > Other elements like "tcp dport http" are multiple tests in one, where > first it has to be "tcp" and, now that the tcp-ness is established the > packet is known to have a destination port, so the port number can be > compared to 80 (the http well known port) for equality. > > The first time you hit something that is "false" the rest of the line is > skipped. > > So mentally put the words "and then" between each directive. > > So :: counter and then limit rate 10 kbytes/minute and then counter and > then tcp sport http and then counter and then log prefix "whatever" > flags all and then counter > > A very few things break this rule. Like "accept" and "drop" are terminal > to the rule, and the chain, once you "accept" then the rest of the rule > and the rest of the chain just don't matter. > > So limit comes before action if you want that action to be limited by > that limit. > > Same for literally everything else. > > Now what this means is that order is important, but unlike iptables, you > can stack the non-terminal actions several deep in a rule, even > returning adding extra tests after one action and before the next. > > So you can make long and complex rules that get progressively more picky > about the packets that get to that point. > > The caraige return is like a "start-from-scratch" where the previous > rule is done and the condition is reset to "true". > > That is, any rule could be mentally rewritten as "true and then (rest of > rule). > > This is why you can just have a log statement as the whole rule if you > want to log every packet that hasn't yet hit a terminal like accept or > drop. Indeed a bare log rule at the end of a chain is a great way to log > all the packets that are about to hit the "policy" of the chain, or > which have otherwise gotten to the end of a sub-chain when you were > expecting to handle every possibility. > > So just relax and understand that the whole thing is "as you read", > while iptables was "test-and-do". > > So no, the limit isn't limiting "all packets that enter the rule", it > limits all packets that "get as far along the rule as the limit statement". > > So ... > > limit rate 10 kbytes/minute tcp dport http log "whatever" flags all > and > tcp dport http limit rate 10 kbytes/minute log "whatever" flags all > > produce completely different results. > > In the first one you are only considering 10 kilobytes a minute of > packets, then of that limited set you are logging the http requests. > > In the second one you are considering the first 10 kilobytes of http > requests per minute. > > So in the first rule the ssh and ftp and sip and dhcp and all the other > traffic are being considered in the limit, and then only the http is > being logged. This is almost certianly not what you want. > > In the second the http-ness is considered first, and then you limit the > logging rate. > > And of course it is not "10 kbytes of log" it's 10 kbytes of data" so if > you are sending large requests, and the Mtu is the nominal 1500 bytes > per packet, your ten kbytes is probably seven or eight packets a minute > total. > > See... thing, and then thing, and then thing... as you read. > > --Rob. -- Paulo Ricardo Bruck consultor tel 011 3596-4881/4882 011 98140-9184 (TIM) http://www.contatogs.com.br http://www.protejasuarede.com.br gpg AAA59989 at wwwkeys.us.pgp.net -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
