Monday, August 21st, 2017

NetBSD: безопасность процессов и сервисов

Published on Апрель 7, 2009 by   ·   Комментариев нет

Этот документ охватывает вопросы обеспечения безопасности процессов и сервисов для операционной системы NetBSD. Большинство информации в этом документе может быть также отнесено и к другим BSD системам.

mac internet security software

NetBSD, защита процессов и сервисов: Введение
Начиная с версии NetBSD 1.5 в состав системы входит полный набор, встроенных по умолчанию в ядро, инструментов системного и сетевого администратора.

С 1.5 release установка по умолчанию стала значительно более безопасной, что делает систему более привлекательной.

Наряду с защищенностью, NetBSD — также наиболее переносимая операционная система в мире и при этом сохраняет высокую эффективность, имеет множество дополнительных возможностей и невероятно стабильна.
Цель этого документа
Уже существует большое количество документации по настройке NetBSD firewalls, IP network address translation (IPNAT) и Secure Shell, но все они разрознены и целью данного документа является объединение и некоторая детализация накопленного материала.
Оглавление

1. Краткий обзор основных компонентов
2. Конфигурирование NetBSD Secure Shell
3. Конфигурирование IP Filter
4. IP Network Address Translation
5. Конфигурация и запуск служб
6. Дополнительные/Альтернативные продукты
7. Примеры файлов конфигурации
8. Дополнительные ссылки

Краткий обзор основных компонентов
В этом разделе мы проведем краткий обзор материала, изложенного в остальных главах.

    * Пример установки
    * Чего мы хотим?

Пример установки
Для большей наглядности, давайте представим сеть, с которой нам предстоит в дальнейшем работать:

      Internal Network                 clients, hosts, internal servers
                                                172.16.0.0

                                                    |
                                                    |

      NetBSD 1.5 Firewall                    fxp0 172.16.14.1
      Server with SSH Open                  ------------------
                                             ep0 216.68.250.60
                                                   
                                                    |
                                                    |

      Internet Connection                     gateway switch/
      Provider Network                          router
                                              216.68.250.65

                                                    |
                                                    |

      Big Bad Internet                         insert cloud here

Эта схема довольно обычна и весьма распространена в организациях, получающих доступ в сеть через своего Internet — провайдера.

Конечная цель фаервола состоит в том, чтобы позволить клиентам из сети 172.16.0.0 взаимодействовать с Internet.
Чего мы хотим?
Нам необходимо передать определенный трафик из внутреннего периметра, доступ к самому фаерволу будет осуществляться через SSH.

Данная таблица описывает взаимодействие внутренних сетевых сервисов, фаервола и Internet.

      Service   Connect to Firewall Pass In Pass Out
      ----------------------------------------------
      DNS             NO             YES      YES
      SMTP            NO             YES      YES
      HTTPD           NO             YES      YES
      FTPD            NO             YES      YES
      SSH            YES             YES      YES

Обратите внимани на то, что мы должны иметь возможность транслировать трафик служб DNS, SMTP, HTTP и FTP. Следует также учесть, что правила IPFILTER для создания соединения и передачи трафика очень похожи.
Больше чем один способ…
Примите во внимание, что есть много способов решения данной задачи. Например, такая:

      private network    firewall    DMZ with public    firewall  uplink
                                     web, ftp, etc.      
                                     servers

В демилитаризованной зоне можно было бы разместить общедоступные серверы, сервисы FTP и т.д. В нашем примере мы не будем использовать ДМЗ, так как у нас нет никаких серверов, которые должны быть доступны из Internet, например DNS сервера, являющегося главным для какой-либо зоны.
Конфигурирование NetBSD Secure Shell

    * Настройка /etc/ssh.conf клиента
    * Настройка /etc/ssh.conf сервера

