Использование ipfw для защиты от сканирования

Одна из самых отказоустойчивых и неприхотливых платформ. Описание процесса установки, настройки и эксплуатации.
Аватар пользователя
Администратор
Сообщений: 161
Зарегистрирован: 27 фев 2011, 17:40
Откуда: откуда и все :)
СообщениеДобавлено: 20 май 2011, 14:06
В данной статье остановимся лишь на тех особенностях, которые будут использоваться нами для построения правил защиты. Все примеры относятся к версии ipfw, используемой начиная с 5-й версии FreeBSD. В более ранних версиях некоторые особенности могут не работать или иметь несколько отличный от приведенного в статье синтаксис.
В общем виде правило ipfw задается следующим образом:
Номер Действие Протокол from Источник to Приемник [Опции]
Интерес для нас представляет секция Опции, которая может содержать один или несколько следующих параметров:
via интерфейс - имя интерфейса системы (например, сетевой карты). Если этот параметр задан, правило будет применяться только к пакетам, проходящим через указанное устройство;
{in | out} - опционально может быть указано направление прохождения пакета (in - входящий по отношению к машине, на которой работает ipfw; out - исходящий; по умолчанию учитываются как входящие, так и исходящие пакеты);
frag - правилу будут удовлетворять только фрагментированные пакеты (кроме первого фрагмента);
icmptypes types - тип icmp-пакетов (types может иметь следующие значения: 0 - echo replay, 3 - destination unreach, 5 - redirect, 8 - echo request, 11 - time-to-live exceeded, 12 - IP-header bad, 15 - information request, 16 - information replay и другие);
iplen length - длина IP-пакета;
Оригинал статьи

