А в чём он(c.dns.ripn.net.) виновник?
Такого узла в трэйсе нет
dig
# dig -t NS ufsin45.ru @8.8.8.8 +trace
; <<>> DiG 9.10.0-P2 <<>> -t NS ufsin45.ru @8.8.8.8 +trace
;; global options: +cmd
. 8481 IN NS h.root-servers.net.
. 8481 IN NS m.root-servers.net.
. 8481 IN NS b.root-servers.net.
. 8481 IN NS e.root-servers.net.
. 8481 IN NS f.root-servers.net.
. 8481 IN NS k.root-servers.net.
. 8481 IN NS l.root-servers.net.
. 8481 IN NS c.root-servers.net.
. 8481 IN NS i.root-servers.net.
. 8481 IN NS a.root-servers.net.
. 8481 IN NS g.root-servers.net.
. 8481 IN NS d.root-servers.net.
. 8481 IN NS j.root-servers.net.
. 8481 IN RRSIG NS 8 0 518400 20140923080000 20140916070000 8230. YN5/hkvFbV3QYm+vbTK78z3ywfUbQjfwmx4War88gfchyxE/GdY9ZwHf PduztMsvIc+RDOswlpQvdb4ZJ62+kbya/nFuY+ydrLREd3jqlr0ENRCZ kwGt4AZ058HccexOiP2EnCIiFBgIsfX2diGO2hJWgWPSPCRjudEkvNaJ cpc=
;; Received 397 bytes from 8.8.8.8#53(8.8.8.8) in 262 ms
ru. 172800 IN NS f.dns.ripn.net.
ru. 172800 IN NS d.dns.ripn.net.
ru. 172800 IN NS e.dns.ripn.net.
ru. 172800 IN NS b.dns.ripn.net.
ru. 172800 IN NS a.dns.ripn.net.
ru. 86400 IN DS 51272 8 2 13ECAF18251EEC90C6BC8F16E2730F1F597F6D7E406C4A8FF1D4FD7D 760D6EEE
ru. 86400 IN RRSIG DS 8 1 86400 20140923080000 20140916070000 8230. SvrUGQY+rnY285vSiCx2cqpXA2bUhlirORiCW/vOqrZXkh66eNNmoTu2 8SAVLQNZtBwShZTAMZDx6it/BWFlNDawBH0SDuiBM/xjRpiNhiMReali MTMHQZFGqarEea5VSUTVy5NvIl21D59A1Noh73UbCLp5YnUW3jYHmyYV QNw=
;; Received 558 bytes from 192.5.5.241#53(f.root-servers.net) in 133 ms
ufsin45.ru. 345600 IN NS ns1.nameself.com.
ufsin45.ru. 345600 IN NS ns2.nameself.com.
ufsin45.ru. 345600 IN DS 51586 8 1 E15D816549C093423C97AC2AEA8BA67B189C5C2B
ufsin45.ru. 345600 IN RRSIG DS 8 2 345600 20141008143205 20140824142457 43590 ru. VWoK1Th+eBOouL2EpGxYAAom7r+9Rg20BJAZdM08GPl7Uo/LeZPRSUv0 poq4ya68ABOcvV76DtiWeMAk2WDZME9pXJMSIMPXR2P5FoGwZbaPx5Ap 0QC0RFfaJGCPwTTg9/3AnLo9x5E4rlROJmdJbE8kvTdol7Bj0MAhNbJS hZU=
;; Received 285 bytes from 193.232.156.17#53(f.dns.ripn.net) in 308 ms
ufsin45.ru. 28800 IN NS ns1.nameself.com.
ufsin45.ru. 28800 IN NS ns2.nameself.com.
ufsin45.ru. 28800 IN RRSIG NS 8 2 28800 20140502113343 20140402113343 64269 ufsin45.ru. nVVrLtD7qxuWSNnlJGJNWh+BCVlkEiAe4afPLBpa/xQEsvbTKEj43C/C 3BYTIehjpz1P4fYO4LS7MLj3WCLw3La414ix6bMEUO8gktu9WJew+9lG 90Wqfu9OYiT59R+icwOplaGA6pM9C9Y2tA44AgefcfEonDF+WLjbileF uyY=
;; Received 865 bytes from 77.221.159.237#53(ns2.nameself.com) in 60 ms
Если для сервиса не было какого-то уникального критерия, как-то, например, доменное имя, то неадекватный клиент всегда найдёт способ обойти ограничение. Адекватный же просто попросит увеличить тестовый период, если ему не хватило времени на оценку.
Вероятнее всего не только ФБР, а и все серьёзные спецслужбы. И всем это выгодно/удобно, потому выступление на тему деанонимизации tor на blackhat2014 не допустили.
Может, конечно, и наконечники где-то используют. Но так как конец трубы самая уязвимая часть, то проще её заварить, чем использовать многоразовый наконечник.
У нас был случай даже когда загнали трубу под дорогу (метров 6), её там защемило и вынуть обратно не смогли, поэтому просто похоронили там кусок.
Но больше 30 метров не доводилось закладывать. Километр, конечно, впечатляет.
А кто заставлял останавливать его работу?
СМС-ка была отправлена не в органы и не в какие-то ведомства, т.е. никаких угроз не поступало. Он отправил её своему другу. Если так реагировать на все пересылаемые СМС, то боюсь, что метро никогда работать не будет.
По сравнению с минским псевдо террористом это цветочки. Там 5 лет грозит за шутливую смс-ку, которую у него девушка прочитала через плечо. И уже никто не сомневается в том, что срок будет.
Отключают, конечно. Но стоит ли делать подобные отключения в тот момент когда по вине самого регистратора не работает ресолвинг? Как клиенту угадать, что это отключение за неподвтерждение почты в тот момент когда у него сначала всё отключилось по вине самого регистратора, а техподдержка либо заявляет что проблем нет, либо просто не отвечает по полсуток?
Может таки надо сначала решать собственные проблемы, а не махать шашкой?
Собственно выглядело это так:
С учётом недельного ttl, который отдавался во время «сбоя» некоторые DNS-ники до сих пор ресолвят «сбойный» 209.222.14.6
А первого ответа от техподдержки r01 мы дождались только через 12 часов.
Но ещё больше «порадовало», то что, в то время пока мы ожидали каких-то разъяснений, одному из наших клиентов r01 отключили 69 доменов на основании того что он не подтвердил e-mail — support.reghouse.ru/knowledgebase.php?article=22
Александр, меня вот терзают смутные сомнения о необходимости публиковать статью о http-ддосинге, потому что там описан механизм доступный любому школьнику, способный уложить большинство шаред-хостингов и впсок нижнего диапазона. Но о защите от http-ддоса сейчас не знает только ленивый и защита от таких атак меня не интересует.
А вот если не подогревать тему стековых-атак, то и решений найдено не будет. Я долго думал писать ли её, либо просто разослать решение всем кто просил, но сейчас я уже уверен, что решение о написании было верным, хотя бы даже потому, что мне указали на явные косяки (0din отдельное спасибо!).
А как мне простому админу получить нужную мне информацию как не в обсуждении здесь?
Во-первых, такая атака сложит сетевую инфраструктуру самого атакующего с гораздо большей вероятностью чем что-то еще.
Некоторая доля истины в словах Александра есть. Я приведу историю без упоминания имён и слегка изменив детали.
— Компания А проводила тендер в строго означенное время и для неё невероятно важна была гарантированная доступность. Для этой цели она арендовала сервер в одном румынском ДЦ. Этот датацентр предлагает защиту от атак до ~500 mpps и его защита реальна. Но в означенное время сервер убит. Как же это произошло?
Компания Б выяснив где расположен сервер также арендовала несколько серверов в этом же ДЦ и в час Х начала атаки. Так как вся защита ДЦ расположена на пограничных узлах и не контролирует внутренние сети, то сервер оказался незащищённым в защищённом ДЦ.
— Конечно, это чётко спланированная акция и с учётом денег которые там крутились текущая статья даже не песчинка в пустыне.
О netmap/dpdk/pfring-dna я говорю чуть-ли не на каждой презентации.
Александр, а что Вы на них говорите? То что ВАМ удалось сделать решение. Где и когда вы поделились накопленным опытом, хотя бы уже и устаревшим? Где хоть одно готовое решение по защите? Да, понятно, что для Вас это бизнес и Вы не собираетесь делиться своими наработками. Но давайте не будем лукавить — кроме самопиара там ничего нет.
Такого узла в трэйсе нет
; <<>> DiG 9.10.0-P2 <<>> -t NS ufsin45.ru @8.8.8.8 +trace
;; global options: +cmd
. 8481 IN NS h.root-servers.net.
. 8481 IN NS m.root-servers.net.
. 8481 IN NS b.root-servers.net.
. 8481 IN NS e.root-servers.net.
. 8481 IN NS f.root-servers.net.
. 8481 IN NS k.root-servers.net.
. 8481 IN NS l.root-servers.net.
. 8481 IN NS c.root-servers.net.
. 8481 IN NS i.root-servers.net.
. 8481 IN NS a.root-servers.net.
. 8481 IN NS g.root-servers.net.
. 8481 IN NS d.root-servers.net.
. 8481 IN NS j.root-servers.net.
. 8481 IN RRSIG NS 8 0 518400 20140923080000 20140916070000 8230. YN5/hkvFbV3QYm+vbTK78z3ywfUbQjfwmx4War88gfchyxE/GdY9ZwHf PduztMsvIc+RDOswlpQvdb4ZJ62+kbya/nFuY+ydrLREd3jqlr0ENRCZ kwGt4AZ058HccexOiP2EnCIiFBgIsfX2diGO2hJWgWPSPCRjudEkvNaJ cpc=
;; Received 397 bytes from 8.8.8.8#53(8.8.8.8) in 262 ms
ru. 172800 IN NS f.dns.ripn.net.
ru. 172800 IN NS d.dns.ripn.net.
ru. 172800 IN NS e.dns.ripn.net.
ru. 172800 IN NS b.dns.ripn.net.
ru. 172800 IN NS a.dns.ripn.net.
ru. 86400 IN DS 51272 8 2 13ECAF18251EEC90C6BC8F16E2730F1F597F6D7E406C4A8FF1D4FD7D 760D6EEE
ru. 86400 IN RRSIG DS 8 1 86400 20140923080000 20140916070000 8230. SvrUGQY+rnY285vSiCx2cqpXA2bUhlirORiCW/vOqrZXkh66eNNmoTu2 8SAVLQNZtBwShZTAMZDx6it/BWFlNDawBH0SDuiBM/xjRpiNhiMReali MTMHQZFGqarEea5VSUTVy5NvIl21D59A1Noh73UbCLp5YnUW3jYHmyYV QNw=
;; Received 558 bytes from 192.5.5.241#53(f.root-servers.net) in 133 ms
ufsin45.ru. 345600 IN NS ns1.nameself.com.
ufsin45.ru. 345600 IN NS ns2.nameself.com.
ufsin45.ru. 345600 IN DS 51586 8 1 E15D816549C093423C97AC2AEA8BA67B189C5C2B
ufsin45.ru. 345600 IN RRSIG DS 8 2 345600 20141008143205 20140824142457 43590 ru. VWoK1Th+eBOouL2EpGxYAAom7r+9Rg20BJAZdM08GPl7Uo/LeZPRSUv0 poq4ya68ABOcvV76DtiWeMAk2WDZME9pXJMSIMPXR2P5FoGwZbaPx5Ap 0QC0RFfaJGCPwTTg9/3AnLo9x5E4rlROJmdJbE8kvTdol7Bj0MAhNbJS hZU=
;; Received 285 bytes from 193.232.156.17#53(f.dns.ripn.net) in 308 ms
ufsin45.ru. 28800 IN NS ns1.nameself.com.
ufsin45.ru. 28800 IN NS ns2.nameself.com.
ufsin45.ru. 28800 IN RRSIG NS 8 2 28800 20140502113343 20140402113343 64269 ufsin45.ru. nVVrLtD7qxuWSNnlJGJNWh+BCVlkEiAe4afPLBpa/xQEsvbTKEj43C/C 3BYTIehjpz1P4fYO4LS7MLj3WCLw3La414ix6bMEUO8gktu9WJew+9lG 90Wqfu9OYiT59R+icwOplaGA6pM9C9Y2tA44AgefcfEonDF+WLjbileF uyY=
;; Received 865 bytes from 77.221.159.237#53(ns2.nameself.com) in 60 ms
Проверил, всё работает как положено.
У нас был случай даже когда загнали трубу под дорогу (метров 6), её там защемило и вынуть обратно не смогли, поэтому просто похоронили там кусок.
Но больше 30 метров не доводилось закладывать. Километр, конечно, впечатляет.
Конец заваривается, потом спиливается.
СМС-ка была отправлена не в органы и не в какие-то ведомства, т.е. никаких угроз не поступало. Он отправил её своему другу. Если так реагировать на все пересылаемые СМС, то боюсь, что метро никогда работать не будет.
Может таки надо сначала решать собственные проблемы, а не махать шашкой?
С учётом недельного ttl, который отдавался во время «сбоя» некоторые DNS-ники до сих пор ресолвят «сбойный» 209.222.14.6
А первого ответа от техподдержки r01 мы дождались только через 12 часов.
Но ещё больше «порадовало», то что, в то время пока мы ожидали каких-то разъяснений, одному из наших клиентов r01 отключили 69 доменов на основании того что он не подтвердил e-mail — support.reghouse.ru/knowledgebase.php?article=22
В общем чУдной регистратор…
А вот если не подогревать тему стековых-атак, то и решений найдено не будет. Я долго думал писать ли её, либо просто разослать решение всем кто просил, но сейчас я уже уверен, что решение о написании было верным, хотя бы даже потому, что мне указали на явные косяки (0din отдельное спасибо!).
А как мне простому админу получить нужную мне информацию как не в обсуждении здесь?
да, именно так
pkt-gen -f tx -i netmap:ix0 -s 128.0.0.1:1025-223.255.255.254:65535 -d 10.90.90.55:80 -l 60
Здесь меня интересовал только подсчёт контрольной суммы.
Эти вопросы я пересмотрю.
Некоторая доля истины в словах Александра есть. Я приведу историю без упоминания имён и слегка изменив детали.
— Компания А проводила тендер в строго означенное время и для неё невероятно важна была гарантированная доступность. Для этой цели она арендовала сервер в одном румынском ДЦ. Этот датацентр предлагает защиту от атак до ~500 mpps и его защита реальна. Но в означенное время сервер убит. Как же это произошло?
Компания Б выяснив где расположен сервер также арендовала несколько серверов в этом же ДЦ и в час Х начала атаки. Так как вся защита ДЦ расположена на пограничных узлах и не контролирует внутренние сети, то сервер оказался незащищённым в защищённом ДЦ.
— Конечно, это чётко спланированная акция и с учётом денег которые там крутились текущая статья даже не песчинка в пустыне.
Александр, а что Вы на них говорите? То что ВАМ удалось сделать решение. Где и когда вы поделились накопленным опытом, хотя бы уже и устаревшим? Где хоть одно готовое решение по защите? Да, понятно, что для Вас это бизнес и Вы не собираетесь делиться своими наработками. Но давайте не будем лукавить — кроме самопиара там ничего нет.