Начиная с NetBSD 1.5 Secure Shell был включен в состав операционной системы. Заданная по умолчанию конфигурация sshd сделана весьма хорошо, однако, давайте разберем настройку демона ssh, дабы иметь об этом представление.
Настройка /etc/ssh.conf клиента

      This is what the default SSH client configuration file looks like on NetBSD 1.5:


      #       $NetBSD: ssh.conf,v 1.1.1.1 2000/09/28 22:10:34 thorpej Exp $
      #
      # This is ssh client systemwide configuration file.  This file provides
      # defaults for users, and the values can be changed in per-user configuration
      # files or on the command line.

      # Configuration data is parsed as follows:
      #  1. command line options
      #  2. user-specific file
      #  3. system-wide file
      # Any configuration value is only changed the first time it is set.
      # Thus, host-specific definitions should be at the beginning of the
      # configuration file, and defaults at the end.

      # Site-wide defaults for various options

      # Host *
      #   ForwardAgent yes
      #   ForwardX11 yes
      #   RhostsAuthentication yes
      #   RhostsRSAAuthentication yes
      #   RSAAuthentication yes
      #   PasswordAuthentication yes
      #   FallBackToRsh no
      #   UseRsh no
      #   BatchMode no
      #   CheckHostIP yes
      #   StrictHostKeyChecking no
      #   IdentityFile ~/.ssh/identity
      #   Port 22
      #   Protocol 2,1
      #   Cipher blowfish
      #   EscapeChar ~

Как видно, названия параметров весьма красноречивы и однозначны.
Настройка /etc/ssh.conf сервера
Файл конфигурации сервера также весьма хорош даже с параметрами по умолчанию.

      #       $NetBSD: sshd.conf,v 1.1.1.1.2.1 2000/10/03 21:55:26 lukem Exp $
      #
      # This is ssh server systemwide configuration file.

      Port 22
      #Protocol 2,1
      #ListenAddress 0.0.0.0
      #ListenAddress ::
      HostKey /etc/ssh_host_key
      ServerKeyBits 768
      LoginGraceTime 600
      KeyRegenerationInterval 3600
      PermitRootLogin yes
      #
      # Don't read ~/.rhosts and ~/.shosts files
      IgnoreRhosts yes
      IgnoreRootRhosts yes
      # Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
      #IgnoreUserKnownHosts yes
      StrictModes yes
      X11Forwarding no
      X11DisplayOffset 10
      PrintMotd yes
      KeepAlive yes

      # Logging
      SyslogFacility AUTH
      LogLevel INFO
      #obsoletes QuietMode and FascistLogging

      RhostsAuthentication no
      #
      # For this to work you will also need host keys in /etc/ssh_known_hosts
      RhostsRSAAuthentication no
      #
      RSAAuthentication yes

      # To disable tunneled clear text passwords, change to no here!
      PasswordAuthentication yes
      PermitEmptyPasswords no
      # Uncomment to disable s/key passwords
      #SkeyAuthentication no

      # To change Kerberos options
      #KerberosAuthentication no
      #KerberosOrLocalPasswd yes
      #AFSTokenPassing no
      #KerberosTicketCleanup no

      # Kerberos TGT Passing does only work with the AFS kaserver
      #KerberosTgtPassing yes

      #CheckMail yes
      #UseLogin no

      #Subsystem      sftp    /usr/local/sbin/sftpd
      #MaxStartup 10:30:60

Этот файл немного жестче, по сравнению с клиентским, например запрещен X11 forwarding, что оправдано для фаервола. Для того, чтобы включить X11 forwarding, необходимо исправить в файле конфигурации следующие строки:

      StrictModes no
      X11Forwarding yes

Администратору нечего редактировать в файле конфигурации sshd, пусть все остается по умолчанию.
Конфигурирование IP Filter

    * Понимание файла ipf.conf
    * Синтаксис
    * Пример написания
    * IP Filter для модемного подключения
    * Дополнительная информация

NetBSD использует ipfilter как фаервол, заданный по умолчанию. С NetBSD 1.5, ipfilter интегрирован в ядро, однако, мы рассмотрим случай, как заставить работать ipfilter и ipnat на более ранних релизах.
Понимание файла ipf.conf
Файл, который управляет правилами для ipfilter обычно называется /etc/ipf.conf. В этом разделе мы пробежимся через параметры настройки, которые нам необходимы, однако несравненно более авторитетные документы могут быть найдены на http://www.obfuscation.org/ipf/ во всем разнообразии.

В основном, ipfilter оперирует двумя основными принципами:

1. Соответствие текущей строке
2. Последнее правило заменяет предидущие

Вот пример самого простого ipf.conf:

      pass in on any all
      block in on any all

