Sunday, January 5, 2014

Domain: pddos.com

Domain: pddos.com

If you are seeing queries for this domain, than you are likely participating in DNS Amplification attacks and your DNS server is probably reachable from the internet and has recursion enabled.

If you are seeing responses for this domain.. unlucky. You are currently beeing DDOS-ed! Good luck.


IPtables:


There are two iptable rules available. If your distribution supports Iptables 'u32' module pick this one, otherwise use the 'string' rule.

U32:
iptables --insert INPUT -p udp --dport 53 -m u32 --u32 "0x28&0xFFDFDFDF=0x05504444 && 0x2c&0xDFDFFFDF=0x4f530343 && 0x30&0xDFDFFF00=0x4f4d0000" -j DROP -m comment --comment "DROP DNS Q pddos.com"

More U32 rules can be found here:

https://github.com/smurfmonitor/dns-iptables-rules/blob/master/domain-blacklist.txt

String:
iptables --insert INPUT -p udp --dport 53 -m string --from 40 --to 51 --algo bm --hex-string '|057064646f7303636f6d00|' -j DROP -m comment --comment "DROP DNS Q pddos.com"
More Iptables rules for the STRING module can be found here:


https://github.com/smurfmonitor/dns-iptables-rules/blob/master/domain-blacklist-string.txt

Source:


No IP source for this domain

Name server:


;; ANSWER SECTION:
pddos.com. 600 IN NS ns1.spaceweb.ru.
pddos.com. 600 IN NS ns2.spaceweb.ru.


Response:


A 5
MX 43
NS 2
SOA 1
TXT 3
Rsize 3968


Whois



Whois Server Version 2.0

Domain names in the .com and .net domains can now be registered
with many different competing registrars. Go to http://www.internic.net
for detailed information.

Domain Name: PDDOS.COM
Registrar: ONLINENIC, INC.
Whois Server: whois.onlinenic.com
Referral URL: http://www.OnlineNIC.com
Name Server: NS1.SPACEWEB.RU
Name Server: NS2.SPACEWEB.RU
Status: clientTransferProhibited
Updated Date: 04-jan-2014
Creation Date: 04-jan-2014
Expiration Date: 04-jan-2015

>>> Last update of whois database: Sun, 05 Jan 2014 16:42:37 UTC <<<

NOTICE: The expiration date displayed in this record is the date the
registrar's sponsorship of the domain name registration in the registry is
currently set to expire. This date does not necessarily reflect the expiration
date of the domain name registrant's agreement with the sponsoring
registrar. Users may consult the sponsoring registrar's Whois database to
view the registrar's reported date of expiration for this registration.


The Registry database contains ONLY .COM, .NET, .EDU domains and
Registrars.


Registrant:
Burakosky Sergei Aleksandrovych mrinj@ya.ru +8.0504661325 +8.0504661325
SpaceWeb client
Petrozavodskii Str., 7
Harkov,n/a,RU 03119


Domain Name:pddos.com
Record last updated at
Record created on 1/4/2014
Record expired on 01/04/2015


Domain servers in listed order:
ns1.spaceweb.ru ns2.spaceweb.ru

Administrator:
Petrozavodskii Str., 7
Harkov
n/a,
RU
03119

name:(Burakosky Sergei Aleksandrovych)
mail:(mrinj@ya.ru) +8.0504661325
+8.0504661325
SpaceWeb client
Technical Contactor:
18 Tsvetochnaya str.
Saint-Petersburg
n/a,
RU
196084

name:(Igor Shakhbazyan)
mail:(domain.reg@sweb.ru) +7.8123341222
+7.8123341222
SpaceWeb JSC
Billing Contactor:
Petrozavodskii Str., 7
Harkov
n/a,
RU
03119

name:(Burakosky Sergei Aleksandrovych)
mail:(mrinj@ya.ru) +8.0504661325
+8.0504661325
SpaceWeb client

Registration Service Provider:
name: Spaceweb LLC
tel: +7.8123341222
fax: +7.8123341222
web:http://www.sweb.ru



