http://blog.gmane.org/gmane.network.opennic.general hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.network.opennic.general/8748 <pre> If you're blocking on box then you are still going to be receiving a load of traffic. There is no way to stop the inbound traffic. However by not responding you should see the traffic drop by a half. I had to kill a DNS server off last year as the inbound traffic was still killing me in B/W costs. --julian -------- You are a member of the OpenNIC Discuss list. You may unsubscribe by emailing discuss-unsubscribe&lt; at &gt;lists.opennicproject.org </pre> Julian DeMarchi 2013-05-23T00:26:37 http://permalink.gmane.org/gmane.network.opennic.general/8747 <pre>heya guys-- OpenNIC is pleased to now take donations! We offer paypal and bitcoin donations. While paypal is the most popular way to pay online these days, we do realize there are security concerns and thus we welcome any ideas for further consideration. If you would like to donate funds in another way, please email alex at alex [AT] opennicproject [DOT] org and we can see what we can do for you. Rest assured that these donations are put only towards the maintenance of OpenNIC infrastructure. As we are able to receive more donations, we will be able to add additional services and servers to our global community. Once again, please feel free to contact Alex by email or on the OpenNIC IRC (purrdeta) if you have any questions or concerns. --julian -------- You are a member of the OpenNIC Discuss list. You may unsubscribe by emailing discuss-unsubscribe&lt; at &gt;lists.opennicproject.org </pre> Julian DeMarchi 2013-05-23T00:23:26 http://permalink.gmane.org/gmane.network.opennic.general/8746 <pre>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&lt; at &gt;runbox.com wrote: -------- You are a member of the OpenNIC Discuss list. You may unsubscribe by emailing discuss-unsubscribe&lt; at &gt;lists.opennicproject.org </pre> Jeff Taylor 2013-05-21T22:24:57 http://permalink.gmane.org/gmane.network.opennic.general/8745 <pre>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 .&lt; at &gt;............%. 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 &lt;Root&gt;: type OPT Name: &lt;Root&gt; 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 &lt;shdwdrgn&lt; at &gt;sourpuss.net&gt; To: discuss&lt; at &gt;lists.opennicproject.org Subject: Re: [opennic-discuss] iptables rules inefficient ----- End Original Message ----- -------- You are a member of the OpenNIC Discuss list. You may unsubscribe by emailing discuss-unsubscribe&lt; at &gt;lists.opennicproject.org </pre> kennytaylor< at >runbox.com 2013-05-21T20:26:49 http://permalink.gmane.org/gmane.network.opennic.general/8744 <pre>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&lt; at &gt;runbox.com wrote: -------- You are a member of the OpenNIC Discuss list. You may unsubscribe by emailing discuss-unsubscribe&lt; at &gt;lists.opennicproject.org </pre> Jeff Taylor 2013-05-21T19:08:57 http://permalink.gmane.org/gmane.network.opennic.general/8743 <pre>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 &lt;shdwdrgn&lt; at &gt;sourpuss.net&gt; To: discuss&lt; at &gt;lists.opennicproject.org Subject: Re: [opennic-discuss] iptables rules inefficient ----- End Original Message ----- -------- You are a member of the OpenNIC Discuss list. You may unsubscribe by emailing discuss-unsubscribe&lt; at &gt;lists.opennicproject.org </pre> kennytaylor< at >runbox.com 2013-05-21T15:44:22 http://permalink.gmane.org/gmane.network.opennic.general/8742 <pre>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&amp;clicking. On 05/20/2013 09:04 AM, kennytaylor&lt; at &gt;runbox.com wrote: -------- You are a member of the OpenNIC Discuss list. You may unsubscribe by emailing discuss-unsubscribe&lt; at &gt;lists.opennicproject.org </pre> Jeff Taylor 2013-05-21T15:07:02 http://permalink.gmane.org/gmane.network.opennic.general/8741 <pre>Thanks for your answer. However I just found out the filter is actually efficient, just the dnstop tool captures the packets before they are filtered. Now I use "dnstop eth0 -R" to see only DNS replies instead of queries, and there is nothing with "isc.org" or "ripe.net". Sorry about this mistake. 2013/5/20 &lt;kennytaylor&lt; at &gt;runbox.com&gt; -------- You are a member of the OpenNIC Discuss list. You may unsubscribe by emailing discuss-unsubscribe&lt; at &gt;lists.opennicproject.org </pre> Psilo 2013-05-20T16:11:27 http://permalink.gmane.org/gmane.network.opennic.general/8740 <pre>(sorry, hit the send button too early) 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 2/second per source IP (matches root zone ANY queries) - Drop all 56-byte packets in excess of above rule - Allow all other UDP DNS traffic That has limited the attack traffic generated to around 500 kbit/sec, which is much more manageable. Here's the raw iptables rules I'm using: ## Rate limit 64-byte queries (ANY against isc.org) iptables -A TO-NS1 -d &lt;dns_server_IP&gt; -p udp --dport 53 -m length --length 64 -m hashlimit --hashlimit-srcmask 32 --hashlimit-mode srcip --hashlimit-upto 1/s --hashli$ iptables -A TO-NS1 -d &lt;dns_server_IP&gt; -p udp --dport 53 -m length --length 64 -j DROP -m comment --comment "Drop all other 64-byte DNS queries" ## Rate limit ANY queries against the root zone iptables -A TO-NS1 -d &lt;dns_server_IP&gt; -p udp --dport 53 -m length --length 56 -m hashlimit --hashlimit-srcmask 32 --hashlimit-mode srcip --hashlimit-upto 2/s --hashli$ iptables -A TO-NS1 -d &lt;dns_server_IP&gt; -p udp --dport 53 -m length --length 56 -j DROP -m comment --comment "Drop all other 56-byte DNS queries" Hope that helps, Kenny ----- End Original Message ----- -------- You are a member of the OpenNIC Discuss list. You may unsubscribe by emailing discuss-unsubscribe&lt; at &gt;lists.opennicproject.org </pre> kennytaylor< at >runbox.com 2013-05-20T15:10:09 http://permalink.gmane.org/gmane.network.opennic.general/8739 <pre>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 &lt;dns&lt; at &gt;psilo.org&gt; To: "discuss&lt; at &gt;lists.opennicproject.org" &lt;discuss&lt; at &gt;lists.opennicproject.org&gt; Subject: [opennic-discuss] iptables rules inefficient ----- End Original Message ----- -------- You are a member of the OpenNIC Discuss list. You may unsubscribe by emailing discuss-unsubscribe&lt; at &gt;lists.opennicproject.org </pre> kennytaylor< at >runbox.com 2013-05-20T15:04:29 http://permalink.gmane.org/gmane.network.opennic.general/8738 <pre>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&lt; at &gt;lists.opennicproject.org </pre> Psilo 2013-05-20T14:23:00 http://permalink.gmane.org/gmane.network.opennic.general/8737 <pre>Today 03-May-2013 09:28:56.865 queries: info: client 91.211.118.145#38317: query: anticardsharing.net IN TXT +E 03-May-2013 09:28:56.865 client: warning: client 91.211.118.145#38317: error sending response: not enough free resources 03-May-2013 09:28:56.869 queries: info: client 91.207.4.146#64628: query: anticardsharing.net IN TXT +E 03-May-2013 09:28:56.869 client: warning: client 91.207.4.146#64628: error sending response: not enough free resources i'm blocking with packet filter block in quick on $wanif proto { tcp udp } from 91.207.4.0/24 to any *dkcorp.ec* | *CEO* *Enterprise Networks* Blog: unixlegion.com GPG Key: *0xBBDC0CDE* OpenNIC Project: opennic.sle.ec *IT Security - ISO 27000 - Packet Core* Phone: +593 995 956811 | +593 07 2952-763 On Sat, Apr 6, 2013 at 11:26 PM, Jeff Taylor &lt;shdwdrgn&lt; at &gt;sourpuss.net&gt; wrote: -------- You are a member of the OpenNIC Discuss list. You may unsubscribe by emailing discuss-unsubscribe&lt; at &gt;lists.opennicproject.org </pre> Killman BOFH 2013-05-03T14:38:55 http://permalink.gmane.org/gmane.network.opennic.general/8736 <pre> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - From an end-user perspective, I found OpenNIC Wizard to work pretty well during these periods of DoS attacks, it seems to be able to adapt well to changing conditions pretty quickly. For instance I was just remote with a laptop that I don't usually take with me, and it had a fixed IP address pointing to one of my OpenNIC T2 servers. The DNS server began to choke up, and my client-end performance started suffering terribly. I fired up OpenNIC Wizard on the laptop and in a minute or two it had pretty much settled on the best performing set of alternates for me, and I was back to near normal levels of performance. I need to push another OpenNIC Wizard update out, the last one's getting long in the tooth and I've got a number of patches to make. One of these days. - --Mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRg7iaAAoJEA7EcEr0emgfA+0H/jDqBQk2GJweNFrunPUmQ86Y tZn9fCPYkLDfvpeOcMKWspLpBchT5g/D8zHH25fXQyZfOpfR+1R7HaCEzwErRVfo yEUsaaV+4iLRVBnVjl2yOspNTBJPIDNmxDg6b7U2KSjqMvtWYJn+z4nOpjhl48iz +P4Ccrz2dLBa0z1wxL1cTFffvZ2I1jqBmvjnfoah1/7eVmfXa+ShhAQt5N/5F+bs lxNtVk8kB6bilLHNx6eyqSGQaLkibtxiAIieWuDB5FaVOIgx/418ExZGOeq6Ycu0 3c9S9OJy8rYKVv9rtV06gDqEZm1AUYOwLybAEdJcN2sV0JXPf3s9THdRYz7y5EE= =JcaJ -----END PGP SIGNATURE----- -------- You are a member of the OpenNIC Discuss list. You may unsubscribe by emailing discuss-unsubscribe&lt; at &gt;lists.opennicproject.org </pre> mike 2013-05-03T13:16:15 http://permalink.gmane.org/gmane.network.opennic.general/8735 <pre>Hi, Some updates. Saw this query today: 02-May-2013 17:52:42.521 queries: info: client 109.3.51.194#80: query: . IN RRSIG +E (106.186.17.181) Looks like the high school kids attacking us can read mailing lists or something. This should be pretty trivial to block but I wanted to share it in advance in case some of you hadn't seen the pattern yet. On Mon, Apr 29, 2013 at 10:32 PM, Jeff Taylor &lt;shdwdrgn&lt; at &gt;sourpuss.net&gt; wrote: -------- You are a member of the OpenNIC Discuss list. You may unsubscribe by emailing discuss-unsubscribe&lt; at &gt;lists.opennicproject.org </pre> Guillaume Parent 2013-05-02T18:04:43 http://permalink.gmane.org/gmane.network.opennic.general/8734 <pre>I logged the source IP's for about 8 hours one day and got around 750 unique IP's. These were all over the globe and seemed to have no relation to each other, other than the obvious clusters in certain subnets. Kenny, you mentioned seeing new IP's coming up after blocking the current ones, and I think I may know what happened. When I was watching for a period of time, I noticed the same, usually around 4 source IPs attacking at once, however each IP would rotate out every 3-5 minutes for a new address. It may not have been that the attacked detected your blocks, but rather that the source IP was simply getting rotated out at the same time you were blocking the addresses? I've had a nice quiet week with no attacks, but unfortunately they started back up again today. I don't know why... the packet they are sending has been blocked by iptables since February. Obviously the person(s) running the attack are too stupid to pay attention to the effectiveness of the DNS hosts they are using. "Gee why hasn't my attack taken down my target yet? Oh I'm wasting all my bandwidth on DNS servers that aren't playing my game..." On 04/29/2013 05:25 PM, Alex M (Coyo) wrote: -------- You are a member of the OpenNIC Discuss list. You may unsubscribe by emailing discuss-unsubscribe&lt; at &gt;lists.opennicproject.org </pre> Jeff Taylor 2013-04-30T02:32:04 http://permalink.gmane.org/gmane.network.opennic.general/8733 <pre> are these source ip addresses related to each other in any way? in other words, what does rdns say about these source ip addresses? do they make sense as an attack target? -------- You are a member of the OpenNIC Discuss list. You may unsubscribe by emailing discuss-unsubscribe&lt; at &gt;lists.opennicproject.org </pre> Alex M (Coyo 2013-04-29T23:25:31 http://permalink.gmane.org/gmane.network.opennic.general/8732 <pre>The incoming stream of queries isn't a problem, the outbound 10mbit+ stream is a problem. The block takes effect after 3 queries on my end and it gets stopped pretty much instantly. On Mon, Apr 29, 2013 at 5:44 PM, mike &lt;mike&lt; at &gt;pikeaero.com&gt; wrote: -------- You are a member of the OpenNIC Discuss list. You may unsubscribe by emailing discuss-unsubscribe&lt; at &gt;lists.opennicproject.org </pre> Guillaume Parent 2013-04-29T21:48:00 http://permalink.gmane.org/gmane.network.opennic.general/8731 <pre> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/29/2013 05:37 PM, Guillaume Parent wrote: I wouldn't say defeat, mitigate perhaps. The packets still arrive, and with rotating banks of source IPs apparently, the mitigation does not last long. - --Mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRfunCAAoJEA7EcEr0emgfE8cH/jPToUCn34O67+vCwGjSEgq8 JmY2JT9B22iqLe5CWbfxDhP4PvRl9YXbdOcLc2AFto1V7E/RGBCfERzfh+KIz/ij ifFFcjwkgCKHyOMYT7tt899t2yjMekRCA1gRVPX11rMCVlm8wW6RpclkFhW7mIFt 13kY9q3p9uV8U8oQxBGr1DtblxaQlMOiseePKWNDeRsNnPyUWVQvgGjhUW9jMU5n j4qvQt0Pr9tcReCOt8tcch/whjSVeHUelxvrHQNTWV6juqdvRhvKujO8oMbaOvjn DI91zh0Bhaqgu8/PzKFE7jUI47FkPUSs3QEshU7/pmIIthqBx7lRz/ZLludprHA= =0oA8 -----END PGP SIGNATURE----- -------- You are a member of the OpenNIC Discuss list. You may unsubscribe by emailing discuss-unsubscribe&lt; at &gt;lists.opennicproject.org </pre> mike 2013-04-29T21:44:39 http://permalink.gmane.org/gmane.network.opennic.general/8730 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/29/2013 04:17 PM, Alex M (Coyo) wrote: No need to pull the plug. I use the RRL patch w/ slip 1 (so everything that would be blocked is simply returned as a truncated answer, which a legit DNS client should retry over TCP), but I also explicitly block any IN/ANY/ISC.ORG queries over UDP: iptables -A INPUT -p udp -m udp --dport 53 -m string --hex-string "|03697363036f72670000ff0001|" --algo kmp --to 65535 -j DROP If one really needs that specific query against my resolvers, use TCP. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRfuj8AAoJEKDJEQNczrCUy60H/Rftz6lMOM7nVbw9bbWhUWYl JTOrSAaRa6hMAKFJS/6Z/SyjxMsOkEIYHdoEa5lMc6AyMyLwsVYcghh4sf6nuHEW RsnJb6cNn1B/VLJF4rkjjgv+dbvyZflqS60J/xtKQEl6N5Lh6Gz0i65yYg8jMiqa MDmEbPg4VtAU6L69jELwHFflTAQ35yAsbPo7pBws1bUyCzFmVDCZmGyQiVdkQ5If NrGXCALT6XGmA6OQKj/l3nPl5sSvYEdGtFXUnSFDi6oZxsArlQz/7NDYYXCHwZB3 q45x294usDZPSyhigKeNeCxCThC92c6pbYV02xYvGMmW+9g55AfeohXpqU83TE8= =hHuN -----END PGP SIGNATURE----- -------- You are a member of the OpenNIC Discuss list. You may unsubscribe by emailing discuss-unsubscribe&lt; at &gt;lists.opennicproject.org </pre> Bersl 2013-04-29T21:41:26 http://permalink.gmane.org/gmane.network.opennic.general/8729 <pre>The tier 2 security page shows how to trivially defeat these attacks through netfilter. It is available on the wiki. The target is the source IP address, not isc.org. On Mon, Apr 29, 2013 at 5:17 PM, Alex M (Coyo) &lt;coyo&lt; at &gt;darkdna.net&gt; wrote: -------- You are a member of the OpenNIC Discuss list. You may unsubscribe by emailing discuss-unsubscribe&lt; at &gt;lists.opennicproject.org </pre> Guillaume Parent 2013-04-29T21:37:20 http://permalink.gmane.org/gmane.network.opennic.general/8728 <pre> Unfortunately, I have little experience with server administration, and have never had the pleasure of attempting to mitigate or thwart an attack on server and network infrastructure I was responsible for, and whose attack I'd be blamed for. I'd say the dampening patch and throttling may help, but you may need to pull the plug on those resolvers in the short term to thwart the attack upon isc.org. -------- You are a member of the OpenNIC Discuss list. You may unsubscribe by emailing discuss-unsubscribe&lt; at &gt;lists.opennicproject.org </pre> Alex M (Coyo 2013-04-29T21:17:05 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.network.opennic.general