Согласно первой строке, разрешен любой трафик на любом интерфейсе. Во второй строке, однако, весь трафик на любом интерфейсе блокирован.
Синтаксис
Главным образом, синтаксис ipfilter прост и почти естественен. Для того, чтобы пропустить трафик используются связки pass in и pass out. Интерфейс может быть как определен, так и не определен:

      pass out on all . . .

И для определенного интерфейса:

      pass out on ep0 . . .

Все замечательно. Взглянем на конфигурацию, которая нам нужна. Мы уже знаем, что нам необходимо пропускать и разрешать соединения по SSH.

      # sshd in from any
      pass in quick on ep0 proto tcp from any to 216.68.250.60/32 port = 22 keep state

Рассмотрим ключевые слова:

    * quick
      Это ключевое слово отменяет любые предыдущие параметры настройки. Оно очень удобно при формировании больших и сложных систем сетевой защиты. В нашем случае это не так, но мы его используем, чтобы быть абсолютно уверенным, что правило будет обработано.
    * proto
      Определяет протокол. Для нашего случая - всегда TCP.
    * port
      Определяет номер порта или его имя в соответствии с записями в /etc/services. В нашем файле конфигурации я делал и так и так.
    * keep state
      Данное ключевое слово описывает уже установленное соединение. (Пр.п - советую более подробно почитать об этом параметре, я, например, понял далеко не сразу его смысл...)

Пример написания
Взглянем на фесь файл вооруженным взглядом.

      Блокирование зарезервированных и частных адресов
      Есть некоторые классы адресов, которые не должны проходить сквозь нашу систему защиты:
          o 127.0.0.0/8 (the localhost)
          o 192.168.0.0/16 (reserved for internal networks)
          o 172.16.0.0/12 (reserved for internal networks)
          o 10.0.0.0/8 (reserved for internal networks)
          o 169.254.0.0/16 (IANA use)
          o 192.0.2.0/24 (netblock for documentation authors)
          o 204.152.64.0/23 (Sun Microsystems cluster interconnects)
          o 224.0.0.0/3 (class D and E multicasts)

Важно обратить внимание, что на одном интерфейсе, fxp0, мы хотим иметь возможность пропускать трафик сети 172.16.0.0 (так как наша внутренняя сеть — 172.16.0.0). Чтобы сделать это, мы можем использовать следующие правила:

            block in quick on any from 192.168.0.0/16 to any
            block in quick on any from 10.0.0.0/8 to any
            block in quick on any from 127.0.0.0/8 to any
            block in quick on any from 0.0.0.0/8 to any
            block in quick on any from 169.254.0.0/16 to any
            block in quick on any from 192.0.2.0/24 to any
            block in quick on any from 204.152.64.0/23 to any
            block in quick on any from 224.0.0.0/3 to any

Обратите внимание, что сеть 172.16.0.0/12 пропущена, хотя и должна была быть заблокирована на интерфейсе ep0. Мы рассмотрим этот момент чуть позже.
Режем все!
Затем мы отключим весь трафик к ep0, следовательно мы не должны явно указывать для блокировки сеть 172.16.0.0.

            # block all
            block in quick on ep0 all

Пишем правила как для клиента Internet
Затем мы хотим заставить систему сетевой защиты иметь возможность работать подобно Internet клиенту:

            # pass out as if we were a single internet client
            pass out quick on ep0 proto tcp from 216.68.250.60/32 to any keep state
            pass out quick on ep0 proto udp from 216.68.250.60/32 to any keep state
            pass out quick on ep0 proto icmp from 216.68.250.60/32 to any keep state

Разрешаем остальное
Теперь добавим протоколы, которые мы хотим разрешить. Обратите внимание, что если Вы имеете один из этих типов сервисов, запущеных на машине с фаерволом,

            # dns stuff
            pass in log proto tcp from any to any port = 53 keep state
            pass in log proto udp from any to any port = 53 keep state

            # pass thru www and ftp
            pass in log proto tcp from any to any port = www keep state
            pass in proto tcp from any to any port = ftp keep state
            pass in proto tcp from any to any port = ftp-data keep state
            pass in proto tcp from any port = ftp-data to any port > 1023 keep state
            pass in log proto icmp all keep state

