Discuss mailing list

[<kennytaylor AT runbox.com>]

Wireshark detail below..  I don't see anything in the IP or UDP header that 
would be very useful.  Looking at the TTL field, that's going to indicate the 
number of hops from the source to the DNS server (255-TTL)..  That may give 
us an indication of whether all the spoofed packets are coming from the same 
source..

0000   92 f4 a2 f8 72 1c 00 11 0a 5a f9 99 08 00 45 00  ....r....Z....E.
0010   00 40 11 0c 00 00 e5 11 03 e7 2e 1d 14 12 25 01  .@............%.
0020   59 8a 63 01 00 35 00 2c 00 00 2a 39 01 00 00 01  Y.c..5.,..*9....
0030   00 00 00 00 00 01 03 69 73 63 03 6f 72 67 00 00  .......isc.org..
0040   ff 00 01 00 00 29 10 00 00 00 80 00 00 00        .....)........

Internet Protocol Version 4, Src: 46.29.20.18 (46.29.20.18), Dst: 37.1.89.138 
(37.1.89.138)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: 
Not-ECT (Not ECN-Capable Transport))
    Total Length: 64
    Identification: 0x110c (4364)
    Flags: 0x00
        0... .... = Reserved bit: Not set
        .0.. .... = Don't fragment: Not set
        ..0. .... = More fragments: Not set
    Fragment offset: 0
    Time to live: 229
    Protocol: UDP (17)
    Header checksum: 0x03e7 [correct]
    Source: 46.29.20.18 (46.29.20.18)
    Destination: 37.1.89.138 (37.1.89.138)
User Datagram Protocol, Src Port: 25345 (25345), Dst Port: domain (53)
    Source port: 25345 (25345)
    Destination port: domain (53)
    Length: 44
    Checksum: 0x0000 (none)
Domain Name System (query)
    Transaction ID: 0x2a39
    Flags: 0x0100 (Standard query)
        0... .... .... .... = Response: Message is a query
        .000 0... .... .... = Opcode: Standard query (0)
        .... ..0. .... .... = Truncated: Message is not truncated
        .... ...1 .... .... = Recursion desired: Do query recursively
        .... .... .0.. .... = Z: reserved (0)
        .... .... ...0 .... = Non-authenticated data: Unacceptable
    Questions: 1
    Answer RRs: 0
    Authority RRs: 0
    Additional RRs: 1
    Queries
        isc.org: type ANY, class IN
        Type: ANY (Request for all records)
        Class: IN (0x0001)
    Additional records
        <Root>: type OPT
            Name: <Root>
            Type: OPT (EDNS0 option)
            UDP payload size: 4096
            Higher bits in extended RCODE: 0x0
            EDNS0 version: 0
            Z: 0x8000
                Bit 0 (DO bit): 1 (Accepts DNSSEC security RRs)
                Bits 1-15: 0x0 (reserved)
            Data length: 0


----- Start Original Message -----
Sent: Tue, 21 May 2013 13:08:57 -0600
From: Jeff Taylor <shdwdrgn AT sourpuss.net>
To: discuss AT lists.opennicproject.org
Subject: Re: [opennic-discuss] iptables rules inefficient