established - TCP-пакеты с установленными флагами RST или ACK, то есть пакеты, принадлежащие установленному соединению;
ipttl ttl - пакеты с определенным временем жизни (time-to-live, ttl);
setup - пакеты, запрашивающие установление соединения (с установленным битом SYN, но без флага ACK);
limit {src-addr | src-port | dst-addr | dst-port} N - вводит ограничение на число одновременных соединений, удовлетворяющих правилу. Все последующие (свыше N) соединения будут считаться несоответствующими данному п равилу. Признаки src-addr, src-port, dst-addr и dst-port указывают, что учитываются пакеты с одного IP-адреса источника, с порта источника, на один адрес приемника или на порт приемника соответственно.
В качестве примера приведу правило, позволяющее ограничить число TCP-соединений на данную машину с одного IP-адреса (признак src-addr):
# ipfw add number allow tcp from any to me setup limit src-addr 5
Данное правило пропустит только первые 5 запросов на соединение (признак setup), поступившие с одного IP-адреса, а для остальных пакетов с этого адреса проверка на соответствие правилам будет продолжена, и в случае закрытого брандмауэра они будут отброшены после проверки всей цепочки правил.
uid user - пакеты, посланные указанным пользователем или адресованные указанному пользователю;
gid group - пакеты, посланные пользователем, принадлежащим группе group или адресованные пользователю этой группы;
tcpwin win - TCP-пакеты с указанным размером окна приема (window);
tcpflags флаги - задает перечень флагов TCP-пакета, которые должны быть установлены. Допускаются значения fin, syn, rst, psh, ack и urg. Символ "!" перед именем флага означает, что данный флаг должен быть сброшен.
Любой из этих параметров может предваряться служебным словом "not", которое инвертирует значение параметра.
Как мы видели, один из способов сканирования портов удаленной машины - посылка пакетов с установленным флагом FIN. Такое сканирование может быть выполнено, например, с помощью команды:
# nmap -sF
В нормальной ситуации данный флаг сигнализирует об окончании сеанса связи, но поскольку в данном случае связь не установлена, то запрошенная система отвечает сообщением об ошибке, по наличию которого хакер и определяет, открыт сканируемый порт или нет. Защититься от подобного сканирования можно с помощью следующего правила:
# ipfw add number reject tcp from any to any not established tcpflags fin
В соответствии с ним все TCP-пакеты с установленным флагом FIN, но не принадлежащие установленным соединениям (not established) будут отбрасываться.
Сканирование с установкой или сбросом всех флагов (параметры nmap -sX и -sN соответственно) можно сделать бесполезным, добавив в цепочку следующие два правила:
# ipfw add number reject tcp from any to any tcpflags fin, syn, rst, psh, ack, urg
# ipfw add number reject tcp from any to any tcpflags !fin, !syn, !rst, !psh, !ack, !urg
То есть если в пакете все флаги установлены или, наоборот, сброшены, то пакет будет отброшен соответствующим правилом.
От сканирования, выполняемого с параметрами nmap -sT и -sS ("соединение" и "полусоединение"), нельзя закрыться запрещающим правилом, подобно изложенному выше, поскольку при данных методах сканирования соединение устанавливается (или начинает устанавливаться) в соответствии с протоколом TCP. Естественно, мы не можем запретить все пакеты, запрашивающие соединение с тем или иным портом. Однако, поскольку и реакция на такие пакеты будет стандартной, то злоумышленник уже не сможет получить дополнительную информацию о системе, такую, например, как версия ОС. Кроме того, интенсивность сканирования можно существенно снизить, установив ограничение "limit" на число соединений с одного адреса (см. выше).
Кроме того, нельзя забывать, что грамотная политика фильтрации пакетов, когда разрешаются только соединения с нужными портами и с ограниченного числа адресов, позволит сделать сканирование практически бесполезным.
Раз уж мы взялись защищать нашу сеть от хакеров, заодно добавим правило против спуфинга (подмены IP-адресов на легальные). Смысл спуфинга заключается в том, что злоумышленник отсылает пакеты от имени доверенного хоста, подменяя IP-адрес отправителя. Например, мы можем закрыть доступ к порту 110 (POP3) со всех адресов, кроме локальной подсети 193.163.0.0/24. Но если хакер пошлет на порт 110 пакет от имени пользователя локальной сети, например, подставив адрес 193.163.0.12, то он получит доступ к порту. Конечно, исключить такую возможность можно грамотной маршрутизацией, но подстраховаться никогда не вредно. Добавим в цепочку еще одно правило:
# ipfw add 10007 deny ip from any to any not verrevpath in
В результате пакеты, пришедшие с интерфейса, отличного от того, куда они были бы направлены маршрутизатором, будут отброшены. Это исключит возможность выдать себя за легального пользователя локальной сети, подключившись извне (конечно, только в том случае, когда локальная сеть и "внешний мир" подключены через разные интерфейсы).
Кроме того, никогда не лишне (особенно когда речь идет о безопасности) вести журнал всех "злонамеренных" пакетов. Для этого правило нужно снабдить ключевым словом "log" после действия, которое должно быть выполнено по отношению к пакету, удовлетворившему данному правилу, например:
# ipfw add 10007 deny log ip from any to any not verrevpath in
Теперь, если пакет будет получен с "неправильного" интерфейса, то syslogd получит сообщение уровня LOG_SECURITY, которое будет обработано в соответствии с настройками в /etc/syslog.conf. Кроме того, ядро системы должно быть собрано с опцией "IPFIREWALL_VERBOSE". Чтобы снизить вероятность переполнения диска журнальной информацией, предусмотрен механизм ограничения числа одинаковых записей. Ограничение по умолчанию задается опцией ядра, например:
option "IPFIREWALL_VERBOSE_LIMIT=100"
В этом случае в журнал будут записаны только 100 записей, соответствующих правилу. Кроме того, это значение можно переопределить для конкретного правила, задав секцию logamount number после ключевого слова log:
# ipfw add number reject log logamount 5 tcp from any to any not established tcpflags fin
Журналирование - функция очень полезная, однако если у Вас недостаточно места на диске, то использовать ее следует очень осторожно, поскольку одним из распространенных последствий DoS-атак является переполнение раздела файловой системы журнальной информацией и, как следствие, - отсутствие какого бы то ни было контроля за попытками подключения к системе и отказ таких служб, как сервер электронной почты, которые требуют дискового пространства для своей работы, а порой и полная неработоспособность системы. К слову заметим, что последствия этого можно снизить правильной разбивкой диска на разделы, когда не особо важная, но быстрорастущая информация (от ipfw, apache, squid и т.д.) записывается на свой раздел и не влияет на разделы, хранящие, например, логи авторизации и спул электронной почты.
Итак, мы создали набор базовых правил, которые существенно усложнят сканирование нашей системы. Теперь нам нужно записать эти правила в конфигурационный файл, чтобы при перезагрузке системы они автоматически активировались. Для ipfw есть две возможности увековечить наши правила.
Во-первых, это конфигурационный файл /etc/rc.firewall. По умолчанию в нем уже содержится два правила с номерами 100 и 200 (иногда и правило 300), которые служат для обеспечения доступа к "внутреннему" интерфейсу системы lo0 и ограничивают доступ к "внутренним" адресам системы 127.0.0.0/8. По аналогии с ними можно дописать в этот файл и наши правила в виде:
$fwcmd add ПРАВИЛО
Например, упомянутые выше два правила заданы следующим образом:
$fwcmd add 100 pass all from any to any via lo0
$fwcmd add 200 deny all from any to 127.0.0.0/8
Однако нужно иметь в виду, что /etc/rc.firewall - системный файл, и его лучше не изменять (это позволит избежать проблем, например, при обновлении системы с помощью cvsup).
Более правильным является конфигурация ipfw как пользовательского. Для этого в файле /etc/rc.conf поменяем тип брандмауэра:
firewall_type="/etc/ipfw.conf"
Теперь создадим файл ipfw.conf в папке /etc (впрочем, имя файла может быть любым удобным для Вас) и поместим в него наши правила так, как если бы вводили их с консоли, только без имени программы ipfw. То есть выглядеть этот файл будет примерно так:
# Запрет X-сканирования:
add 1001 reject log tcp from any to any tcpflags fin, syn, rst, psh, ack, urg
# Запрет N-сканирования:
add 1002 reject log tcp from any to any tcpflags !fin, !syn, !rst, !psh, !ack, !urg
# Запрет FIN-сканирования:
add 1003 reject log tcp from any to any not established tcpflags fin
# Защита от спуфинга
add 1004 deny log ip from any to any not verrevpath in

