Рубрика «ddos» - 15

в 13:35, , рубрики: ddos, ddos-атака, reg.ru, Блог компании REG.RU, метки: , , ,

Хостинг провайдер vs. DDoS атака. Решение REG.RU – профессиональный аутсорс

Недавно REG.RU совместно с компанией DDoS Guard представил бесплатную Хостинг провайдер vs. DDoS атака. Решение REG.RU – профессиональный аутсорс автоматическую защиту от DDoS-атак. Защита срабатывает автоматически и способна выдержать атаку со скоростью более 100 Гбит/с, что позволяет избежать отключения серверов и сайтов, а, следовательно, потери клиентов и прибыли.

Проблема борьбы с DDoS-атаками встает перед всеми хостинг-провайдерами без исключения. Классические методы борьбы предполагают временную недоступность атакованного сайта, однако REG.RU и DDoS Guard смогли найти пути решения этой проблемы. Но обо всем по порядку.
Читать полностью »

в 23:31, , рубрики: ddos, Блог компании ESET NOD32, информационная безопасность, метки:

Похоже, что эта неделя запомнится как самая насыщенная по количеству кибератак на государственные ресурсы различных стран. Ранее СМИ сообщали, что DDoS-атакам подверглись различные российские сайты, в том числе, ЦБ, «Первый канал», канал «Россия» и ресурс президента РФ kremlin. Несколько часов назад стало известно, что на сей раз DDoS-атаке подверглись веб-ресурсы НАТО: nato.int и Cyber Center ccdcoe.org, которые ушли в оффлайн и остаются там на момент написания этого поста. Но в отличие от атак на российские ресурсы, ответственность за которые никто не взял, на сей раз ответственные лица дали о себе знать.

Сайт НАТО «положен» КиберБеркутом

На веб-сайте КиберБеркута размещено сообщение «КиберБеркут атакует НАТО», в котором указанная группа берет на себя ответственность за проведение этой операции. В сообщении говорится, что кибератака связана с возможными действиями блока НАТО на территории Украины.

Мы, КиберБеркут, заявляем, что сегодня в 18:00 мы начали атаку на ресурсы НАТО:
ccdcoe.org
nato.int
nato-pa.int

Читать полностью »

в 13:21, , рубрики: ddos, pingback, wordpress, информационная безопасность

Более 162.000 сайтов на WordPress использовались для масштабной DDOS атакиСегодня я вам хочу рассказать о крупной DDOS-атаке, усиленной с помощью тысяч отдельных сайтов на движке WordPress.

Любой WordPress сайт с включенным Pingback (который, между прочим, включен по умолчанию), может использоваться в DDOS-атаке на другие сайты [В конце статьи ссылка на онлайн-сервис для проверки вашего сайта на участие в уже известных атаках – прим. переводчика].

Заметьте, XMLRPC используется для pingbacks, trackbacks, удаленного доступа с мобильных устройств и для многого другого, от чего вы, скорее всего, не захотели бы отказаться. Но как мы увидим, его можно использовать не только в благих целях.

История

Эта история произошла с популярным WordPress сайтом, который ушел в оффлайн из-за многочасовой DDOS-атаки. Когда атака усилилась, хостер отключил их сайт, и они приняли решение обратиться к нам за помощью и приобрести подписку на наш CloudProxy Website Firewall.

После того, как DNS были перенесены, мы, наконец, увидели, что происходит: это была мощная распределенная HTTP-flood Layer 7 атака, выполняющая сотни запросов в секунду к их серверу. Так выглядели эти запросы:

74.86.132.186 - - [09/Mar/2014:11:05:27 -0400] "GET /?4137049=6431829 HTTP/1.0" 403 0 "-" "WordPress/3.8; http://www.mtbgearreview.com"
121.127.254.2 - - [09/Mar/2014:11:05:27 -0400] "GET /?4758117=5073922 HTTP/1.0" 403 0 "-" "WordPress/3.4.2; http://www.kschunvmo.com" 
217.160.253.21 - - [09/Mar/2014:11:05:27 -0400] "GET /?7190851=6824134 HTTP/1.0" 403 0 "-" "WordPress/3.8.1; http://www.intoxzone.fr" 
193.197.34.216 - - [09/Mar/2014:11:05:27 -0400] "GET /?3162504=9747583 HTTP/1.0" 403 0 "-" "WordPress/2.9.2; http://www.verwaltungmodern.de" 
..