> Ah ok , that makes sense.  I only see the byte-count that tcpdump gives me.
> Hmm, this makes me wonder if there's something in the headers that I'm 
> missing which might give more info about the origin of these packets?
> 
> 
> On 05/21/2013 09:44 AM, kennytaylor AT runbox.com wrote:
> > Heh yes.  The ISC.org packets I'm receiving look like this:
> >
> > IP Header:  20 bytes
> > UDP Header:  8 bytes
> > UDP Payload:  36 bytes
> >
> > So we're probably seeing the same thing.  The iptables rule just wants me 
> > to call that a 64-byte packet :)
> >
> >
> > ----- Start Original Message -----
> > Sent: Tue, 21 May 2013 09:07:02 -0600
> > From: Jeff Taylor <shdwdrgn AT sourpuss.net>
> > To: discuss AT lists.opennicproject.org
> > Subject: Re: [opennic-discuss] iptables rules inefficient
> >
> >> Your packets must be different than the ones I've seen.  The isc.org
> >> packets I typically get are 36 bytes in length.  I am also getting
> >> flooded with ANY queries for the root zone which are 28 bytes.  It would
> >> be nice if the little script kiddies were smart enough to realize their
> >> flood has been blocked for the last 3 months, but I guess that would
> >> require them to poses more intelligence than pointing&clicking.
> >>
> >>
> >> On 05/20/2013 09:04 AM, kennytaylor AT runbox.com wrote:
> >>> Hi Psilo,
> >>>
> >>> I have been doing battle with the isc.org ANY queries for a month or 
> >>> so.  Those queries are all 64 bytes in length, so I set iptables rules 
> >>> to handle 64-byte packets differently.  Basically this:
> >>>
> >>> - If packet length = 64, then allow up to 1/second per source IP    
> >>> (matches isc.org ANY queries)
> >>>       - Drop all 64-byte packets in excess of above rule
> >>> - If packet length = 56, then allow up to 1/second per source IP
> >>>
> >>> ----- Start Original Message -----
> >>> Sent: Mon, 20 May 2013 16:23:00 +0200
> >>> From: Psilo <dns AT psilo.org>
> >>> To: "discuss AT lists.opennicproject.org" 
> >>> <discuss AT lists.opennicproject.org>
> >>> Subject: [opennic-discuss] iptables rules inefficient
> >>>
> >>>> Dear OpenNIC,
> >>>>
> >>>> I have setup my iptables rules according to the wiki but still getting 
> >>>> a
> >>>> lot of unwanted traffic with isc.org and ripe.net.
> >>>> Here is the output of dnstop:
> >>>>
> >>>> Query Name           Count      %
> >>>> ---------------- --------- ------
> >>>> ripe.net               590   54.2
> >>>> isc.org                406   37.3
> >>>> cnr.it                  13    1.2
> >>>> akamaiedge.net           6    0.6
> >>>> 140.in-addr.arpa         6    0.6
> >>>> 125.in-addr.arpa         5    0.5
> >>>> 2-0.pl                   5    0.5
> >>>> 86.in-addr.arpa          5    0.5
> >>>> multi-play.pl            4    0.4
> >>>> multi-play.eu            4    0.4
> >>>> net.pl                   4    0.4
> >>>> 202.in-addr.arpa         3    0.3
> >>>> 46.in-addr.arpa          3    0.3
> >>>> 91.in-addr.arpa          3    0.3
> >>>>
> >>>> I have setup the following iptables rules which were supposed to block 
> >>>> this
> >>>> traffic:
> >>>>
> >>>> # isc.org
> >>>> -A DNSFILTER -p udp -m string --hex-string
> >>>> "|00000000000103697363036f726700|" --algo bm --dport 53 -j DROP
> >>>> # ripe.net
> >>>> -A DNSFILTER -p udp -m string --hex-string
> >>>> "|0000000000010472697065036e6574|" --algo bm --dport 53 -j DROP
> >>>>
> >>>> The "ddos.pl" script is neither efficient.
> >>>>
> >>>> I am getting annoyed by my provider who wants to cut the server 
> >>>> because of
> >>>> this traffic.
> >>>>
> >>>> Can you please help me figure what's wrong? Do you have a more 
> >>>> aggressive
> >>>> version of this filters?
> >>>>
> >>>> Thanks
> >>>> Psilo
> >>>>
> >>>>
> >>>> --------
> >>>> You are a member of the OpenNIC Discuss list.
> >>>> You may unsubscribe by emailing 
> >>>> discuss-unsubscribe AT lists.opennicproject.org
> >>> ----- End Original Message -----
> >>>
> >>>
> >>> --------
> >>> You are a member of the OpenNIC Discuss list.
> >>> You may unsubscribe by emailing 
> >>> discuss-unsubscribe AT lists.opennicproject.org
> >>
> >>
> >> --------
> >> You are a member of the OpenNIC Discuss list.
> >> You may unsubscribe by emailing 
> >> discuss-unsubscribe AT lists.opennicproject.org
> > ----- End Original Message -----
> >
> >
> > --------
> > You are a member of the OpenNIC Discuss list.
> > You may unsubscribe by emailing 
> > discuss-unsubscribe AT lists.opennicproject.org
> 
> 
> 
> --------
> You are a member of the OpenNIC Discuss list. 
> You may unsubscribe by emailing discuss-unsubscribe AT lists.opennicproject.org

----- End Original Message -----