Сетевая безопасность с /proc/sys/net/ipv4
 
Автор: (C) David Lechnyr
Перевод: (C) А. Куприн

В дополнение к набору правил, используемых сетевым экраном, файловая система /proc предлагает возможность существенно усилить сетевую безопасность. К сожалению, большинство из нас не знает об этом "звере" ничего, кроме домыслов и слухов. Здесь мы рассмотрим основные элементы файловой системы /proc/sys/net/ipv4, необходимые для усиления общей сетевой безопасности Linux-сервера.

Возможно, что файловая система /proc -- одна из наиболее часто пренебрегаемых частей кофигурации сетевых экранов. Псевдофайловая структура /proc даёт возможность работать со структурами внутренних  данных ядра ОС, что позволяет как получать информацию о системе, так и влиять на её работу, меняя специфические настройки. Одна часть /proc доступна только для чтения, в то время как другая может быть изменена. Чаще всего она рассматривается, как виртуальная файлова система не занимающая реального дискового пространства: файлы создаются только в момент обращения к ним. В этой статье мы сфокусируем внимание на /proc/sys/net/ipv4.

Чтобы воспользоваться файловой системой /proc, при сборке ядра нужно включить две опции. Опция CONFIG_PROC_FS позволяет вам получить доступ к /proc и просматривать её, а CONFIG_SYSCTL -- это та мелочь, что позволяет вам изменять элементы /proc без необходимости перезагрузкки системы или перекомпиляции ядра. Настройки доступны в процессе загрузки только после того, как файловая система /proc будет смонтирована.

Специальные настройки ICMP

Как правило, "пингование"используется для того, чтобы определить доступные в сети компьютеры-"хосты". Обычно это делается посылкой на требуемую машину пакетов ICMP ECHO. На первый взгляд в этом нет ничего криминального, но сетевые администраторы часто блокируют такой траффик для того, чтобы запутать пингующих. Эти команды отключают защиту:
echo "0" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
echo "0" > /proc/sys/net/ipv4/icmp_echo_ignore_all
Перенаправление ICMP сообщений может причинять неудобства. Если ваша машина не используется как маршрутизатор, то вы, вероятно, захотите отключить эту возможность:
echo "0" > /proc/sys/net/ipv4/conf/all/accept_redirects
Иногда вы будете сталкиваться с маршрутизаторами, рассылающими неверный ответ на кадры с широковещательными [broadcast] запросами. Это нарушение RFC 1122, "Requirements for Internet Hosts -- Communication Layers" ("Требования к Интернет-хостам -- коммуникационный уровень"). Как результат, такие события регистрируются ядром. Чтобы избежать заполнения лог-файла ненужной информацией, можно сказать ядру не накапливать эти предупреждения:
echo "1" > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses

Специальные настройки IP

Как ни странно, но перенаправление пакетов [IP forwarding] пакетов между сетевыми интерфейсами включается по умолчанию в стартовых скриптах многих систем. Если вы не заинтересованы в пересылке трафика между интерфейсами или, если вы имеете только один интерфейс, то перенаправление пакетов лучше отключить. Имейте ввиду, что смена этого значения сбросит все параметры конфигурации  (восстановит умолчания), а именно: в значения из RFC1122 для узлов сети (hosts) и в значения из RFC1812 для маршрутизаторов. Так что лучше изменять настройку переадрисации перед всеми остальными настройками в /proc.
if [ -r /proc/sys/net/ipv4/ip_forward ]; then
  echo "Disabling IP forwarding"
  echo "0" > /proc/sys/net/ipv4/ip_forward
fi
Если же вы решите включить ретрансляцию пакетов, то придется изменить и настройку rp_filter, которая часто неправильно понимается сетевыми администраторами. rp_filter может отвергать поступающие пакеты, если их исходный адрес не соответствует сетевому интерфейсу, на который они прибывают -- это помогает предотвратить IP spoofing (подмену имен узлов в пакетах, спуфинг). Включение rp_filter, однако, имеет последствия: если ваш хост имеет несколько IP-адресов на разных интерфейсах или, если отдельный интерфейс имеет несколько IP-адресов, то в один прекрасный момент вы можете обнаружить, что ядро блокирует "честный" трафик. Важно помнить, что даже если rp_filter не включен, защита против спуфинга всё равно включена. Только эта защита направлена против спуфинга внутренних адресов; внешние адреса всё ещё могут оказаться подмененными. По умолчанию rp_filter отключен. Следующие комнады его включат:
if [ -r /proc/sys/net/ipv4/conf/all/rp_filter ]; then
  echo "Enabling rp_filter"
  echo "1" > /proc/sys/net/ipv4/conf/all/rp_filter