IP Filter для модемного подключения
Модемное соединение отличает то, что адрес интерфейса каждый раз назначается удаленной стороной и обычно случайным образом. Это, своего рода, вызов ipfilter!

В случае динамического адреса правила фильтрации должны быть написаны с несколько низжей степенью безопасности. Другими словами, ipfilter не может использовать в правилах IP адрес, хотя использование имени интерфейса тоже дает достаточную гарантию безопасности. (Пр.п — у PF данная возможность есть, сам переводил FAQ. То, что я перевожу сейчас или слишком старо, или действительно ipfilter не может использовать динамический адрес в правилах фильтрации?)

Вот пример правил, использующих IP адрес:

      # pass out as if we were a single internet client
      pass out quick on ep0 proto tcp from 216.68.250.60/32 to any keep state
      pass out quick on ep0 proto udp from 216.68.250.60/32 to any keep state
      pass out quick on ep0 proto icmp from 216.68.250.60/32 to any keep state

Для модемного соединения мы должны заменить набор правил на это:

      # pass out as if we were a single internet client
      pass out quick on ep0 proto tcp from any to any keep state
      pass out quick on ep0 proto udp from any to any keep state
      pass out quick on ep0 proto icmp from any to any keep state

Ну и что хорошего мы вынесли из этой главы?
Во первых — блокируйте все лишнее, во вторых — если не используется какая-либо служба и не предполагается доступ ее из Internet, разрешайте только входящий трафик. Не используйте для соединения с системой ничего, кроме ssh.
Дополнительная информация
Я строго рекомендую прочитать ipf howto для получения более детальной информации и изучения различных стратегий фильтрации. (Пр.п — я тоже)
IP Network Address Translation

    * Как должен выглядеть наш /etc/ipnat.conf
    * Другие интересные вещи
    * ipnat и модемное соединение

Начиная с NetBSD 1.5, ipnatтакже включен по умолчанию в ядро. Задачей IPNAT является взять исходный IP адрес и транслировать его в адрес другого сетевого интерфейса. Это также известно как masquerading.
Как должен выглядеть наш /etc/ipnat.conf
Это очень просто:

      map ep0 172.16.0.0/16 -> 216.68.250.60/32 proxy port ftp ftp/tcp
      map ep0 172.16.0.0/16 -> 216.68.250.60/32 portmap tcp/udp 10000:20000
      map ep0 172.16.0.0/16 -> 216.68.250.60/32

Первым правилом мы проксируем ftp через интерфейс ep0. Следующая строка разрешает tcp/udp, устанавливая соответствие между внутренним адресом и внешним адресом. Последняя строка просто маскарадит адреса сети 172.16.0.0/16 в адрес 216.68.250.60. Этих правил вполне достаточно для наших целей.
Другие интересные вещи
Вот несколько довольно интересных моментов. Например, как мы можем пробросить соединение внутрь нашей сети:

      map fxp0 216.68.250.60/32 -> 172.16.14.1/32 (add whatever service here)

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

Кончно, большинство администраторов разместило бы общедоступные сервисы (например вэб-сервер) в пределах ДМЗ и использовали бы ipfilter, разрешив к нему только http и ssh.

Но если у Вас больше, чем один внешний адрес? Также все просто:

      ap ep0 172.16.0.0/16 -> 216.68.250.0/24

Наконец, диапазон portmap может быть откорректирован, если Вы чувствуете в этом необходимость.
ipnat и модемное соединение
Очень много домашних пользователей используют модемное соединение, для связи с Internet и у большинства из них — динамчески назначаемый IP адрес. Может показаться, что мы не сможем использовать ipnat, которому требуется указание внешнего IP адреса для работы, но это только кажется… В случае постояннгого соединения мы делаем так:

      map ep0 172.16.0.0/16 -> 216.68.0.0/16

Это правило говорит нам, что все адреса сети 172.16.0.0/16 транслируются в любые адреса сети 216.68.0.0/16. Учитывая тот факт, что при модемном соединении всегда назначается один адрес, записываем правила так:

      map ppp0 172.16.0.0 -> 0/32 proxy port ftp ftp/tcp
      map ppp0 172.16.0.0 -> 0/32 portmap tcp/udp 40000:60000
      map ppp0 172.16.0.0 -> 0/32

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

    * Включение IP Forwarding
    * /etc/defaults/rc.conf и /etc/rc.conf
    * Запуск служб

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

    * ipfilter
    * ipnat
    * ipmon
    * sshd

