RSS

Компьютерная терминология    1_9  A  B  C  D  E  F  G  H  I  J  K  L  M  N  O  P  Q  R  S  T  U  V  W  X  Y  Z  .....  A  Б  В  Г  Д  Ж  З  И  К  Л  М  Н  О  П  Р  С  Т  У  Ф  Х  Ц  Ч

Вопрос сокрытия портов

В статье рассматривается вопрос сокрытия портов используемых какими-либо программами или демонами. Подразумевается протокол tcp, хотя некоторые выкладки применимы и к udp (даже еще и проще). В принципе, сокрытие трояна и работа с ним может также осуществляться и через icmp, но целью данной статьи было рассмотрение сокрытия именно портов.

Предположим, мы поставили на хост-жертву руткит - вроде все круто, система затроянена, и, находясь на данной машине, мы уже с трудом сможем обнаружить этого трояна, а если еще и сам кернел затроянен, то это достаточно не тривиальная задача. Но админ додумался просканировать данную машину с других хостов и определить, что открыт порт, который ранее не использовался на данной машине. Удостоверившись в отношении того, что данный порт не должен быть здесь открыт, - он проводит анализ системы и обнаруживает ваш руткит, патчит систему и все больше у вас этого шела нет.

Теперь рассмотрим, как нам можно обмануть сканер, чтобы нас нельзя было обнаружить. Как известно установка соединения происходит в 3 этапа - это так называемое "three-way hand shake" (rfc793).

Для начала рассмотрим стандартную установку соединения.

На первом этапе мы получаем запрос на соединения в форме - SYN.

Далее мы отправляем свой запрос на соединение и подтверждаем прием последовательности - SYN, ACK.

И, наконец, мы получаем подтверждение приема нашей последовательности.

Таким образом, соединение успешно установлено.

Теперь посмотрим, что происходит в случае отказа сервера от соединения (т.е. если, например, у нас порт не открыт).

Мы получили запрос на соединение - SYN.

Т.к. порт не слушается, то ядро отвечает ответом - RST, ACK.

Т.е. соединение не установлено - в общем случае это означает, что порт не слушается, либо там установлен и грамотно настроен межсетевой экран.

 

Бесплатная консультация специалиста

Loading…
 

По спецификации TCP не оговаривается передача данных именно после установления соединения, т.е. при желании можно подкрутить клиент и сервер, чтоб первый отправлял данные в 1-ом SYN пакете, а второй считал данные из этого SYN пакета. Т.е. таким образом, мы можем произвести идентификацию (проверка доступности пользователю данного ресурса) клиента. В случае если клиент не прошел идентификацию - не верная строка или вообще данные отсутствуют, то сервер должен послать ему RST. При таком раскладе, простой порт сканер не сможет определить реально открытый порт, а специально подкрученный сканер уязвимостей не сможет пройти идентификацию - что позволит нам сохрани тam невидимость. Идентификация по адресу и порту не рассматривается, в связи с возможностью компрометации - хотя бы тем же самым spoofing'ом.

Для улучшения системы защиты нашего порта можно добавить еще и аутентификацию (проверка пользователя на соответствие). Т.е., предположим, соединение осуществляется только при условии, что строка идентифицирована. Для аутентификации клиента можно использовать криптографию с открытым ключом. У клиента находится секретный ключ, которым он зашифровывает строку для идентификации и некоторую случайную последовательность. Получившуюся строку отправляем серверу вместе со случайной последовательностью. На стороне сервера находится публичный ключ (ну не будем же мы в тылу врага оставлять секретный ключ) которым происходит расшифровка строки, которая затем разбивается для проверки с внутренней строкой и полученной случайной последовательностью. Таким образом, мы снижаем вероятность обнаружения нашего трояна - даже если появится специализированный сканер (хотя в при условии применения криптографии это сделать затруднительно) нашего руткита, да и в трафике не будет видно реальной строки для идентификации. В принципе, можно вообще весь трафик между клиентом и сервером шифровать.

Итак, при соответствующем уровне "невидимости" нашего руткита на хосте-жертве (сокрытие процессов, открытых портов и т.п.) - путем сокрытия порта мы можем повысить его прозрачность и для постороннего взгляда извне - получаем практически пожизненный шел (пока кому-нить не вздумается переставить систему), или нас не выдаст какой-нибудь IDS, обнаруживший подозрительный трафик на неизвестный порт с условием того что он еще и закрыт.

Cкрытые каналы в протоколе HTTP

В любом наборе информации, будь то исполняемая программа, графическое изображение или сетевой протокол есть пути переноса дополнительных «скрытых» данных. Такая возможность есть и практически на всех уровнях модели OSI. Широко известны инструменты туннелирования, использующие служебные заголовки протоколов сетевого уровня TCP/UDP. Однако практическое применение таких туннелей ограничено из-за их низкой пропускной способности. Более широкие перспективы для построения скрытых коммуникационных каналов основываются на использовании прикладных протоколов. Здесь есть возможность быстрой передачи больших объемов произвольной информации в качестве полезной нагрузки самого протокола, а не кода внутри его служебных заголовков. Одним из таких протоколов является HTTP.

