Я не понимал все эти дела, связанные с безопасностью. Обычная
человеческая психология подразумевает, что также думают многие обычные
пользователи Линукс. К сожалению в моём случае все эти пункты оказались
лишь выдачей желаемого за действительное, не говоря уже о последнем.
Из-за _ последнего.
Как я это обнаружил ? Чтобы подготовиться к тому счастливому дню,
когда постоянное, высоко-скоростное соединение с Интернет будет доступно
в нашем районе, я решил что будет хорошей идеей начать разбираться с
безопасностью. Результаты меня шокировали.
Первый шок я испытал взглянув на долгое время игнорируемые мной файлы
/var/log/syslog*. Несколько записей 'refused connect from' (в
соединении с адреса отказано). Одно соединение по ftp ('connect from'),
которое очевидно было успешным. Уппс. Кажется пользователи интернет
соединяющиеся по dial-up не оставлены кракерами без внимания. И моя
безопасность не непробиваемая. Лучше потратить немного времени, взглянув
на безопасность по-настоящему. И попытаться на сей раз понять
некоторые её аспекты. Это означает чтение книг, FAQ, HOWTO и множество
статей в Web; и проведение некоторых экспериментов.
Эта статья результат моих изысканий. Помните: Я не эксперт, а всего
лишь дилетант, домашний пользователь, пытающийся заставить всё работать
как надо. Я не гарантирую правильность или работоспособность ничего из
описанного здесь.
2. Система
У меня очень простая домашняя сеть, состоящая из двух
машин:
- earth (земля) это Win 95 машина, без принтера или модема.
- heaven (небеса) использует Debian Linux 2.1 (со
всевозможными обновлениями). На ней запущен exim (для локальной почты
и для посылки почты во внешний мир), qpopper (pop3 сервер
используемый earth), и samba (чтобы предоставить earth
доступ к файлам и печати). heaven по запросу соединяется с ISP,
открывая модемное (ppp) соединение. Почта из внешнего мира
собирается при помощи fetchmail.
Эта локальная сеть использует
один из диапазонов IP адресов, зарезервированных для частных сетей,
192.168.1.0/24. heaven имеет адрес 192.168.1.1, earth
192.168.1.2.
Содержимое /etc/hosts на heaven, и
c:\windows\hosts на earth, таково:
127.0.0.1
localhost
192.168.1.1
heaven.my.home heaven
192.168.1.2
earth.my.home earth
Это показывает, что моя
сеть использует имя домена my.home. Это имя не зарегистрировано
и предназначено только для локального использования. Адреса 'message
from (сообщение от) ' и 'envelope from (перенаправлена)' , в почте
отправляемой во внешний мир, будут преобразовываться (в выпусках
LG за Июль
и Сентябрь,
1999, я описывал как сделать это).
3. 'Частные' домашние сети
В моём понимание, безопасность - это
иметь частную сеть. Под этим я понимаю сеть, которая не предоставляет
каких либо внешних сервисов. Она не предоставляет WWW страницы
или файлы. Вы не можете войти в неё при помощи telnet. Она даже не
слушает запросы извне. Если кто-то попытается соединиться, то не
получит ответа. Эта идея недавно была развита Sander Plomp ,
серия статей которого послужила основой для этого фрагмента.
Сеть LAN, которая не соединена с интернет, по определению является
частной сетью. Но это не тот тип частной сети, который я имею в виду. Я
хочу использовать сеть, посылать и принимать почту, ходить по Web,
загружать файлы и т.д. Я просто не хочу чтобы кто-то извне входил
в мою сеть.
Линукс системы в общем случае не являются частными сетями. По
умолчанию, процедура инсталляции дистрибутива Линукс устанавливает
всевозможные виды сетевых сервисов (таких как telnet,ftp,finger, и
т.д.), которые доступны всем в мире, защищённые при этом (если вообще)
лишь паролем. Также, LAN построенные на основе Microsoft Windows в общем
случае не являются частными. Соедините между собой два Win95
компьютера и включите 'file sharing' (разделение (совместное
использование) файлов), и весь мир сможет разделить с вами ваши файлы,
пока вы подключены к интернет :).
Чтобы сделать не-частные сети безопасными, используются различные
приемы; пароли и другие методы обеспечения безопасности, которые
обсуждались в Linux Gazette множество раз, такие как tcpd (врапперы для
tcp, использующие псевдонимы) и фильтрация пакетов на уровне ядра (с
ipchains в качестве пользовательского интерфейса). Эти методы могут
придать некоторую безопасность системе, которая обязательно должна
предоставлять общедоступные сервисы. Они похожи не стражей у дверей,
поставленных там, чтобы удерживать нежелательных персон, в то же время
пропуская желаемых клиентов. Но зачем здесь вообще двери? Я не
хочу, чтобы меня посещали. Моя сеть частная!
Если у нас есть запущенные серверы, доступные из внешнего мира, нам
всегда придётся беспокоиться о том, не сделали ли мы какой либо ошибки в
конфигурации, которая может послужить основой для взлома. Также,
программы серверы часто имеют ошибки в них самих, которые предоставляют
кракерам возможность для проникновения. Одна из таких была недавно
найдена в named. ОК, он был позднее исправлен, так что люди,
имеющие последнюю версию named могут не беспокоиться об
этой ошибке. Но как насчёт следующей ? Лучше вообще не иметь
никаких дверей!
Если вы действительно хотите сделать доступными некоторые
сервисы (например распространение mp3 или что-то ещё), для компьютеров
вне дома, вы должны овладеть более продвинутыми способами соблюдения
безопасности. Но если вы просто хотите иметь дома частную сеть,
читайте дальше.
4. Насколько безопасна ваша сеть ?
Чтобы проверить безопасность
домашней сети, вы можете просканировать её извне, например при помощи
Secure Design.
Щелкните на 'scan me now' и 'basic scan' (просканируйте меня сейчас и
простое сканирование). Попробуйте сканирование как со шлюзовой машины,
так и с других машин вашей сети. Когда я сделал это, то получил второй
"шок". Это было впечатляюще. Длинный список показывающий возможные точки
входа в мою систему: сервисы по разделению файлов Samba, telnet, сервис
печати, X, почтовый сервер, ftp, finger и т.д. У меня были некоторые
рудиментарные меры безопасности, таким образом система была в какой то
мере защищена от серьёзного вторжения (я надеюсь). Но я считаю брешью в
моей безопасности то, что внешний мир знает о наличии у меня почтового
сервера (даже он один даёт возможности для проникновения). Эти сервисы
предназначались для использования в моей домашней сети. И они в любом
случае не для внешнего мира.
Итак: вы просканировали свою систему! Кроме Secure Design, существуют
также другие сервисы сканирования , например Shields Up!, DSL Reports, Sygate Online Services, и
многие другие. Множество подобных сервисов можно найти на Австрийском
сайте, Sicherheit im
Kabelnetzwerk ('Безопасность в кабельных сетях'; там также есть
и почти аналогичная английская версия). Используйте несколько
сканирующих сервисов. Распечатайте результаты. Что из себя представляет
это 'сканирование', я надеюсь станет понятно в ходе чтения статьи.
Вы также можете 'просканировать' вашу систему самостоятельно, вызовом
команды ( после su root) netstat -pan --inet.
Используйте широкое окно xterm, когда будете делать это, т.к. вывод
состоит из довольно длинных строк. Программы, которые имеют 0.0.0.0 в
графе 'Local Address' (Локальный адрес) видны всему миру !
5. Серверы и клиенты
Различие между серверами и клиентами не
всегда понятно пользователям. Если вы хотите использовать ftp, например
(чтобы получать и выкладывать файлы на другой компьютер) вы используете
ftp клиент чтобы соединиться с другим компьютером. Если это всё,
что вы хотите от ftp, то кроме программы ftp-клиента, вам больше ничего
не понадобиться. Ftp сервер нужен, только если вы хотите, чтобы
другие пользователи могли получать файлы с вашего компьютера или класть
их туда. Аналогично с telnet: программа клиент для вашего
собственного использования, программа сервер для использования
другими людьми. Программы клиент и сервер совершенно различны
имеют разные названия; например /usr/bin/telnet для telnet
клиента, /usr/sbin/in.telnetd для сервера. Для новичков
различие не всегда ясно. Если программа установки Линукс спрашивает
'хотите ли вы установить ftp сервер?', пользователи могут подумать 'эээ
... да, я конечно хочу использовать ftp, так что давайте'. Часто вас
даже не спрашивают, а устанавливают ftp сервер по умолчанию.
Один из путей создания частной сети - это не устанавливать вообще
никаких серверов, только клиенты. Но это слишком просто, если вы имеете
дома сеть соединяющую два или более компьютеров. Внутри вашей
сети вы хотите заходить с одной машины на другую при помощи telnet, вы
хотите иметь внутренний почтовый сервис, и т.д. Другими словами вам не
обойтись без серверов.
Основное занятие серверов - слушать. Они ждут сигнала который
скажет: мне нужен твой сервис. Сигнал (по крайней мере для
TCP-основанных сервисов) это специальный IP пакет, называемый SYN
пакетом, который попадает на ваш компьютер и указывает номер сервиса.
Например, номер telnet сервиса (номер которого ждёт программа
in.telnetd, если она запущена) 23. Эти номера обычно называют
номерами портов. Если программа in.telnetd не запущена,
никто не слушает SYN пакетов с номером 23. Т.е., как говорят, 'порт 23
закрыт'.
Порты не существуют сами по себе, как маленькие двери в ваш
компьютер, которые вы можете открыть или закрыть. Порт открыт, если
какой-то из серверов слушает его. В любом другом случае он закрыт. TCP
порт существует только если есть программа которая слушает его, иначе он
не существует !.
Как SYN пакеты попадают в ваш компьютер ? В случае с heaven,
пакет может попасть внутрь тремя разными путями:
- Пакеты посылаемые из earth приходят через Ethernet карту (
также называемую интерфейсом eth0); они адресованы фиксированному IP
адресу 192.168.1.1
- Пакеты из внешнего мира проходят через ppp соединение, или ppp0
интерфейс; который также имеет IP адрес, но он не фиксирован. Для
каждой Internet сессии ISP выделяет 'динамический' адрес, годный
только для текущей сессии.
- Пакеты также могут посылаться из самого heaven,
адресованные самому себе. Этот метод посылки пакетов часто
используется для тестирования; пакеты адресуются на так называемый
loopback интерфейс с адресом 127.0.0.1. Имя localhost указывает
на этот loopback интерфейс, в то время как имя heaven указывает
на 192.168.1.1. (Это очень важный момент для понимания: имена и IP
адреса указывают на интерфейсы, не компьютеры, хотя в
повседневном использовании это различие часто расплывчато.)
Теперь ключевым моментом является то, что сервера обычно
прислушиваются только к пакетам с 'их' номером порта, в независимости
от того, как они попадают в систему. Если мы хотим создать частную
сеть, не предоставляющую каких либо сервисов внешнему миру, мы должны
каким-то образом изменить это.
Было бы прекрасно, если бы все программы-серверы доступные на Линукс
системах, имели опцию указывающую к какому из интерфейсов они
должны прислушиваться. В этом случае мы могли бы просто сказать серверам
не прислушиваться к ppp соединению, и все было бы как надо. Не
понадобились бы какие либо меры безопасности (tcpd,firewall и т.д.); вы
бы использовали их только для 'полноты' безопасности, как дополнительную
предосторожность. Может быть это и случиться когда-нибудь, на на
сегодняшний момент только несколько серверных программ имеют такую опцию
( включая важные exim и samba). Поэтому нам придётся сделать несколько
вещей, чтобы наша сеть стала частной:
- Никогда не повредит последовать распространённому совету 'закрыть
неиспользуемые порты', другими словами не запускать ненужных вам
серверов.
- Заставить сервисы, которые имеют соответствующую опцию, слушать
только внутренние интерфейсы (eth0 и, если нужно, loopback).
- 'супер-сервер' inetd (который используется для
'пробуждения' множества других серверов на Линукс системе) нужно
заменить на xinetd, который имеет опцию
разрешающую слушать только внутренние интерфейсы. ПРИМЕЧАНИЕ:
очевидно, Red Hat Linux 7.0 устанавливает xinetd по
умолчанию.
- Небезопасные сервера, которые не могут быть запущены из
xinetd ( такие как сервер печати lpd), должны быть
по возможности заменены.
- для оставшихся трудных случаев, вам может понадобиться firewall
который будет блокировать SYN пакеты из внешнего мира. Его можно также
использовать для блокирования нежелательного UDP и ICMP доступа.
- для 'дополнительной безопасности', есть несколько других
возможностей. Одна из них - это не использовать IP masquerading
и перенаправление в вашей сети.
6. Удаление ненужных сервисов
6.1 Ненужные сервисы inetd
Во-первых, есть несколько
сервисов, которые запускаются из inetd.conf. Почти все Линукс системы
имеют супер-сервер называемый inetd, его работы заключается в
том, что он слушает множество портов сразу и 'пробуждает' сервисы, когда
это необходимо. Однако он также пробуждает и сервисы которые вам не
нужны.
Примерами ненужных сервисов могут служить:
- ftp сервер. Я не планирую предоставлять какие-либо файлы во
внешний мир, а внутри своей сети я могу использовать Samba (и smbfs),
чтобы передавать файлы. Отсутствие ftp сервера никаким образом
не может помешать вам использовать ftp клиент когда вы этого
захотите,и обмениваться файлами с внешним миром. Но большинство
дистрибутивов, включая Debian, устанавливают ftp сервер по умолчанию.
- portmapper и все связанное с RPC вызовами (по той-же причине).
Portmapper используется для разрешения удалённого вызова процедур.
Проще говоря он нужен вам, если вы используете NFS. Но я не использую
NFS ( Samba, в которой я нуждаюсь в любом случае, т.к. в сети есть
Win95 машина, предоставляет достаточную функциональность по
совместному использованию файлов). Таким образом всё связанное с
portmapper и RPC в inetd.conf, может быть смело закомментировано.
- finger и ident. Существуют разные мнения о пользе 'ident'. Я
удалил его, и не испытал никаких побочных эффектов от этого.
- некоторые другие явно бесполезные вещи, которые могут запускаться
из inetd.conf (такие как saft).
- некоторые сервисы в inetd.conf которые используются
только для тестирования сетей: echo, chargen
(произносится kargen, 'character generator' 'генератор
символов'), discard, daytime, и time. Два
последних (в случае если вы обеспокоены о них) не имеют ничего общего
с автоматическим подводом времени на вашей системе; это просто
сервисы, которые сообщают время на вашей системе другим. Вы не
нуждаетесь ни в них ни в других 'тестовых' сервисах.
Все эти
сервисы могут быть отключены путём закомментирования (помещения символа
# перед ними) соответствующих строк в /etc/inetd.conf, и
перезапуска inetd (в Debian: /etc/init.d/inetd
restart).
6.2 Другие ненужные сервисы
Если сервис не пробуждается при
помощи inetd, он запускается независимо, как 'демон' или
фоновая программа. Среди демонов, которые вам не понадобятся,
кроме portmapper (если он запускается как демон) , локальный nameserver
(сервер имён) (named, произносится name-dee). Не
существует причины по которой небольшая домашняя сеть должна
поддерживать такую вещь. /etc/hosts и C:\windows\hosts
на ваших машинах, и адреса name серверов вашего ISP в
/etc/resolv.conf, решат проблему поиска адресов в вашей сети.
Обычно существует команда, которая предотвращает автоматический
запуск сервера во время загрузки, путём удаления его из директорий
начальной инициализации; например я избавился от сервера
tamagotchi, автоматически установленный Debian 2.1, выдав команду
update-rc.d -f /etc/init.d/tama remove
7. Обеспечение безопасности желаемых сервисов:
не-inetd
Теперь мы примемся за сервисы, которые мы
хотим использовать, но не хотим, чтобы их видели из внешнего
мира. Часто существуют опции конфигурации, которые делают сервис
'частным'. Примеры приведены далее.
7.1 X
Система X была сконструирована как ориентированная на сеть
оконная система, но на самом дела сетевые возможности никогда не
используются в большинстве установок, и представляют угрозу
безопасности. Вы можете избавиться от сетевых возможностей X, путём
запуска X с опцией командной строки: startx -- -nolisten tcp.
Теперь Secure Design не будет указывать в отчёте, что 'X11'
открыты'. Чтобы сделать это постоянным, вы можете сделать синоним
для startx (в ~/.bashrc, /etc/profile, или в другом
подходящим для этого месте):
alias startx="startx -- -nolisten
tcp"
Команда -nolisten tcp на самом деле
должна быть в одном из файлов ресурсов X11, но я до сих пор не нашёл в
каком. В любом случае способ с 'alias' работает. Чтобы протестировать,
запустите (как root) netstat -pan --inet. X теперь не должны
упоминаться в списке. Конечно, было бы лучше, если бы могли сохранить
сетевые возможности X в рамках локальной сети, блокировав только доступ
извне, но я не нашёл способа сделать это.
7.2 Samba
В Debian основанных системах, файл конфигурации для
Samba это /etc/samba/smb.conf (на других системах, это может
быть /etc/smb.conf). Когда я устанавливал Samba, я
выбрал 'let Samba run as daemon' (позволить Samba запускаться в качестве
демона); она не работала правильно из inetd. Любые строки
относящиеся к netbios (который использует Samba) в
/etc/inetd.conf должны быть предварительно закомментированы.
Затем в /etc/samba/smb.conf, в секции [global], я
добавил
bind interfaces only = True
interfaces = 192.168.1.1
После
/etc/init.d/samba restart, демоны Samba 'слушают' только нашу
домашнюю LAN. Они больше не видны остальному миру. Проверьте это при
помощи netstat -pan --inet, и сканирования системы.
7.3 Exim
Exim это почтовый сервер (или Mail Transport Agent, MTA
(агент по пересылке почты)), используемый на моей системе. Вы можете
использовать что-то другое (например sendmail или postfix), но при этом
сохраняется тот-же принцип: ваш 'частный' почтовый агент не
должен 'слушать' внешний мир. Люди, которые посылают вам почту, и
другим пользователям в вашем доме, посылают её на почтовые ящики у ISP
(или на несколько почтовых ящиков у разных ISP). Вы получаете её оттуда
используя fetchmail или ему подобную программу. Люди не могут
посылать почту в вашу сеть напрямую.
У Exim есть опция local_interfaces(локальные интерфейсы)
(которая находится в секции MAIN CONFIGURATION файла
/etc/exim.conf). Это список (IP адресов) интерфейсов, которые
будет слушать exim. Это работает только когда exim запущен как демон,
независимо от inetd. Что настроить эту возможность:
- В /etc/exim.conf, в секции MAIN CONFIGURATION,
введите строку:
local_interfaces = 192.168.1.1:127.0.0.1
(кроме локальной сети, можно указать также и loopback
интерфейс,иначе fetchmail не сможет работать; или вы должны
использовать следующий синтаксис fetchmail -S имя вашей
машины).
- Закоментируйте строку smtp в /etc/inetd.conf .
- В /etc/init.d/exim закомментируйте строку exit 0
в начале файла, сразу же за строкой #usually this is disabled and
exim runs from /etc/inetd.conf. Это заставит exim запускаться в
режиме демона, после вызова /etc/init.d/exim start. Запуск
exim в качестве демона, означает необходимость вызова
/etc/init.d/exim restart после каждого изменения в
exim.conf.
7.4 Junkbuster
Junkbuster это http proxy сервер, который вы
можете сконфигурировать так, чтобы не пропускать рекламу и нежелательную
информацию. Он отлично делает своё дело. В Debian основанных системах,
он слушает порт 5865, в других системах порт 8000. Это устанавливается в
файле /etc/junkbuster/config. По умолчанию, junkbuster слушает
все интерфейсы (другими словами весь мир). Однако вы можете
установить в конфигурационном файле
listen-address 192.168.1.1:5865
и теперь только машины в вашей собственной сети смогут присоединиться
к нему ( включая машину-шлюз, на которой запущен junkbuster,
heaven в данном случае, имя heaven вводится в
'Preferences/Advanced/Proxies' в меню Netscape, не localhost).
7.5 Другие (не-inetd) сервисы
Приведённые выше примеры
единственные. Если на вашей системе работают другие сервисы, вне
inetd, проверьте их документацию на предмет того, как сделать
их 'частными'. Например sendmail можно заставить слушать только
локальную сеть, при помощи:
0DaemonPortOptions=Addr=192.168.1.1
в файле sendmail.cf. Но я не проверял это !
7.6 Оставшиеся проблемные случае, наподобие
lpd
lpd остаётся проблемой. Его нельзя заставить
слушать только внутреннюю сеть. Проще говоря необходимо заменить его на
что-нибудь безопасное. Sander
Plomp рекомендует заменить его на pdq. До сих пор я
ленился сделать это, но я обязательно уделю этому своё внимание в
ближайшем будущем.
Могут остаться и другие проблемные случаи: сервера, которые нужны вам
в вашей сети, но которые нельзя сделать 'частными', и для которых не
существует подобных альтернатив. У меня есть такая проблема с
cannaserver, системой для ввода японских символов с клавиатуры.
Такие сервисы должны быть экранированы от внешнего мира, при помощи
firewall, фильтрующей пакеты. См. секцию 10 этой статьи.
8. Маскировка сервисов inetd через xinetd
На
текущий момент список видимых сервисов системы, согласно Secure Design,
стал таким:
- telnet
- pop3
- lpd (система печати)
Намного меньше чем раньше, но всё
равно слишком много. Telnet и pop3 запускаются inetd/tcpd и поэтому
защищены при помощи host.allow и host.deny, но я не
уверен что это 100 процентная защита. ldp остаётся полностью
открытым и ,как я полагаю, незащищённым. Я думаю, что его нельзя
запустить из inetd.
8.1 Замена inetd
Для сохранения безопасности домашней
сети необходимо заменить inetd на что-нибудь, что может
различать запросы к сервисам исходящие из локальной сети и
извне. Plomp рекомендует tcpserver; Я же попробовал:
xinetd. Сначала убейте inetd, затем установите
xinetd. Важно знать что: Скрипт Debian
/etc/init.d/xinetd запускает не только сам xinetd
демон, но также и portmapper. Мы не хотим использовать portmapper,
который используется для RPC вызовов и NFS, которые мы не используем.
Так что всё относящееся к portmapper в /etc/init.d/xinetd
должно быть закомментировано (# в начале строки).
Один из способов сконфигурировать xinetd для telnet и pop3 это
поместить следующие строки в /etc/xinetd.conf:
defaults
{
instances = 10
log_type = SYSLOG daemon
log_on_success += DURATION HOST
USERID
log_on_failure +=
HOST
interface =
192.168.1.1
}
service telnet
{
socket_type = stream
wait = no
user = root
server =
/usr/sbin/in.telnetd
}
service pop-3
{
socket_type = stream
wait = no
user = root
server =
/usr/sbin/in.qpopper
}
Таким образом, кроме общей секции 'defaults' (установки по
умолчанию), которая описывает интерфейс, есть отдельные секции для
каждого сервиса, который вы хотите запускать. Хотя формат совершенно
отличен, данные для различных секций могут быть найдены в вашем
inetd.conf. См. также man xinetd.conf.
Я запустил xinetd и убедился, что теперь возможно зайти на
heaven при помощи telnet как с самого heaven, так и с
earth. Итак, Secure Design больше не указывает, что моя система
имеет открытые telnet и pop3 порты ! Победа ! ПРИМЕЧАНИЕ: на моей
собственной машине telnet heaven проходит успешно, а telnet
localhost нет. xinetd может производить привязку (bind)
только к одному интерфейсу в один момент времени; в данном случае к
192.168.1.1, но не к localhost (loopback интерфейс 127.0.0.1).
К этому времени, все другие сервисы в /etc/inetd.conf были
закомментированы. Поэтому inetd больше не нужен и можно от него
избавиться. На Debian основанной системе, это можно сделать так:
update-rc.d -f /etc/init.d/inetd
remove
Его место занял xinetd:
update-rc.d xinetd defaults
OK; сделан
ещё один шаг в обеспечении безопасности.
Вывод netstat -pan --inet выглядит примерно так:
heaven:~# netstat -pan --inet
Active Internet connections (servers and
established)
Proto Local
Address Foreign Address State
PID/Program name
tcp
127.0.0.1:25
0.0.0.0:* LISTEN
11391/exim
tcp
192.168.1.1:25
0.0.0.0:* LISTEN
11391/exim
tcp
192.168.1.1:139
0.0.0.0:* LISTEN
10761/smbd
tcp
192.168.1.1:5865
0.0.0.0:* LISTEN
1670/junkbuster
tcp
192.168.1.1:110
0.0.0.0:* LISTEN
161/xinetd
tcp
192.168.1.1:23
0.0.0.0:* LISTEN
161/xinetd
tcp
0.0.0.0:515
0.0.0.0:* LISTEN 148/lpd
MAIN
udp
192.168.1.1:138
0.0.0.0:*
10759/nmbd
udp
192.168.1.1:137
0.0.0.0:*
10759/nmbd
udp
0.0.0.0:138
0.0.0.0:*
10759/nmbd
udp
0.0.0.0:137
0.0.0.0:*
10759/nmbd
raw
0.0.0.0:1
0.0.0.0:*
7 -
raw
0.0.0.0:6
0.0.0.0:*
7 -
Практически все сервисы теперь слушают локальный интерфейс.
Исключение составляет система печати: она слушает по адресе 0.0.0.0(т.е.
везде) на порту 515. Теперь при сканировании системы будет упомянут как
открытый только порт 515. На самом деле, некоторые сервисы сканирования,
ориентированные на Windows, будут сообщать, что система полностью
закрыта, т.к. они не сканируют порт 515.
9. Что насчёт IP Masquerading?
Годами я использовал IP
Masquerading, чтобы дать Windows системе в моём доме доступ в интернет.
Вернее я так думал, пока однажды, в ходе моих изысканий связанных с
безопасностью системы, я не отключил Masquerading, Windows система могла
использовать интернет как и раньше.
В чём дело? Просто earth, Windows машина, использовала всего
три вещи связанные с интернет:
- e-mail, что не требовало от earth связи с интернет, только
с smtp и pop3 серверами, запущенными на heaven;
- Web браузинг; для этого, earth соединяется с junkbuster на
heaven, т.е. опять не напрямую с интернет;
- получение внешней почты от ISP; для этого, пользователь
earth создавал telnet соединение с heaven и запускал
fetchmail.
Т.е., с тех пор, как я 6 месяцев назад установил
junkbuster, earth никогда не соединялась с интернет напрямую, и
Masquerading теперь не нужен. Я не понимал этого. Сам того не зная, я
создал 'proxying firewall'. Это означает, что Masquerading может - и
должен быть отключён. Это даёт несколько преимуществ:
- Простота: ipchains (см. следующую секцию) больше не имеют передней
(FORWARD) цепи, т.е. нам не надо о ней беспокоиться. Нам не нужно
настаивать DNS на earth (вводить имена серверов имён).
- Безопасность: даже если на earth будет установлен троянский
конь,он не сможет связаться с кракерами через интернет.
Единственный минус это то, что earth теперь ограничена
только e-mail и http. Не работает ping и telnet во внешний мир,нет ftp,
Real Audio, chat и т.д. Но на данный момент почта и http это всё, что
требуется. Если на earth потребуются другие сервисы, я полагаю,
что мне придётся установить proxy для них на heaven.
Чтобы отключить IP masquerading и перенаправление (forwarding), в
Debian, вам нужно сделать следующее:
- изменить первую строку в /etc/network/options чтобы она
говорила ip_forward=no
- отключить перенаправление в ядре при помощи echo 0 >
/proc/sys/net/ipv4/ip_forward
- Удалить все специальные команды для Masquerading, такие как
ipchains -A forward -s 192.168.1.0/24 -j MASQ из стартовых
скриптов, ip-up скрипта, или оттуда где они у вас расположены.
10. Закрываем последние двери
Давайте просуммируем всё сделанное
нами: избавившись от ненужных сервисов, переконфигурировав
другие, так чтобы они не слушали шлюзовый интерфейс, завернув
другие в xinetd, и выключив Masquerading, мы уже создали достаточно
безопасную систему, без firewall. Теперь время добавить финальный
штрих: мы создадим вокруг нашей системы firewall для фильтрации пакетов,
при помощи ipchains. Это должно быть последним шагом, а не первым.
Часто можно прочитать совет 'сконфигурировать ipchains так, чтобы всё
было блокировано по умолчанию', и затем сделать исключения для вещей,
которые вы хотите разрешить. Возможно теоретически это и правильно, но
на практике это может привести к разочарованию. Если всё заблокировано,
ваша система просто откажется работать. Вы всё равно будете в той или
иной степени в темноте, решая что разрешить. Так что по умолчанию я
разрешил всё и добавлял ограничения одно за другим. Если система
ломается (т.е. нет ping или невозможно просматривать Web страницы) после
добавления очередного ограничения, значит оно было слишком радикальным и
его необходимо отменить. Установка политики по умолчанию для цепи на
DENY (отказать) или REJECT (отклонить) должна быть последним шагом, а не
первым.
Я начал с разборки firewall (ipchains -F) и запуска
простейшего firewall скрипта с одним правилом:
#!/bin/sh
# simple firewall
ipchains -F input
ipchains -P input ACCEPT
ipchains -A input -i ppp0 -p TCP --syn -j DENY -l
Это блокирует SYN пакеты приходящие из внешнего
интерфейсы,существенно повышая безопасность системы. Никто извне не
может инициализировать соединение; внешние сканирующие сервисы сообщают,
что сайт полностью закрыт (некоторые теперь могут даже назвать его
'скрытым' или 'невидимым'). Но мы можем добавить дополнительные
ограничения. Т.е., мы можем использовать более общие DENY/REJECT
правила и более точные ACCEPT правила.
Перед тем, как вы добавите ограничения, будет полезно провести
некоторые эксперименты. Вы можете создать правила типа ipchains, которые
пропускают пакеты и ведут их лог (-j ACCEPT -l). Таким образом
даже если вы не знаете (как например я), какие пакеты блокировать, вы
можете посмотреть, что происходит 'обычно', держа открытое окно с
tail -f /var/log/syslog в нём. Позже вы можете создать правила,
чтобы блокировать 'ненормальные' пакеты. Я очень рекомендую вам провести
собственные эксперименты и создать правила основываясь на вашем
собственном понимании.
После нескольких таких экспериментов, мой firewall скрипт в
/etc/ppp/ip-up.d выглядит следующим образом. Это подразумевает
что не запущен сервер имён, но у вас есть адреса ДВУХ серверов имён,
предоставленные вашим ISP, в /etc/resolv/conf. Помните о
важности обратных скобок (`)! Они могут исчезнуть, при
копировании информации с этой страницы.
#!/bin/sh
#
Несколько более сложная firewall
# Находим адреса внешних серверов имён
ns="`grep nameserver /etc/resolv.conf | awk
'{print $2}'`"
nameserver1="`echo $ns
| sed -e 's/ .*//'`"
nameserver2="`echo $ns | sed -e 's/.* //'`"
# устанавливает входные (INPUT) правила
ipchains -F input
ipchains -P input ACCEPT
# блокируем вход извне, с фиксированных диапазонов
адресов
ipchains -A input -i ppp0 -s
10.0.0.0/8 -j DENY
ipchains -A input -i ppp0 -s
172.16.0.0/12 -j DENY
ipchains -A input -i ppp0 -s 192.168.0.0/16 -j
DENY
# Блокируем TCP соединения извне
ipchains -A input -i ppp0 -p TCP --syn -j DENY
-l
# Блокируем все UDP пакеты, за исключением ответов
серверов имён
ipchains -A input -i
ppp0 -p UDP -s $nameserver1 53 -j ACCEPT
ipchains -A input -i ppp0 -p UDP -s $nameserver2 53 -j
ACCEPT
ipchains -A input -i ppp0 -p
UDP -j DENY -l
# Разрешаем (пока) но ведём протокол всех ICMP
пакетов
ipchains -A input -i ppp0 -p
ICMP -j ACCEPT -l
# Из локальной сети разрешаем только пакеты
адресованные нам и широковещательные
#
Перенаправление отключено, другие пакеты никуда не пойдут,
но
# теперь мы можем вести их
протокол, чтобы изобличить нелегальную активность в нашей сети
ipchains -A input -i eth0 -d
192.168.1.1 -j ACCEPT
ipchains -A input -i eth0 -d 192.168.1.255 -j ACCEPT
ipchains -A input -i eth0 -j REJECT -l
# Устанавливаем выходные (OUTPUT)
правила
ipchains -F output
ipchains -P output ACCEPT
# Не посылать пакеты на зарезервированные диапазоны
адресов
ipchains -A output -i ppp0 -d
10.0.0.0/8 -j REJECT
ipchains -A output -i ppp0 -d
172.16.0.0/12 -j REJECT
ipchains -A output -i ppp0 -d 192.168.0.0/16 -j
REJECT
# Блокировать все UDP пакеты кроме запросов к
серверам имён
ipchains -A output -i
ppp0 -p UDP -d $nameserver1 53 -j ACCEPT
ipchains -A output -i ppp0 -p UDP -d $nameserver2 53 -j
ACCEPT
ipchains -A output -i ppp0 -p
UDP -j REJECT -l
# Разрешить (пока) ICMP во внешний мир, но вести
протокол
ipchains -A output -i ppp0 -p
ICMP -j ACCEPT -l
# У нас нет правил перенаправления (FORWARD);
перенаправление отключено
Такой firewall (который вы должны адаптировать к вашим персональным
вкусам и нуждам) создаст дополнительную 'оболочку' вокруг вашей системы.
Но ваша безопасности не должна зависеть от firewall; Единственная
причина этому - то, что firewall'ы очень сложные штуки и слишком легко
сделать ошибку при работе с ними. Сначала можно сделать множество других
вещей, чтобы гарантировать безопасность вашей сети.
11. Ссылки и дополнительные материалы
- Amateur Fortress
Building in Linux, part 1, by Sander Plomp (rootprompt.org)
- Amateur Fortress
Building in Linux, part 2, by Sander Plomp (rootprompt.org)
- Real World Linux
Security, by Bob Toxen (Prentice-Hall, 2001).
- What is the
difference between REJECT and DENY? (Linux@home)
- Ipchains log
format (Linux@home). Чтобы понимать, что вы видите при запуске
tail -f /var/log/syslog.
- ICMP
Type numbers (IANA)
- Setting Up
Mail for a Home Network Using Exim (Linux Gazette, July 1999)
- Experiments
with SMTP (Linux Gazette, September 1999)