Дополнительно, может потребоваться включить форвардинг пакетов в ядре.
Включение IP Forwarding
Включаем форвардинг, используя sysctl:

      sysctl -w net.inet.ip.forwarding=1

Для того, чтобы сохранить изменения полсле перезагрузки, внесите изменения в /etc/sysctl.conf:

      net.inet.ip.forwarding=1

Для релизов NetBSD, младших, чем 1.5 необходимо в ядре установить поддержку ipfilter:

      options         PFIL_HOOKS              # pfil(9) packet filter hooks
      pseudo-device   ipfilter

Если Вы хотите, чтобы был доступен ipmon:

      ptions         IPFILTER_LOG    # ipmon(8) log support

/etc/defaults/rc.conf и /etc/rc.conf

Начиная с NetBSD 1.5, все rc настройки, принимаемые по умолчанию, находятся в файле /etc/defaults/rc.conf. Размещение пользователем в файле /etc/rc.conf управляющих инструкций, имеет приоритет над /etc/defaults/rc.conf. Целью этого является сделать систему более стабильной , так как ранее все настройки располагались в /etc/rc.conf и могли быть по неосторожности или в ходе обновлений привести к краху системы.

Что необходимо разместить в /etc/rc.conf:

      #
      # see rc.conf(5) for more information.
      #
      # Use program=YES to enable program, NO to disable it. program_flags are
      # passed to the program on the command line.
      #

      # Load the defaults in from /etc/defaults/rc.conf (if it's readable).
      # These can be overriden below.
      #
      if [ -r /etc/defaults/rc.conf ]; then
      . /etc/defaults/rc.conf
      fi

      # If this is not set to YES, the system will drop into single-user mode.
      #
      rc_configured=YES

      # Add local overrides below
      #
      ipfilter=YES
      ipnat=YES
      ipmon=YESipmon_flags="-sn"
      sshd=YES

На i386 платформах также стоит разрешить wscons:

      wscons=YES

Запуск служб
Есть два пути активации сервисов:

1. Перезагрузка системы
2. Запуск rc скриптов

Я предпочитаю запуск сервисов вручную, чтобы убедиться в их работоспособности и после этого перезапустить систему, для того, чтобы выяснить — происходит ли нормальный запуск во время начальной загрузки.
Запуск «вручную»
Зпуск любого сервиса осуществляется очень просто:

      # /etc/rc.d/[service_name] start

Также сервис может быть и остановлен:

      # /etc/rc.d/[service_name] stop

Или перезапущен:

[cc lang="bash" tab_size="2" lines="-1"]
      # /etc/rc.d/[service_name] restart

Для запуска нашей системы сетевой защиты нам необходимо выполнить:

      # /etc/rc.d/sshd start
      # /etc/rc.d/ipfilter start
      # /etc/rc.d/ipnat start
      # /etc/rc.d/ipmon start

Запуск sshd и ipmon может производиться в произвольном порядке, но ipfilter должен быть запущен раньше ipnat. Дополнительные/Альтернативные продукты

    * Portsentry
    * NMAP