Вы, возможно, заметили, что у всех запросов есть случайный параметр ("?4137049=643182" и др.), благодаря которому запросы обходят кэш и требуют каждый раз полной перезагрузки страницы. Все это очень быстро убивает сервер.

Но самое интересное, что запросы поступают от других ничем ни примечательных WordPress сайтов. Да, другие WordPress сайты посылают множество запросов со случайным параметром и уводят жертву в оффлайн.Читать полностью »

в 11:25, , рубрики: ddos, Google, spreadsheet, информационная безопасность, Сетевые технологии, системное администрирование

Google использует своего «паука» FeedFetcher для кэширования любого контента в Google Spreadsheet, вставленного через формулу =image(«link»).

Например, если в одну из клеток таблицы вставить формулу 

=image("http://example.com/image.jpg")

Google отправит паука FeedFetcher скачать эту картинку и закэшировать для дальнейшего отображения в таблице.

Однако если добавлять случайный параметр к URL картинки, FeedFetcher будет скачивать её каждый раз заново. Скажем, для примера, на сайте жертвы есть PDF-файл размером в 10 МБ. Вставка подобного списка в таблицу приведет к тому, что паук Google скачает один и тот же файл 1000 раз!

=image("http://targetname/file.pdf?r=0")
=image("http://targetname/file.pdf?r=1")
=image("http://targetname/file.pdf?r=2")
=image("http://targetname/file.pdf?r=3")
...
=image("http://targetname/file.pdf?r=1000")

Все это может привести к исчерпанию лимита трафика у некоторых владельцев сайтов. Кто угодно, используя лишь браузер с одной открытой вкладкой, может запустить массированную HTTP GET FLOOD-атаку на любой веб-сервер.

Атакующему даже необязательно иметь быстрый канал. Поскольку в формуле используется ссылка на PDF-файл (т.е. не на картинку, которую можно было бы отобразить в таблице), в ответ от сервера Google атакующий получает только N/A. Это позволяет довольно просто многократно усилить атаку [Аналог DNS и NTP Amplification – прим. переводчика], что представляет серьезную угрозу.

DDOS любого сайта с помощью Google Spreadsheet

С использованием одного ноутбука с несколькими открытыми вкладками, просто копируя-вставляя списки ссылок на файлы по 10 МБ, паук Google может скачивать этот файл со скоростью более 700 Мбит/c. В моем случае, это продолжалось в течение 30-45 минут, до тех пора, пока я не вырубил сервер. Если я все правильно подсчитал, за 45 минут ушло примерно 240GB трафика.
Читать полностью »

в 15:49, , рубрики: ddos, meetup, ntp, информационная безопасность, Сетевые технологии, метки: , ,

У руководства Meetup требуют 300 долларов за отмену мощной DDoS атаки

В четверг СЕО Meetup получил странное сообщение по электронной почте, в котором говорилось «Ваш конкурент попросил меня осуществить DDoS-атаку на ваш сайат. Я могу остановить атаку за 300 долларов США. Дайте мне знать, если вы заинтересовались мои предложением». И прежде, чем сообщение было дочитано, сервис действительно стал подвергаться атаке на 8,2 Гбит/сек., что привело к падению.

Вернуть Meetup к жизни получилось, но только через 24 часа, и то, не очень надолго — работа сервиса была серьезно нарушена. Meetup начал работать в пятницу утром, чтобы снова полечь в субботу днем. В субботу в полночь его подняли, но в воскресенье сервис упал снова. В общем, все это продолжается до сих пор.

Читать полностью »

в 8:26, , рубрики: BGP, blackhole, ddos, juniper, информационная безопасность, Сетевые технологии, метки: , , ,