# Ограничение числа одновременных соединений:
add 1005 allow ip from any to any setup limit src-addr 10

:::
Комментарии, как обычно, предваряются символом "#". Теперь при загрузке системы автоматически будут включаться правила сначала из rc.firewall, затем из пользовательского файла (в нашем случае ipfw.conf).
На первый взгляд запрет нестандартных пакетов может показаться излишним, поскольку в случае "закрытого" брандмауэра они в любом случае будут отброшены последним запрещающим правилом. Однако их явный запрет позволит вести запись попыток сканирования тем или иным методом, что даст возможность вовремя обнаружить чей-то интерес к Вашей системе и предпринять ряд превентивных мер. Кроме того, размещение этих правил в начале цепочки позволит несколько разгрузить систему в случае массированного сканирования, поскольку нестандартные пакеты не станут проверяться на соответствие всем правилам цепочки, а будут отброшены в ее начале.
Итак, мы рассмотрели основные пути защиты сети, первая линия обороны которой построена на базе FreeBSD с брандмауэром ipfw. Безусловно, соответствующей настройки еще не достаточно, чтобы спать спокойно. Ежедневный анализ log-файлов, непрерывное повышение общей грамотности в области протоколов, межсетевых экранов и т.д. - вот базовые составляющие безопасности. Надеюсь, что эта статья позволит Вам более осознанно строить защиту Вашей сети.
Проблема, это задача в решении которой никто не заинтересован.
СВС

Вернуться в FreeBSD

Кто сейчас на форуме

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 0


Яндекс.Метрика
cron