NetBSD 1.5 уже достаточно укомплектовано средствами мониторинга и контроля информационной безопасности, но системный администратор наверняка захочет посмотреть средства сторонних разработчиков.
Portsentry
Portsentry — довольно обширный инструмент. (Пр.п — достаточно подробную статью на русском можно найти здесь — http://linuxcenter.ru:8080/lib/security/) Будучи установленной, данный инструмент отслеживает все попытки соединения с хостом и сканирования портов хоста.

Установить Portsentry можно из системы портов:

      cd /usr/pkgsrc/security/portsentry
      make && make install

Файл конфигурации будет находиться в:

      /usr/pkg/etc/portsentry.conf

Конфигурация портов:
В файле конфигурации есть три набора портов, для TCP и UDP соответственно, выбор производится раскомментированием, по умолчанию используется средний набор.

      # Un-comment these if you are really anal:
      TCP_PORTS="1,7,9,11,15,70,79,80,109,110,111,119,138,139,143,512,513,514,515,540,
      635,1080,1524,2000,2001,4000,4001,5742,6000,6001,6667,12345,12346,20034,30303,32
      771,32772,32773,32774,31337,40421,40425,49724,54320"

      #UDP_PORTS="1,7,9,66,67,68,69,111,137,138,161,162,474,513,517,518,635,640,641,66
      6,700,2049,32770,32771,32772,32773,32774,31337,54321"
      #
      # Use these if you just want to be aware:
      #TCP_PORTS="
1,11,15,79,111,119,143,540,635,1080,1524,2000,5742,6667,12345,12346,
      20034,31337,32771,32772,32773,32774,40421,49724,54320"
      UDP_PORTS="
1,7,9,69,161,162,513,635,640,641,700,32770,32771,32772,32773,32774,31
      337,54321"
      #
      # Use these for just bare-bones
      #TCP_PORTS="
1,11,15,110,111,143,540,635,1080,524,2000,12345,12346,20034,32771,32
      772,32773,32774,49724,54320"
      #UDP_PORTS="
1,7,9,69,161,162,513,640,700,32770,32771,32772,32773,32774,31337,543
      21"

Обнаружение Advanced Stealth
Для этого необходимо указать номера портов, которые portsentry будет мониторить в расширенном режиме:

      ADVANCED_PORTS_TCP="1023"
      ADVANCED_PORTS_UDP="1023"

Также можно исключить некоторые порты (типа NetBIOS)

      # Default TCP ident and NetBIOS service
      ADVANCED_EXCLUDE_TCP="113,139"
      # Default UDP route (RIP), NetBIOS, bootp broadcasts.
      ADVANCED_EXCLUDE_UDP="520,138,137,67"

Файлы конфигурации
В NetBSD эти файлы живут в /usr/pkg/*:

    * # Hosts to ignore
      IGNORE_FILE="/usr/pkg/etc/portsentry.ignore"
    * # Hosts that have been denied (running history)
      HISTORY_FILE="/usr/pkg/etc/portsentry.history"
    * # Hosts that have been denied this session only (temporary until next restart)
      BLOCKED_FILE="/usr/pkg/etc/portsentry.blocked"

Варианты реакции:
# 0 = Do not block UDP/TCP scans. # 1 = Block UDP/TCP scans. # 2 = Run external command only (KILL_RUN_CMD)

      BLOCK_UDP="1"
      BLOCK_TCP="1"

Сброс маршрута:
Строка, сбрасывающая маршрут для NetBSD уже раскомментирована:

      # Generic BSD (BSDI, OpenBSD, NetBSD, FreeBSD)
      KILL_ROUTE="/sbin/route add $TARGET$ 333.444.555.666"

Отметим, что для некоторых систем может быть изменен набор правил фильтрации, например для ipfw FreeBSD:

      # For those of you running FreeBSD (and compatible) you can
      # use their built in firewalling as well.
      #
      #KILL_ROUTE="/sbin/ipfw add 1 deny all from $TARGET$:255.255.255.255 to any"

Возможно Вы используете другой тип сетевой защиты, но portsentry допускает использование синтаксиса Вашего пакетного фильтра.
TCP Wrappers:
В этом разделе находится текст, помещенный в /etc/hosts.deny.

      #
      KILL_HOSTS_DENY="ALL: $TARGET$"

Внешние команды:
Внешняя команда или скрипт могут быть вызваны следующим образом:

      #KILL_RUN_CMD="/some/path/here/script $TARGET$ $PORT$"

Здесь также может стоять и команда, изменяющая правила фильтраци.
Значение счетчика сканирования
Этот параметр указывает порог срабатывания portsentry. По умолчанию стоит 0, но 1 позволяет более-менее исключить ложные срабатывания.
Port Banner
Этот параметр описывает сообщение, возвращаемое в ответ на попытку подключиться к порту.

      #PORT_BANNER="** UNAUTHORIZED ACCESS PROHIBITED *** YOUR CONNECTION ATTEMPT HAS
      BEEN LOGGED. GO AWAY."

NMAP
NMAP — это сканер портов. Позволяет сканировать отдельные хосты и диапазоны сетей. В настоящее время данная утилита доступна через систему портов.
Устанавливаем:

      # cd /usr/pkgsrc/net/nmap
      # make && make install

<Используем: У NMAP очень много вариантов использования, поэтому мы рассмотрим только 3: 1. Сканирование одного хоста 2. Сканирование группы хостов 3. Сканирование NetBSD firewall Сканирование одного хоста: В качестве примера будем использовать очень небезопасную машину внутри сети:

      nmap -P0 172.16.14.12

      Starting nmap V. 2.53 by fyodor@insecure.org ( www.insecure.org/nmap/ )
      Interesting ports on marie.ipsosasi.net (172.16.14.12):
      (The 1504 ports scanned but not shown below are in state: closed)
      Port       State       Service
      7/tcp      open        echo                    
      9/tcp      open        discard                
      13/tcp     open        daytime                
      19/tcp     open        chargen                
      21/tcp     open        ftp                    
      23/tcp     open        telnet                  
      37/tcp     open        time                    
      111/tcp    open        sunrpc                  
      . . .

Сканирование группы хостов
Тоже ничего сложного:

      nmap -P0 172.16.14.0/24 >nmap.out

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

      Starting nmap V. 2.53 by fyodor@insecure.org ( www.insecure.org/nmap/ )
      All 1523 scanned ports on  (172.16.14.0) are: closed
      Interesting ports on somename.blah.net (172.16.14.1):
      (The 1521 ports scanned but not shown below are in state: filtered)
      Port       State       Service
      23/tcp     open        telnet                  
      68/tcp     closed      bootpc                  

      All 1523 scanned ports on somename.blah.net (172.16.14.2) are: closed
      Interesting ports on somename.blah.net (172.16.14.3):
      (The 1520 ports scanned but not shown below are in state: closed)
      Port       State       Service
      23/tcp     open        telnet                  
      79/tcp     open        finger                  
      80/tcp     open        http

Сканирование NetBSD firewall
Ну и наконец — гвоздь программы:

      Starting nmap V. 2.53 by fyodor@insecure.org ( www.insecure.org/nmap/ )

      Interesting ports on  (216.68.250.60):
      (The 1522 ports scanned but not shown below are in state: filtered)
      Port       State       Service
      22/tcp     open        ssh                    

      Nmap run completed -- 1 IP address (1 host up) scanned in 772 seconds

Время сканирования впечатляет…

zp8497586rq





































































Смотрите также:

Tags: , , , , , , , , , , , , , ,

Readers Comments (Комментариев нет)

Comments are closed.

Exchange 2007

Проведение мониторинга Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 3)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Проведение мониторинга Exchange 2007 с помощью диспетчера System ... [+]

Практическое рассмотрение перехода с Exchange 2003 на Exchange 2007 (часть 1)

Введение В этой статье из нескольких частей я хочу показать вам процесс, который недавно использовал для перехода с существующей среды Exchange 2003 ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 2)

Если вы пропустили первую часть этой серии, пожалуйста, прочтите ее по ссылке Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (Часть ... [+]

Мониторинг Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 2)

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Мониторинг Exchange 2007 с помощью диспетчера System Center Operations ... [+]

Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 5)

Если вы пропустили предыдущие части этой серии статей, перейдите по ссылкам: Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 1) ... [+]

Установка и настройка Exchange 2007 из командной строки (Часть 3)

If you missed the previous parts in this article series please read: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 1)

Инструмент ExRCA Текущий выпуск инструмента предоставляется только в целях тестирования и оснащен 5 опциями: Тест подключения Outlook 2007 Autodiscover Тест подключения Outlook 2003 RPC ... [+]

Развертывание сервера Exchange 2007 Edge Transport (часть 5)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Развертывание сервера Exchange 2007 Edge Transport (часть 1) Развертывание ... [+]

Установка и настройка Exchange 2007 из командной строки (часть 2)

Если вы пропустили первую статью данного цикла, пожалуйста, перейдите по ссылке: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование интегрированных сценариев Using Exchange Server 2007 – часть 2: генерирование отчетов агента Transport AntiSpam Agent

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Использование интегрированных сценариев Using Exchange Server 2007 – часть ... [+]