Сервера, размещенные в сети администрируемой мной AS, часто подвергаются различным DDOS атакам. Целью атакующих могут быть, как отдельные ресурсы размещенные на серверах, сами сервера и вся площадка в целом. С каждым месяцем количество, сложность и мощность атак возрастает. Атаки в 300-400Мб/с выросли до 70-80Гб/с. В этой ситуации не все атаки могут быть отражены тюнингом серверов, а крупные атаки могут помешать работе и всей площадки в целом. Бороться с такими атаками необходимо силами всей команды хостинга. Сетевые администраторы также должны иметь средства борьбы с такими атаками на сетевом уровне. О таких средствах и пойдет речь под катом.
Читать полностью »

в 21:18, , рубрики: anonymous, ddos, информационная безопасность, метки: ,

image

Британский Центр правительственной связи (GCHQ) использовал методы хакеров, в том числе DDoS-атаки, против хакерской группы Anonymous. Об это свидетельствуют новые документы от Эдварда Сноудена, пишет Mashable.

В то время как анонимные хакеры атаковали сайты с помощью DDoS в 2011 году, британские и американские власти пытались найти противодействие — и GCHQ решили использовать оружие хакеров против них.
Читать полностью »

в 17:32, , рубрики: ddos, nginx, nosql, redis, высокая производительность, метки: , ,

Не секрет, что для защиты от HTTP-DDoS зачастую используют связку nginx в качестве фронтенда и некий другой web-сервер в качестве бакенда. При этом ввиду большой нагрузки возникает проблема хранения логов для дальнейшего их анализа. Можно хранить в текстовом файле, но, естественно, анализировать/ротировать его весьма неудобно. Можно гнать данные напрямую в, например, mysql через пайп, но выигрывая в удобстве анализа мы проигрываем в производительности, особенно это заметно при фрагментации. Золотой серединой, пожалуй, будет no-sql решение.
Для себя я выбрал redis.
Читать полностью »

в 8:18, , рубрики: asn, BGP, ddos, geoip, iptables, linux, Блог компании FastVPS LLC, метки: , , , , ,

Введение

В свете новогодних праздников с их неотъемлемым атрибутом — повышенной активностью DoS/DDoS атак хотелось бы поднять один довольно редко используемый (но при этом довольно эффективный) способ отражения атак — блокировка на основании принадлежности блоков IP адресов определенному провайдеру/Дата Центру.
Защита от DoS/DDoS атак с помощью фильтрации по номеру автономной системы (ASN)
Читать полностью »

в 9:28, , рубрики: ddos, ddos-атака, iptables, linux, nginx, информационная безопасность, метки: , , ,

Доброго времени суток!

Совсем недавно столкнулся с такой проблемой, как DDoS. Сразу скажу, я вообще ни разу не линуксойд, но зато чуточку программист, так что все что ниже, основано чисто на логике, а не на фактах, плюс переписанное с некоторыми добавками от уже известного.

Перекопав полчища статей и опробовав множество вариантов, ничто так и не помогло. Взяв за основу статьи Простой и эффективный метод отразить http DDoS от 50мбит с помощью nginx и iptables и (D)DoS Deflate решил написать свой скрипт. Ну вернее не решил, а методом тыка и исправлений он получился сам.

Должен заметить, что статья от Алексея Кузьмина не идеальна, т.к. в логах nginx`a не достаточно копаться, да и обработка логов может потребовать много ресурсов. А именно в моем случае создавались логи более 50 Гиг, плюс запросы шли не «GET / HTTP/1.1», а «GET / HTTP/1.0», плюс, как оказалось, мой сервер сам от себя получал редиректы (127.0.0.1), которые не отображались в логах, которые отображались в запросе

netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n

Читать полностью »

1...10...141516...19
Главная   |  Архив новостей  |   Android  |   Google  |   Apple  |   Microsoft  |   Информационная безопасность  |   Веб – разработка
Публикации RSS  |  Комментарии RSS
https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js