Назад | Перейти на главную страницу

Атака TCP, невидимая для netstat

нас поразила странная атака, злоумышленник даже написал нам письмо по электронной почте.

На выходе netstat -n обычно всего несколько «ESTABLISHED» и «TIME_WAIT», но доступ к веб-сайту сервера извне невозможен. А при вводе «ssh 127.0.0.1» в окне консоли на получение запроса пароля уходит почти минута. Использование ЦП и памяти очень низкое.

Вывод команды "tcpdump -l" в среднем составляет всего несколько строк в секунду. Большинство из них представляют собой TCP-соединение с флагами «S» или «R» от порта 80 этого веб-сервера к некоторым удаленным IP-адресам. Как ни странно, эти IP-адреса не отображаются в выводе «netstat -n»! И эти IP-адреса похожи на другие IP-адреса, которые злоумышленник использовал ранее.

И симптом (с задержкой ssh ​​до 127.0.0.1) будет длиться даже после того, как я полностью отключу сервер от сети. Только примерно через 10 минут симптом внезапно исчезнет. И такое поведение можно повторить.

Сервер находится за аппаратным брандмауэром, который разрешает только TCP-соединение с этим веб-сервером. Есть ли что-то, чего я не знал, т.е. есть ли способ позволить серверу запоминать некоторые TCP-запросы, которые не отображаются netstat, но при этом связывают ресурсы сервера, поэтому он вряд ли сможет обрабатывать любые последующие TCP-запросы?

В Network Computing есть статья о Атака TCP SYN Flooding и как с ними обращаться.

Оказалось, что атака использовала протокол, который не используется нашим сайтом, поэтому он заблокирован нашим граничным маршрутизатором. Поэтому, несмотря на то, что он переполнял нашу внешнюю трубу, к нашим внутренним серверам, к счастью, не попадал небольшой легальный трафик.

Не вдаваясь в подробности, комбинация описанных вами симптомов наиболее легко поддается диагностике «руткит», поскольку было бы сложно (хотя и вряд ли невозможно) вызвать их каким-либо другим способом.

У меня не было ответа, чем это вызвано, но у меня есть вопросы, чтобы прояснить ситуацию. Вы не сказали, высока ли нагрузка на сервер? Если ответ положительный - что вызывает эту нагрузку - проверьте с помощью команды top. Можете попробовать запустить tcpdump -ntuap? Кажется, одной опции -n недостаточно. Есть ли у него какие-либо другие службы, такие как DNS, FTP? Возможно ли, что задержка ssh вызвана проблемой разрешения DNS или высокой нагрузкой? Как вы подключились к серверу по ssh, если он отключен? Имеет ли сервер доступ к DNS-серверам, если он отключен (нет разрешения = медленное соединение ssh)? Можете ли вы проверить опцию apache "keepalive" и отключить ее, уменьшив для нее интервал.

Проверьте скорость передачи пакетов на интерфейсах с помощью:

netstat -bdh 1

Проверьте, что делает система:

systat -v 1

Проверьте некоторые ограничения bsd с помощью: (LIMIT / USED)

vmstat -z

PS. Ты используешь Apache? Проверить это статистика

PPS. Попробуйте поставить nginx перед этим.

PPPS. Вы используете модуль ядра accf_http?