Brian J. Murrell wrote:
> On Sat, 2009-01-31 at 20:10 -0800, Tom Eastep wrote:
>> It seems like 90+% of DNS queries against my name server are DDoS:
>>
>> Counters reset Sat Jan 31 19:02:01 PST 2009
>>
>> Chain DNSDDOS (1 references)
>>  pkts bytes target     prot opt in     out     source
>> destination
>>  4675  210K DROP       all  --  *      *       0.0.0.0/0
>> 0.0.0.0/0           STRING match "|010000010000000000000000020001|" ALGO
>> name bm FROM 29 TO 30
>>   330 23531 ACCEPT     all  --  *      *       0.0.0.0/0
>> 0.0.0.0/0
>> gateway:/etc/shorewall #
> 
> Damn.  I have an iptables installation with the older, 1.3.3 string
> match which doesn't support the --algo, --from and --to modifiers.
> 
> What are the --to and --from arguments?  I would guess bytes offset from
> somewhere, probably the packet start.
> 
> But 29-30 is only two bytes.  How does that compute with "hex-string" of
> "|010000010000000000000000020001|"?
> 
> Thanx for any clarification you can provide.

As is normally the case with iptables/Netfilter, documentation is
practically non-existent; you get to learn how it works by a combination
of code reading and experimentation.

From what I've gleaned, --from and --to specify a byte offset range from
the beginning of the IP header that is to be searched for *the first
byte of the pattern*. The signature pattern begins at byte offset 30. I
have changed the DNSDDOS file to specify "--from 30 --to 31" rather than
"--from 29 --to 30"; while either way works, there is no point at
looking at offset 29.

The implementation is somewhat broken in my view. When the rule is being
loaded into the kernel, an error is raised if from_offset > to_offset.
But if the two are equal, no searching occurs because the search itself
starts with "if from_offset + consummed >= to_offset then we're done"
where 'consummed' is the number of bytes already examined (initially zero).

So in practice, --from must be strictly less than --to.

Another thing to note: Just because you specify --hex-string rather than
--string doesn't cause the following string to be interpreted as a hex
string! To be considered a hex string, it must begin and ends with '|'.
I wasted a good hour yesterday before I did enough code reading to grok
that undocumented 'feature'.

As a side note, the rate of attack seems to be down this morning, I'm
only seeing 40-50% bogus queries.

-Tom
-- 
Tom Eastep        \ When I die, I want to go like my Grandfather who
Shoreline,         \ died peacefully in his sleep. Not screaming like
Washington, USA     \ all of the passengers in his car
http://shorewall.net \________________________________________________

Attachment: signature.asc
Description: OpenPGP digital signature

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Reply via email to