Сетевая FAQ

 
 

Сетевая FAQ




А что такое IDENT и зачем он нужен?

   Сервис IDENT предназначен для определения имени пользователя на
   удаленной клиентской системе, который подключился к вашему серверу.
   Сервер ident ожидает соединения на порту 113/tcp (обычно запускается
   через inetd). Протокол ident описан в RFC 1413.

   С работой сервиса IDENT связаны три особенности:
    1. сервис сообщает удаленной стороне имена локальных пользователей,
       что может использоваться при атаке
    2. сервер ident "знает" только о локальных пользователях, что может
       привести к проблемам в случае NAT
    3. если производится фильтрация порта 113/tcp без уведомления другой
       стороны о фильтрации пакета (действие DROP в iptables), это может
       привести к задержке при соединениях с серверами, которые проверяют
       ident

   Для решения первой и второй проблемы разработаны несколько ident
   серверов, которые не сообщают имени пользователя а так же поддерживают
   NAT. Для решения третьей проблемы, фильтруя порт ident, используйте
   REJECT а не DROP.

   Обычно сервер ident можно безболезненно отключить. Практически
   единственным сервисом, для работы которого часто требуется ident,
   является irc.

4.2. Забыл пароль root! Что делать?

   Загрузиться с компакт-диска с linux, подмонтировать корневой раздел,
   отредактировать /etc/shadow.

   Файл shadow состоит из строк, каждая из которых имеет 9 полей
   разделенных двоеточиями. В первом поле хранится имя пользователя, во
   втором - хеш пароля. Удалите содержимое второго поля, сохраните файл,
   отмонтируйте файловую систему, перезагрузитесь с жесткого диска,
   входите в систему как root, без пароля.Не забудьте установить новый
   пароль!
 
3.3. А вот как бы не дать пользователям заниматься тем же?

   В противодействии взломщикам, пытающимся <<прослушать сеть>> надо
   сочетать три метода:

   построение не-sniffer-friendly сетевой топологии.
          Проще говоря - full-switched сети. Поскольку находятся любители
          переполнить таблицу соответствия MAC-адресов портам на
          коммутаторах (switches), активное оборудование тоже нужно
          правильно настраивать. Впрочем, это тема отдельного разговора.

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

          Существующие методики обнаружения снифферов основываются на
          ошибках в реализации. Примером такого способа является
          следуюший:

          Проверяющий создает ethernet фрейм содержащий к качестве MAC
          адреса получателья адрес, неравный адресу подозреваемой машины.
          В качестве IP адреса получателья используется тем не менее IP
          подозреваемой машины. Пакет высылается в сеть. Идея состоит в
          том, что если сетевой интерфейс находится в promisc режиме то
          пакет с MAC не соответствующий MAC адресу карточки все равно
          пройдет через нее и достигнет уровня OS. Остается в качестве IP
          payload положить например ICMP echo-request или TCP SYN для
          некоторого well-known открытого порта. Если вы получили ответ,
          значит карточка находится в смешаном режиме. Если нет - то
          возможно что автор сниффера умнее вас.

          Второй способ проверки основан на том, что теоретически OS
          машины сетевой интерфейс которой находится в смешаном режиме,
          должна обрабатывать бОльшее число пакетов чем та, которая
          слушает только пакеты для себя. Проверка производится так - в
          сегменте сети создается болшое количество траффика, не имеющего
          в качестве адреса получателя подозреваемую машину. После этого
          сравнивается время отклика (например на ping) для подозреваемой
          машины и гарантированно <<чистой.>> Если подозреваемая машина
          сниффит сеть то на нее должна возрасти нагрузка по сравнению с
          <<чистой>> машиной. Способ не работает, если вы не способны
          создать загрузку в сети достаточно серьезную для <<прогрузки>>
          сниферящей машины. Т.е. прогрузить E15K на 10Mb ethernet врят
          ли возможно.

          Примером ПО, позволяющего обнаружить sniffer в сети является
          Sentinel (http://www.packetfactory.net/projects/sentinel/). 
          Эта утилита реализует указанные две проверки плюс еще одну, основанную на
          том, что если сниффер увидит в сети незнакомый ip он сделает
          reverse DNS look-up, который можно увидеть. собственно, опять
          же <<правильный>> сниффер ничего такого делать не будет.

          Существует еще несколько методик поиска, могущих применяться с
          переменным успехом, однако вцелом идеальным решением остается
          применение коммутаторов.

   административные меры
          Как ни странно, увольнение одного нарушителя может надолго
          отбить охоту у других повторять его эксперименты. Безусловно,
          это относится не только к снифферам.
>  1.3. Взломали! Что делать?

   Во-первых, Don't panic! :) Не вы первый, не вы последний. Во-вторых,
   постарайтесь определить для себя, какие действия вы должны
   предпринять. В-третьих, записывайте все, что вы сделали - это поможет
   на досуге сесть, разобраться и сделать выводы.

   Теперь подробней.

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

          Традиционно, для сохранения контроля над взломанной системой,
          взломщики устанавливают т.н. rootkit - набор программ (и иногда
          - модулей ядра), которые скрывают факт взлома от системного
          администратора, обеспечивают доступ к системе, или позволяют
          расширить привелегии атакующего. Если у вас возникло
          подозрение, что в системе установлен rootkit, попробуйте
          проверить ОС с помощью chkrootkit (http://www.chkrootkit.org/). 
          Так же проверьте целостность файлов с помощью Tripwire/Aide 
          (см. так же п. 1.1)

   Приступайте к решению проблемы.
          Не забудьте записывать все происходящее. Если вы решили
          понаблюдать за взломщиком, отдавайте себе отчет, что он может
          это обнаружить и постараться уничтожить все следы. Убедитесь,
          что он не использует ваши сервера как трамплин для новых атак.
          Будет очень неприятно оказаться вовлеченным в DDoS или
          обнаружить у себя склад эксплоитов или вареза (хотя, кому как,
          конечно :) ). Повторю прописную истину, что если вы следите за
          взломщиком командой, не надо пользоваться e-mail для
          координации своих действий.

          Если у вас нет желания и сил проводить расследование,
          переустановите OS с дистрибутива, восстановите данные из
          резервных копий (у вас ведь есть резервные копии? :) ) и
          перечитайте данный FAQ для повышения ее защищенности.

   Сделайте выводы.
          После того как работоспособность восстановлена, займитесь
          <<разбором полетов.>> Как этот взломщик пролез? Как сделать
          так, что бы подобного больше не случалось? Если попытки взломов
          будут повторяться, к чему надо быть готовый. Тут вам
          понадобятся сделанные ранее записи.
 


Создан 07 дек 2011



  Комментарии       
Имя или Email


При указании email на него будут отправляться ответы
Как имя будет использована первая часть email до @
Сам email нигде не отображается!
Зарегистрируйтесь, чтобы писать под своим ником