none
DNS сервер примерно в одно и тоже время выдает не корректный IP для всех запросов. RRS feed

  • Вопрос

  • Примерно в 13-00 в журнале DNS появляется событие 5504

    На DNS-сервере обнаружено недопустимое имя домена в пакете от 8.8.8.8. Пакет будет отклонен. В данных события содержится пакет DNS.

    К 13-09, спустя ~20 записей (5504) появляется Предупреждение с кодом 3000

    DNS-сервер обнаружил значительное число событий времени выполнения. Чтобы определить причину возникновения этих событий, обратитесь к записям журнала DNS-сервера, предшествовавшим этим событиям. Для предотвращения переполнения журнала DNS-cервера, последующие события с кодом события больше 3000 будут подавляться, пока события не перестанут возникать со столь высокой частотой. 

    Все это время интернета у пользователей нет, т.к. при запросе например mail.ru выдается ip 10.0.0.1(такой же IP выдается на все запросы(google, yandex и т.д.))

    После перезапуска службы DNS работает, но отдает IP нестабильно:

    > yandex.ru
    ╤хЁтхЁ:  dc1.companyname.local
    Address:  192.168.1.101
    
    DNS request timed out.
        timeout was 2 seconds.
    DNS request timed out.
        timeout was 2 seconds.
    *** Превышено время ожидания запроса dc1.chts.local
    > yandex.ru
    ╤хЁтхЁ:  dc1.companyname.local
    Address:  192.168.1.101
    
    Не заслуживающий доверия ответ:
    ╚ь :     yandex.ru
    Addresses:  93.158.134.11
              213.180.204.11
              213.180.193.11
    
    >

    При этом запущенный NSLOOKUP до 8.8.8.8 с этого же сервера всегда выдает корректный адрес, без таймаутов, а NSLOOKUP до моего DNS то дает то не дает IP.

    C:\Documents and Settings\ts>ipconfig /all
    
    Настройка протокола IP для Windows
    
       Имя компьютера  . . . . . . . . . : dc1
       Основной DNS-суффикс  . . . . . . : companyname.local
       Тип узла. . . . . . . . . . . . . : гибридный
       IP-маршрутизация включена . . . . : нет
       WINS-прокси включен . . . . . . . : нет
       Порядок просмотра суффиксов DNS . : companyname.local
    
    LAN - Ethernet адаптер:
    
       DNS-суффикс этого подключения . . :
       Описание  . . . . . . . . . . . . : Atheros AR8121/AR8113/AR8114 PCI-E Ethern
    et Controller
       Физический адрес. . . . . . . . . : 20-CF-30-7A-40-D0
       DHCP включен. . . . . . . . . . . : нет
       IP-адрес  . . . . . . . . . . . . : 192.168.1.101
       Маска подсети . . . . . . . . . . : 255.255.255.0
       Основной шлюз . . . . . . . . . . : 192.168.1.254
       DNS-серверы . . . . . . . . . . . : 127.0.0.1
    

    C:\Documents and Settings\ts>dnscmd . /info
    Query result:
    Server info
            server name              = dc1.companyname.local
            version                  = 0ECE0205 (5.2 build 3790)
            DS container             = cn=MicrosoftDNS,cn=System,DC=companyname,DC=local
            forest name              = companyname.local
            domain name              = companyname.local
            builtin domain partition = ForestDnsZones.companyname.local
            builtin forest partition = DomainDnsZones.companyname.local
            last scavenge cycle      = not since restart (0)
      Configuration:
            dwLogLevel               = 00000000
            dwDebugLevel             = 00000000
            dwRpcProtocol            = FFFFFFFF
            dwNameCheckFlag          = 00000002
            cAddressAnswerLimit      = 0
            dwRecursionRetry         = 3
            dwRecursionTimeout       = 3
            dwDsPollingInterval      = 180
      Configuration Flags:
            fBootMethod                  = 3
            fAdminConfigured             = 1
            fAllowUpdate                 = 1
            fDsAvailable                 = 1
            fAutoReverseZones            = 1
            fAutoCacheUpdate             = 0
            fSlave                       = 0
            fNoRecursion                 = 0
            fRoundRobin                  = 1
            fStrictFileParsing           = 0
            fLooseWildcarding            = 0
            fBindSecondaries             = 0
            fWriteAuthorityNs            = 0
            fLocalNetPriority            = 1
      Aging Configuration:
            ScavengingInterval           = 168
            DefaultAgingState            = 1
            DefaultRefreshInterval       = 168
            DefaultNoRefreshInterval     = 168
      ServerAddresses:
     Addr Count = 1
                    Addr[0] => 192.168.1.101
      ListenAddresses:
     Addr Count = 1
                    Addr[0] => 192.168.1.101
      Forwarders:
     Addr Count = 3
                    Addr[0] => 91.144.134.1
                    Addr[1] => 91.144.132.1
                    Addr[2] => 8.8.8.8
            forward timeout  = 8
            slave            = 0
    Command completed successfully.
    
    C:\Documents and Settings\ts>

    Может кто уже сталкивался с подобной ситуацией? уже не знаю куда копать.

    18 декабря 2014 г. 10:18

Все ответы

  • Весьма вероятно, что вы попали под атаку, направленную на "загрязнение" кэша DNS некорректными записями, с использованием IP Spoofing (т.е. адрес источника подменен и пакеты от якобы публичного DNS Google 8.8.8.8 направляются совсем с другого узла сети). На ваш внутренний сервер DNS эта атака проходит, т.к. на шлюз с NAT по какой-то причине осуществляет трансляцию на ваш сервер пакетов DNS, приходящих на его внешний интерфейс: либо сервер DNS опубликован (например, помещен в "DMZ" - в этом случае все неопознанные пакеты с внешнего интерфейса транслируются на ваш сервер), либо потому что в момент прихода на шлюзе есть действуюющая ассоциfция NAT  для обратной трансляции (а таких ассоциаций может быть много, т.к. ваш сервер DNS пересылает запросы на 8.8.8.8).

    В вашем конкретном случае рекомендую

    a) проверить, что никакой ненужной публикации на шлюзе NAT нет;

    б) удалить 8.8.8.8 из списка серверов, куда осуществляется пересылка запросов: в таком случае ассоциации, через которые возможна атака, создаваться не будут;

    Возможно, конечно, (хотя в данном раскладе это кажется мне маловероятным) что атака осуществляется злономеренным узлом вашей внутренней сети. Защититься от этой атаки можно, выполнив п.б), а если не поможет - запретив пакеты с адресом источника 8.8.8.8 в брандмауэре (можно даже - во встроенном), а найти источник - по MAC-адресу источника кадров Ethernet, переносящих вредоносные пакеты IP - для этого потребуется анализатор сети (сниффер), типа Microsoft Network Monitor или Wireshark.


    Слава России!

    18 декабря 2014 г. 13:42