DDoS-атака сайта с Kali Linux. Как положить сервер за 2 минуты?
Zip File, мамкины хацкеры. Последнее время вы всё чаще просите меня вернуться к тематике, так называемых взломов и проникновения. Само-собой разумеется, что ничем таким мы тут в принципе не занимаемся. И никогда доселе не занимались. А все подобные просьбы не имеют под собой никакой почвы и веских доводов. Просто некоторые ребята порою путают проверку различного рода систем на предмет защищённости с отвратительным понятием хацкинг.
Сам я, люто ненавижу и презираю, любое вредоносное воздействие направленное на создаваемые людьми сервисы. Ведь это, по меньшей мере, бесчестно, неэтично и попросту аморально. Ладненько, ребзи, завязываем с толерастией и переходим к делу. Вы давно хотели какой-нибудь ролик про DDoS сайтов. И да, сегодня я наконец покажу вам, один из примеров, как злоумышленники проводят такие атаки.
Предвещая комменты умников, сразу отвечу, что я и без сопливых знаю разницу между DoS и DDoS. Однако, первый вариант на ютубчике вообще никто не ищет, поэтому заголовок взят исключительно из соображений оптимизации. Сам же ролик конечно же посвящён DoS’ке. Но при всём при этом никто не мешает вам зарядить это дело с нескольких тачек по разным каналам и получить по итогу полноценный DDoS.
Об этом способе мне поведал кореш из Лен. области, который уже много лет занимается тем, что наживается на наивности государственных учреждений, у которых в обязательном порядке должна быть Web-страничка на просторах сети. Причём качество исполнения, как это обычно бывает, не имеет значения. Должен быть сайт по документам – значит он есть. И занимаются такими гавно-сайтами, как правило, либо наёмные фрилансеры.
Либо сотрудники местного IT-отдела впахивающие за МРОТ и в гробу видавшие всё на свете кроме зряплаты, пива и пятницы. Поэтому о пресловутой безопасности речь в таких учреждениях заходит в самую последнюю очередь. А если и заходит, то дальше бумажек дело продвигается крайне редко. Однако информация, размещаемая на этих ресурсах, очень часто представляет действительно огромную ценность.
Особенно во время сторонних проверок. Нынче же модно проводить различные аудиты, контроли, оценки качества и прочий бред, помогающий зарабатывать копеечку всем тем, кого сердобольные тёточки наняли по знакомству и теперь не могут озадачить путной работой. Поэтому доступ к ресурсам во время этих проверок. Особенно во время этих проверок должен быть максимально стабилен. И не дай бог, сервер не сможет предоставить нужную инфу по запросу.
Это же сразу паника. Все бегут к руководству, а те в свою очередь начинают страпонить ответственного за сайтец. Тот, естественно, начинает искать выход из ситуации и находит его практически сразу. В гугле по первым же запросам выдаются сервисы, гарантирующие вам защиту от DDoSатак на самом высоком уровне. Но в таких конторах люди и по сей день с неохотой доверяют всяким там Интернетам.
Гораздо спокойнее выйти на местного человека, ИПшника, занимающегося предоставлением подобной услуги и которого в случае чего всегда можно будет найти упрекнуть и даже взыскать по факту нарушений пунктов договора, если таковые будут иметь место. Поэтому, лично я, лезть бы в такой бизнес точно не стал. Однако, для опытных кибербезопасников со стажем, это прям золотая жила. Если ещё и ленд свой раскрутите, то от желающих отбоя не будет.
Но суть нашего сегодняшнего разговора не в этом. Мой друг, частенько заглядывая в такие конторы в поисках новых клиентов проворачивал весьма интересный фокус. Сидя за столом напротив очередного скептически настроенного руководителя, он доставал ноут, спрашивал адрес их сайта и запускал стресс-тест Апатча, который в 88% случаев ложит незащищённые сайты уже через пару секунд.
Далее, он с улыбкой просил директора попробовать перейти на сайт своего учреждения и после того, как ехидная ухмылка сменялась недоумением, снова задавал свой вопрос «нуждаются ли они в услугах квалифицированной защиты сайта»? По словам товарища срабатывает в 8 из 10 случае. Главное заранее перед выездом затестить сайт на предмет восприимчивости к данному типу атак и можно смело отправляться пытать удачу.
Сегодня, я так и быть покажу вам эту методику, посредством которой вы сможете в два счёта проверить любой сайт на устойчивость к встроенному стресс-тесту Апатча. Если интересно, устраивайтесь по удобней и будем начинать.
Шаг 1. Я буду использовать виртульную машину с Kali Linux. В версии 20 года уже предустановлена вторая версия Апатча, а с ним в комплекте и нужный нам модуль тестирования Benchmark. Запускаем окно терминала.
Шаг 2. И параллельно открываем на хост-машине сайт для проверки. Я админю парочку сайтов образовательных учреждений, в частности вот страничка с дистанционными курсами. Благо в данном проекте ответственность за безопасность лежит не на мне, поэтому можно чутка поэкспериментировать в благих целях. Сейчас тем более лето, все кто хотел уже отучились. Так что 5 минутный простой никто не заметит.
Шаг 3. Возвращаемся в Kaliи вставляем длинную команду AB’шки с кучей параметров. «n» у нас отвечает за общее число отправляемых запросов, «c» – это сколько из них будет параллельных, по сути, просто количество соединений.
«k» — активирует KeepAlive, то есть даёт возможность осуществлять множество запросов в течение одной сессии. По дефолту данная возможность выключена. «r» — включает автоматический повтор, при возникновении ошибок.
А «H» до кучи передаёт в заголовках User-Agent, чтобы в логах сервера, всё отображалось, как запросы от Google Bot. Добавляем в конец адрес своего сайта, не забывая слэш на конце. Усё. Жмём «Enter»
Шаг 4. И через пару секунд возвращаемся на хост-машинку проверять доступность ресурса. Пробуем обновиться. Тадам. Сайтик слёг. Этот, к слову, работает вроде бы на WordPress’e.
Шаг 5. У меня есть ещё второй. Дмумловский. Причём он, по-моему, даже без сертификата. HTTP’шный. Тут я храню записи подкастов, чтобы выкладывать на iTunes’е. Т.к. особой популярностью они, к сожалению, тоже не пользуются, давайте побалуемся и с этой web-мордой.
Шаг 6. Возвращаемся в Kaliи в новом окне терминала изменяем адрес тестируемого ресурса. Запускаем зверюгу.
Шаг 7. Снова идём на хост и пробуем обновить страницу. Такая ж петрушка. Только тут всё ещё непонятнее, т.к. никакого сообщения об ошибке не появляется.
Эта темка отлично работает в случае, если нужно быстро увести сайтец в даун на короткое время. При желании, можете подождать, пока скрипт отработает все заданные пакеты, а затем проанализировать, сколько времени это заняло. Допустим на 100к паков у машины ушло 5 минут. Исходя из этого понимаем, что примерно каждые 10 минут можно запускать скрипт по новой и бедненький сайт, по сути, будет находиться в постоянном простое.
Ну а автоматизировать запуск такого скрипта по времени сможет любой начинающий эникей. А вот, чтобы обезопасить ресурс от этой заразы своими силами, придётся уже слегка попотеть. И знаете, я впервые сделаю исключение и нарочно не буду в данном сюжете рассказывать, как защититься. Опытные сайто-админы и так знают, а начинающим, будет стимул учиться.
Искренне надеюсь, что после просмотра данного видео тысячи школьников не побегут DDoS’ить сайты своих ни в чём не повинных учебных заведений. Ведь сайтами в таких местах занимаются, как правило, учителя информатики, а им, уж поверьте, и без того не сладко живётся. Говорю по своему опыту. Ладненько, друзья. Если вы хотите более подробно узнать про сервер Apache и вообще про команды Linux. Стать уже наконец востребованным специалистом, а не сидеть до 30ти у мамки на шее.
В таком случае настоятельно рекомендую вам ознакомиться с моим новым обучающим курсом по Администрированию Linuxс нуля. В нём я, как раз подробно освещаю основные моменты по данной теме. В данный момент, его ещё можно приобрести с 50% скидкой. И как знать, быть может это будет лучшее вложение в вашей жизни. Так что не тупите, регистрируйтесь, и начинайте учиться прямо сейчас.
>>>КЛИКНИТЕ, ЧТОБЫ УЗНАТЬ ПОДРОБНОСТИ
Ну а на сегодня это всё. Если впервые заглянул на канал, то обязательно оформляй подписон и в твоей ленте будут регулярно появляться годнейшие ролики на тему этичных взломов, атак, пентестинга и информационной безопасности. С олдов по традиции жду лайки и конечно же, комментарии по поводу того, как же всё-таки можно защититься от такой простенькой, но согласитесь, весьма эффективной DoS’ки.
Большое спасибо вам за просмотр. Всем удачи, успеха и самое главное, спокойной работы. Берегите себя и свои сайты. Настраивайте на проектах эффективную оборону и тогда, никакой злоумышленник не сможет навредить ресурсам ваших клиентам. С вами, как обычно, был Денчик. Продолжаю прислушиваться к вашим мольбам и пилить видосики чаще. Надеюсь, что вы это цените. До новых встреч, камрады. Всем пока.
Источник
Защита Linux-сервера. Что сделать в первую очередь
Habib M’henni / Wikimedia Commons, CC BY-SA
В наше время поднять сервер на хостинге — дело пары минут и нескольких щелчков мыши. Но сразу после запуска он попадает во враждебную среду, потому что открыт для всего интернета как невинная девушка на рокерской дискотеке. Его быстро нащупают сканеры и обнаружат тысячи автоматически скриптовых ботов, которые рыскают по сети в поисках уязвимостей и неправильных конфигураций. Есть несколько вещей, которые следует сделать сразу после запуска, чтобы обеспечить базовую защиту.
Содержание
Нерутовый юзер
Первым делом нужно завести для себя нерутового юзера. Дело в том, что у пользователя root абсолютные привилегии в системе, а если разрешить ему удалённое администрирование, то вы сделаете половину работы для хакера, оставив для него валидный username.
Поэтому нужно завести другого юзера, а для рута отключить удалённое администрирование по SSH.
Новый пользователь заводится командой useradd :
Затем для него добавляется пароль командой passwd :
Наконец, этого пользователя нужно добавить в группу, которая имеет право выполнять команды с повышением привилегий sudo . В зависимости от дитрибутива Linux, это могут быть разные группы. Например, в CentOS и Red Hat юзера добавляют в группу wheel :
В Ubuntu он добавляется в группу sudo :
Ключи вместо паролей SSH
Брутфорс или утечка паролей — стандартный вектор атаки, так что аутентификацию по паролям в SSH (Secure Shell) лучше отключить, а вместо неё использовать аутентификацию по ключам.
Есть разные программы для реализации протокола SSH, такие как lsh и Dropbear, но самой популярной является OpenSSH. Установка клиента OpenSSH на Ubuntu:
Установка на сервере:
Запуск демона SSH (sshd) на сервере под Ubuntu:
Автоматический запуск демона при каждой загрузке:
Нужно заметить, что серверная часть OpenSSH включает в себя клиентскую. То есть через openssh-server можно подключаться к другим серверам. Более того, со своей клиентской машины вы можете запустить SSH-туннель с удалённого сервера на сторонний хост, и тогда сторонний хост будет считать удалённый сервер источником запросов. Очень удобная функция для маскировки своей системы. Подробнее см. статью «Практические советы, примеры и туннели SSH».
На клиентской машине обычно нет смысла ставить полноценный сервер, чтобы не допускать возможность удалённого подключения к компьютеру (в целях безопасности).
Итак, для своего нового юзера сначала нужно сгенерировать ключи SSH на компьютере, с которого вы будете заходить на сервер:
Публичный ключ хранится в файле .pub и выглядит как строка случайных символов, которые начинаются с ssh-rsa .
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQ3GIJzTX7J6zsCrywcjAM/7Kq3O9ZIvDw2OFOSXAFVqilSFNkHlefm1iMtPeqsIBp2t9cbGUf55xNDULz/bD/4BCV43yZ5lh0cUYuXALg9NI29ui7PEGReXjSpNwUD6ceN/78YOK41KAcecq+SS0bJ4b4amKZIJG3JWm49NWvoo0hdM71sblF956IXY3cRLcTjPlQ84mChKL1X7+D645c7O4Z1N3KtL7l5nVKSG81ejkeZsGFzJFNqvr5DuHdDL5FAudW23me3BDmrM9ifUmt1a00mWci/1qUlaVFft085yvVq7KZbF2OP2NQACUkwfwh+iSTP username@hostname
Затем из-под рута создать на сервере директорию SSH в домашнем каталоге пользователя и добавить публичный ключ SSH в файл authorized_keys , используя текстовый редактор вроде Vim:
Наконец, установить корректные разрешения для файла:
и изменить владение на этого юзера:
На стороне клиента нужно указать местоположение секретного ключа для аутентификации:
Теперь можно залогиниться на сервер под именем юзера по этому ключу:
После авторизации можно использовать команду scp для копирования файлов, утилиту sshfs для удалённого примонтирования файловой системы или директорий.
Желательно сделать несколько резервных копий приватного ключа, потому что если отключить аутентификацию по паролю и потерять его, то у вас не останется вообще никакой возможности зайти на собственный сервер.
Как упоминалось выше, в SSH нужно отключить аутентификацию для рута (по этой причине мы и заводили нового юзера).
На CentOS/Red Hat находим строку PermitRootLogin yes в конфигурационном файле /etc/ssh/sshd_config и изменяем её:
На Ubuntu добавляем строку PermitRootLogin no в конфигурационный файл 10-my-sshd-settings.conf :
После проверки, что новый юзер проходит аутентификацию по своему ключу, можно отключить аутентификацию по паролю, чтобы исключить риск его утечки или брутфорса. Теперь для доступа на сервер злоумышленнику необходимо будет достать приватный ключ.
На CentOS/Red Hat находим строку PasswordAuthentication yes в конфигурационном файле /etc/ssh/sshd_config и изменяем её следующим образом:
На Ubuntu добавляем строку PasswordAuthentication no в файл 10-my-sshd-settings.conf :
Инструкцию по подключению двухфакторной аутентификации по SSH см. здесь.
Файрвол
Файрвол гарантирует, что на сервер пойдёт только тот трафик по тем портам, которые вы напрямую разрешили. Это защищает от эксплуатации портов, которые случайно включились с другими сервисами, то есть сильно уменьшает поверхность атаки.
Перед установкой файрвола нужно убедиться, что SSH внесён в список исключений и не будет блокироваться. Иначе после запуска файрвола мы не сможем подключиться к серверу.
С дистрибутивом Ubuntu идёт Uncomplicated Firewall (ufw), а с CentOS/Red Hat — firewalld.
Разрешение SSH в файрволе на Ubuntu:
На CentOS/Red Hat используем команду firewall-cmd :
После этой процедуры можно запустить файрвол.
На CentOS/Red Hat запускаем сервис systemd для firewalld:
На Ubuntu используем такую команду:
Fail2Ban
Сервис Fail2Ban анализирует логи на сервере и подсчитывает количество попыток доступа с каждого IP-адреса. В настройках указаны правила, сколько попыток доступа разрешено за определённый интервал — после чего данный IP-адрес блокируется на заданный отрезок времени. Например, разрешаем 5 неудачных попыток аутентификации по SSH в промежуток 2 часа, после чего блокируем данный IP-адрес на 12 часов.
Установка Fail2Ban на CentOS и Red Hat:
Установка на Ubuntu и Debian:
В программе два конфигурационных файла: /etc/fail2ban/fail2ban.conf и /etc/fail2ban/jail.conf . Ограничения для бана указываются во втором файле.
Джейл для SSH включён по умолчанию с дефолтными настройками (5 попыток, интервал 10 минут, бан на 10 минут).
Кроме SSH, Fail2Ban может защищать и другие сервисы на веб-сервере nginx или Apache.
Автоматические обновления безопасности
Как известно, во всех программах постоянно находят новые уязвимости. После публикации информации эксплоиты добавляются в популярные эксплоит-паки, которые массово используются хакерами и подростками при сканировании всех серверов подряд. Поэтому очень важно устанавливать обновления безопасности как только они появляются.
На сервере Ubuntu в конфигурации по умолчанию включены автоматические обновления безопасности, так что дополнительных действий не требуется.
На CentOS/Red Hat нужно установить приложение dnf-automatic и включить таймер:
Смена портов по умолчанию
SSH был разработан в 1995 году для замены telnet (порт 23) и ftp (порт 21), поэтому автор программы Тату Илтонен выбрал порт 22 по умолчанию, и его утвердили в IANA.
Естественно, все злоумышленники в курсе, на каком порту работает SSH — и сканируют его вместе с остальными стандартными портами, чтобы узнать версию программного обеспечения, для проверки стандартных паролей рута и так далее.
Смена стандартных портов — обфускация — в несколько раз сокращает объём мусорного трафика, размер логов и нагрузку на сервер, а также сокращает поверхность атаки. Хотя некоторые критикуют такой метод «защиты через неясность» (security through obscurity). Причина в том, что эта техника противопоставляется фундаментальной архитектурной защите. Поэтому, например, Национальный институт стандартов и технологий США в «Руководстве по безопасности сервера» указывает необходимость открытой серверной архитектуры: «Безопасность системы не должна полагаться на скрытность реализации её компонентов», — сказано в документе.
Теоретически, смена портов по умолчанию противоречит практике открытой архитектуры. Но на практике объём вредоносного трафика действительно сокращается, так что это простая и эффективная мера.
Номер порта можно настроить, изменив директиву Port 22 в файле конфигурации /etc/ssh/sshd_config. Он также указывается параметром -p
в sshd. Клиент SSH и программы sftp тоже поддерживают параметр -p
можно использовать для указания номера порта при подключении с помощью команды ssh в Linux. В sftp и scp используется параметр -P
(заглавная P). Указание из командной строки переопределяет любое значение в файлах конфигурации.
Если серверов много, почти все эти действия по защите Linux-сервера можно автоматизировать в скрипте. Но если сервер только один, то лучше вручную контролировать процесс.
На правах рекламы
Закажи и сразу работай! Создание VDS любой конфигурации и с любой операционной системой в течение минуты. Максимальная конфигурация позволит оторваться на полную — 128 ядер CPU, 512 ГБ RAM, 4000 ГБ NVMe. Эпичненько 🙂
Источник
