Skip to Content.
Sympa Menu

discuss - Re: [opennic-discuss] iptables rules inefficient

discuss AT lists.opennicproject.org

Subject: Discuss mailing list

List archive

Re: [opennic-discuss] iptables rules inefficient


Chronological Thread 
    < Chronological >      < Thread >
  • From: Jeff Taylor <shdwdrgn AT sourpuss.net>
  • To: discuss AT lists.opennicproject.org
  • Subject: Re: [opennic-discuss] iptables rules inefficient
  • Date: Tue, 21 May 2013 16:24:57 -0600
All of the packets from different source IP's that I have inspected today always have a TTL of 243 (0xF3). I think you might be on to something there, but the question is, is this something we can use?


On 05/21/2013 02:26 PM, kennytaylor AT runbox.com wrote:
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 -----


--------
You are a member of the OpenNIC Discuss list.
You may unsubscribe by emailing discuss-unsubscribe AT lists.opennicproject.org


Archive powered by MHonArc 2.6.19.

Top of Page