fi
Возможно,  в последнем примере вы заметили подкаталог "all". В /proc/sys/net/ipv4/conf находятся подкаталоги для каждого из сетевых интерфейсов и ещё один каталог, называемый "all". Если нужно, чтобы изменения в настройке коснулись всех интерфейсов, то используйте каталог "all", если же нет -- то только каталог с именем интерфейса, параметры которого вы хотите изменить.

Если ядро собрано с опцией CONFIG_SYNCOOKIES, то можно опционально включать и отключать защиту от атак "отказ в предоставлении доступа" (SYN flood attack). Обратите внимание на опционально -- это означает, что при сборке ядра с этой возможностью по умолчанию она остается отключена. Защита работаер так: при переполнении очереди неустановленных сокетов (backlog queue) система отсылает 'syncookies' (Linux начинает "отбрасывать" эти пакеты. Прим. перев.). Часто не понимается, что очереди незавершённых соединений (socket backlogging) не поддерживаются в новейших операционных системах, это означает, что ваши сообщения об ошибках не могут быть правильно обработаны "атакующей" системой. Итак, если вы видите в ваших логах предупреждения о том, что кто-то пытается вас "утопить" (synflood warnings), то прежде, чем включать tcp_syncookies, удостоверьтесь, что всё это не результат работы перегруженного сервера. Также могут быть проблемы при соединении с другими хостами, пытающимися "достучаться" до вас. Но если не смотря ни на что, вы всё же хотите включить syncookies, то выполните следующее:

if [ -r /proc/sys/net/ipv4/tcp_syncookies ]; then
  echo "Enabling tcp_syncookies"
  echo "1" > /proc/sys/net/ipv4/tcp_syncookies
fi
Обычно, хост не обладает контролем над маршрутом отдельных пакетов за пределами ближайшего маршрутизатора [first hop]. Маршрутизатор сам решает проблемы по успешной доставке пакетов к другим хостам. IP Source Routing (SRR) -- это метод определения точного маршрута, по которому пакет должен следовать, чтобы добраться до пункта назначения. Вообще говоря, это плохая идея для защиты: кто угодно хоть с каплей зравого смысла может направлять пакеты к вам через заслуживающий доверия интерфейс (trusted interface), и в некоторых случаях эффективно обходить защиту. Типичным примером является SSH или telnet трафик, который блокируется на одном интерфейсе и, который мог бы прибывать на другой интерфейс вашего хоста используя SRR, чего могут не предвидеть настройки вашего сетевого экрана. Вероятно, вы захотите отключить эту возможность:
if [ -r /proc/sys/net/ipv4/conf/all/accept_source_route ]; then
  echo "Disabling source routing"
  echo "0" > /proc/sys/net/ipv4/conf/all/accept_source_route
fi
Пакеты, которые имеют исходные адреса с неизвестным маршрутом, классифицируются как "марсиане" ("martians"). Например, если у вас две разные подсети подключены к одному хабу, то маршрутизаторы в каждой из них будут видеть друг друга как "марсиан". Чтобы регистрировать такие пакеты в журнале ядра (kernel log), а такую команду нельзя выполнять в начале сетевых настроек, выполните следующее:
if [ -r /proc/sys/net/ipv4/conf/all/log_martians ]; then
  echo "Enabling logging of martians"
  echo "1" > /proc/sys/net/ipv4/conf/all/log_martians
fi

Дополнительные источники информации

Для получения более подробной информации относительно файловой системы /proc, можно обратиться к документации, поставляемой вместе с исходниками ядра Linux. Особую помощь окажет Documentation/filesystems/proc.txt, написанный Bowden, Bauer и Nerin. Кроме этого, можно просмотреть Documentation/networking/ip-sysctl.txt Kuznetsov'а и Savola.

David Lechnyr

Дейвид -- сетевой администратор в отделе кадров Университета штата Орегон (Human Resources department of the University of Oregon). Имеет степень магистра в социологии, а также сертификаты MCSE+I (дипломированный инженер по системам корпорации Microsoft), CNE (дипломированный инженер по сетевым программным средствам NetWare) и CCNA (администратор компьютерных сетей). Работает с Linux последние пять лет, акцентируя своё внимание на системной безопасности, поиску неисправностей в сетях, написанию PHP-скриптов и интеграции web/SQL.
Copyright (C) 2002, David Lechnyr.
Copying license http://www.linuxgazette.com/copying.html
Published in Issue 76 of Linux Gazette, March 2002
Вернуться на главную страницу