Основное поле для использования скрытых каналов это локальные сети, имеющие доступ в Интернет. Как правило, работа с сетевыми сервисами за пределами домашней сети жестко регламентируется различными системами контроля доступа. Эта статья является практической, в ней мы рассмотрим два способа использования протокола HTTP для туннелирования произвольных данных протоколов сетевого уровня. Оба метода могут быть использованы как для доступа из локальной сети за ее пределы, так и для обратной задачи.

ССTT

СCTT – (“Covert Channel Tunneling Tool”) Инструмент Туннелирования в Скрытых Канналах. CCTT позволяет создавать коммуникационные каналы через системы контроля сетевого доступа с потоками данных, которые позволяют: получить shell на внешнем сервере из внутренней сети. предоставить shell с сервера находящегося во внутренней сети внешнему серверу. установить канал позволяющий TCP соединения (SSH, SMTP, POP и т.д.) между внешним сервером и компьютером во внутренней сети.

Для использования CCTT необходимо установить его клиентскую часть в локальной сети и серверную во внешней сети. В качестве канала передачи между ними могут выступать TCP, UDP соединения и TCP соединения с использованием метода HTTP CONNECT через локальный HTTP прокси сервер или через цепь HTTP прокси серверов. Одна из интересных особенностей CCTT это работа в режиме реверсивного прокси. ССTT клиент устанавливает соединение с CCTT сервером (TCP, UDP, HTTP CONNECT) и регистрируется на нем как реверсивный прокси. CCTT сервер, находящийся за пределами локальной сети, принимает соединения от клиентов, находит соответствующую запись в таблице зарегистрированных реверсивных прокси и использует уже открытое соединение с соответствующим прокси, как канал для передачи данных. ССTT клиент, принимает эти данные и устанавливает соединение с нужным сервисом внутри локальной сети. Так же есть возможность кодировать поток данных между CCTT клиентом и сервером. FIREPASS

В большинстве локальных сетей использование метода HTTP CONNECT запрещено на внутреннем HTTP прокси сервере. В этом случае может работать технология, реализованная в проекте Firepass. Здесь используется метод HTTP POST. Firepass клиент располагается на сервере внутри локальной сети и «слушает» несколько TCP/UDP портов. Как только устанавливается соединение с ним, Firepass клиент отправляет HTTP/1.1 POST запрос на веб сервер во внешней сети. Он может сделать это как напрямую, так и с использованием локального HTTP прокси сервера. Ресурс, на который он отправляет POST запрос, это Firepass сервер. В заголовке первого HTTP запроса указываться адрес, порт и протокол сервиса во внешней сети с которым необходимо установить соединение. Firepass сервер, получив первый запрос, порождает новый процесс – “менеджер соединения”, который и будет устанавливать дальнейшее соединение со внешним сервисом.. Далее Firepass клиент с некоторым интервалом отправляет серверу HTTP POST запросы с TCP/UDP данными, полученными от своего клиента. Эти данные отправляются на целевой сервис с использованием «менеджера соединения». Данные же полученные от сервиса проходят обратный путь и возвращаются Firepass клиенту в качестве HTTP ответа на очередной POST запрос. В некоторых случаях, если позволяет конфигурация сети и DMZ возможно проникновение извне в локальную сеть через, например, корпоративный веб сервер. В этом случае Firepass сервер работает на корпоративном веб сервере, а Firepass клиент общается с ним из внешнего мира. Одно из достоинств технологии использованной в Firepass это множество вариантов размещения его серверной части. Требуется только веб сервер и возможность устанавливать с него исходящие TCP/UDP соединения.

ЗАКЛЮЧЕНИЕ

Приведенные здесь методы, показывают только несколько вариантов использования протокола HTTP в качестве среды передачи произвольных данных. В целом же можно сказать, что если в локальной сети есть клиент с возможностью отправлять/принимать HTTP запросы (методы GET, POST, CONNECT), то для него так же всегда есть возможность использования HTTP как туннеля для протоколов сетевого и прикладного уровня.

seo & website usability inet html os faq hardware faq memory video cpu hdd mainboard faq printer & scaner modem mobiles

Windows 10 | Registry Windows 10 | Windows7: Общие настройки | Windows7: Реестр | Windows7: Реестр faq | Windows7: Настроки сети | Windows7: Безопасность | Windows7: Брандмауэр | Windows7: Режим совместимости | Windows7: Пароль администратора |  |  |  |  | Память | SDRAM | DDR2 | DDR3 | Quad Band Memory (QBM) | SRAM | FeRAM | Словарь терминов | Video | nVIDIA faq | ATI faq  | Интегрированное видео faq | TV tuners faq | Терминология | Форматы графических файлов | Работа с цифровым видео(faq) | Кодеки faq | DVD faq | DigitalVideo faq | Video faq (Архив) | CPU | HDD & Flash faq | Как уберечь винчестер | HDD faq | Cable faq | SCSI адаптеры & faq | SSD | Mainboard faq | Printer & Scaner | Горячая линия бесплатной юридической консультации | Благотворительность

На главную | Cookie policy | Sitemap

 ©  2004