5 comments:

  1. I am getting really sick and tired of the abuse of my DNS servers this way. I keep blocking these domains and a new one pops up 10 hours later.

    More domains: saveroads.ru, amp.crack-zone.ru, eschenemnogo.com, krasti.us, azmx.ru, fkfkfkfa.com, ddostheinter.net.

    I need a recursive DNS for mobile customers. I tried moving the servers' IPs (none are published anywhere) and the ****holes still find them within 24 hours, presumably using brute-force scans of IP blocks.

    ReplyDelete
  2. #
    # Block DNS queries for pddos.com - Jan 2014
    #
    # 6&0xFF=17 -- check for a UDP packet
    # && 4&0x1FFF=0 -- check for 1st fragment
    # && 0>>22&0x3C@ -- skip forward by len of IP header
    # 8>>8&0xF0=0x00 -- Skip UDP header, then check for DNS query (vs response)
    # && 0>>22&0x3C@ -- skip forward by len of IP header
    # 20&0xFFFFFFFF=0x05706464 -- Skip UDP header+DNS hdr, check for '.pdd' (05 70 64 64 0x5=5 chars. But big-endian, len=4)
    # && 0>>22&0x3C@ -- skip forward by len of IP header
    # 24&0xFFFFFFFF=0x6f730363 -- Skip UDP header+DNS hdr+'.pdd', check for 'os.c' (6f 73 03 63, 'os.c', len=4)
    #
    # Must drop pkts early and silently, in the mangle table, to avoid a tracked connection
    #
    $IPTABLES -t mangle -I PREROUTING -i ${WAN} -p udp --dport 53 -m u32 --u32 '6&0xFF=17 && 4&0x1FFF=0 && 0>>22&0x3C@ 8>>8&0xF0=0x00 && 0>>22&0x3C@ 20&0xFFFFFFFF=0x05706464 && 0>>22&0x3C@ 24&0xFFFFFFFF=0x6f730363' -j DROP

    ------

    I'm thinking of writing a script to auto-generate these rules based on a rate trigger.

    ReplyDelete
  3. I came up with the following OpenWRT script that will permanently kill the DDOSing attacks. It works without having to manually reconfigure iptables. This is basically a 'teergrube'. It is a well-known method in the anti-SPAM community to thwart spammers by wasting their resources.

    You are actively hindering the DDOS attack by tying up their amplification machines hitting a black hole.

    #
    # Anti-Bruteforce for DNS cache poisoning attacks and DNS DDOS amplification attacks.
    #
    # According to /proc/net/xt_recent/*, --hitcount max appears to be 18-20.
    #
    if iptables -N BRUTEDNS ; then
    : # create new chain
    else
    iptables -F BRUTEDNS
    fi
    # Jump if new connection (forwarding)
    iptables -I forwarding_wan -p udp -m state --state NEW --dport 53 -j BRUTEDNS
    # Jump if new connection (input)
    iptables -I input_wan -p udp -m state --state NEW --dport 53 -j BRUTEDNS
    iptables -A BRUTEDNS -m recent --update --seconds 3 --hitcount 18 --name BRUTEDNS -j DROP
    # --set must be last
    iptables -A BRUTEDNS -m recent --name BRUTEDNS --set

    Once the attacker hits the 18-query limit, the DNS server effectively shuts down and becomes a black hole. It remains a black hole until the attacker pauses for at least 3 seconds. Which, of course, they never do.

    This rate-limits incoming queries to 18 every 3 seconds. I picked 18 because the maximum supported --hitcount for the 'recent' module was set to 20 in OpenWrt Attitude Adjustment (12.09). Prior to that the max was 14. You can determine the max by inspecting the output 'cat /proc/net/xt_recent/*' The maximum number of packet IDs that you see listed for a single hit determines the limit.

    This works for authoritative servers with a relatively small number of authoritative records with decent TTLs measured in minutes or hours.

    I set this script and it killed all my DDOS attackers stone dead. They kept hitting at higher than the 3-second limit which effectively shut them down completely. Best of all, it wastes their attack resources against a blackhole, so they are no longer amplifying anything. (Don't fail with -j REJECT, always fail with -j DROP. Don't send back a TCP RST -- that just helps them DDOS their victim.)

    If a DNS client isn't getting an answer it will wait and retry -- a well-behaved client won't keep blasting away like that.

    3 seconds seems to be the optimum threshold. .No well-behaved client should be asking for that many recs that fast unless their DNS cache is totally broken or their upstream forwarding-DNS server has a broken cache. All Microsoft Windows PCs implement a caching client (DNS Client Service), as does Linux (dnsmasq), And even they do hit the limit somehow, it's only for 3 seconds, after which they get 18 more requests. And if you are legitimately receiving more than 36 queries for unique per client every few secs routinely then you need to buy something bigger than a $60 OpenWRT router anyway :-)

    -Gideon7

    ReplyDelete
  4. The code snippet in your last comment using the recent module doesn't work on OpenWRT BB 14.07-RC1 (assuming it's put in /etc/firewall.user). Could you elaborate please?

    TIA!

    ReplyDelete