Discuss mailing list

[Killman BOFH <killman AT dkcorp.ec>]

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 <shdwdrgn AT sourpuss.net> wrote:

Unfortunately ddos.pl is not set up to handle this particular problem.  Since we've had good results with the iptables rules for blocking this issue, I haven't taken the time to try and write new methods into the script.

On 04/06/2013 09:58 PM, David Norman wrote:

I'm not going to put a lot of effort into hosting
ga.us.dns.opennic.glue. If the garbage continues, I'll probably just
turn Bind off. I do real business on that VM and don't really need
people tagging it as a pawn in the middle of DDoS attacks.

Adding these rules to my startup for rc.local basically broke my DNS
service. I've removed them for now, which makes me largely dependent
on ddos.pl again. Should it really take an hour or two for that to
stop this stuff?

iptables -I INPUT -p udp -m hashlimit --hashlimit-srcmask 24

--hashlimit-mode srcip --hashlimit-upto 50/m --hashlimit-burst 10

--hashlimit-name DNSTHROTTLE --dport 53 -j ACCEPT
iptables -I INPUT -p udp -m udp --dport 53 -j DROP

On 4/6/13 11:25 PM, Kenny Taylor wrote:
> Being UDP, the source address is likely spoofed.  At least that's
> what I was seeing.  The attackers seemed to rotate through a few
> spoofed source addresses.


> David Norman <deekayen AT deekayen.net> wrote:

>> I had some abusive ANY queries today. I had everything on the
>> Tier2Security wiki page except the hash limit. Since I don't log,
>> I had to tcpdump; greping that for ANY made the offender very
>> obvious.

>> It took the ddos.pl script 1h10m to figure out what was going on
>> a block all queries from the main offender. Now I've added the
>> hash limits in iptables but at 50 instead of 30. I think it
>> probably ought to go even higher than 50. At the rate they were
>> querying, there's still a big difference between a high volume
>> user and being part of a DoS.

>> On Apr 3, 2013, at 10:25 AM, Aaron J. Angel
>> <thatoneguy AT aaronjangel.us> wrote:

>>> On 04/03/2013 09:52 AM, Jeff Taylor wrote:
>>>> I'm also not sure about the +E, but take a look at the
>>>> tcpdump
>> section
>>>
>>> Recursion requested (+).  EDNS0 enabled (E); that is, large
>>> DNS
>> messages.
>>>
>>>> I'm starting to wonder if we should make it a policy to drop
>>>> all ANY requests?  It seems that is the key factor behind all
>>>> of these
>> attacks,
>>>> and other than the servers talking between themselves, I
>>>> don't know
>> of
>>>> any use a client would have for such a query.
>>>
>>> This doesn't resolve the problem, it just covers it up a
>>> portion of
>> it.
>> http://www.corecom.com/external/livesecurity/dnsamplification.htm
>>>
>>>>
>>
On 04/02/2013 11:53 PM, kennytaylor AT runbox.com wrote:
>>>>> I'm not entirely sure offhand what that query is asking
>>>>> for.
>>>
>>> The query (. IN ANY) is requesting all records for the root
>>> zone. As
>> you can imagine, that's a fairly hefty request to be made that
>> often. Likely the result of the previous request (z.tn.co.za ANY
>> ANY) being blocked by name servers claiming authority for
>> z.tn.co.za, then serving no results.  (Apparently, that domain
>> had a rather large TXT record.)
>>>
>>>
>>> -------- 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




> -------- 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