Назад | Перейти на главную страницу

Несколько служб, отличных от HTTP, 1 статический IP-адрес

У меня проблема, связанная с наличием нескольких служб, отличных от http, к которым мы хотели бы получить доступ через WAN. SSH - это основной протокол, который мы будем использовать, а также FTP.

Вот как все устроено. У нас есть единый публичный IP-адрес. Этот адрес находится на нашем ASA (базовая лицензия 5505), который привязан к серверу в нашей DMZ. Это компьютер с Windows Server 2012, на котором прямо сейчас запущены службы IIS для выполнения обратного прокси-сервера для наших служб HTTP и HTTPS.

Как лучше всего разрешить внешний доступ к таким службам, как SSH / FTP? Есть ли (желательно бесплатный) Linux-эквивалент ISA server / Threat Management Gateway 2010 (ни один из которых у меня не доступен в качестве опций)

Я знаю, что могу использовать функцию NAT от ASA для перенаправления портов напрямую на машины, но это не кажется таким безопасным. В идеале я хотел бы иметь возможность создавать записи DNS A (например, ftp.domain.com), которые указывают на статический IP-адрес, перенаправляются в DMZ (как сейчас), а затем определяют тип запроса и пересылают это к нужному хосту? Возможно ли это можно сделать с помощью IPTables в Linux?

Спасибо за ЛЮБУЮ помощь!

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

На прикладном уровне у вас больше возможностей. Это будет зависеть от протокола и возможно только для некоторых протоколов. HTTP-прокси - один из примеров этого.

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

Я знаю следующие варианты выполнения этой работы:

  • Используйте разные номера портов для разных SSH-серверов
  • Используйте IPv6, чтобы у вас было достаточно IP-адресов для каждого хоста
  • Инкапсулируйте трафик SSH в другом протоколе. Это может быть SSH внутри SSH с использованием хоста-бастиона.

Что касается FTP, я рекомендую не использовать этот протокол. Два отдельных TCP-соединения, используемых FTP, затрудняют работу. А отсутствие проверки целостности в протоколе означает, что он не очень безопасен. Я рекомендую sftp (который похож на ftp, но работает через ssh) или HTTP, если вам нужен анонимный доступ.

Есть несколько инструментов, которые обрабатывают управление угрозами на разных уровнях (большинство из них являются реактивными, потому что, будучи зашифрованным протоколом, трудно что-либо увидеть, пока это не будет записано в журналы). SSH, как правило, является безопасным протоколом при правильной настройке. Обычно я выступаю ПРОТИВ, чтобы SSH открывался для Интернета, если это не абсолютно необходимо. Даже в этом случае хорошей альтернативой будет иметь что-то вроде защищенного URL-адреса, по которому вы можете войти в систему и временно занести в белый список свой текущий IP-адрес. В настоящее время существует ооочень много ботов, сканирующих уязвимые SSH-машины, и вы никогда не знаете, когда в каком-либо приложении появится новая уязвимость.

Что касается FTP, ИМНШО, НЕ ИСПОЛЬЗУЙТЕ ЕГО!!! Скорее используйте его альтернативу на основе SSH, SFTP. FTP - это протокол, по которому даже пароли обычно отправляются в виде открытого текста вместе со всеми данными. Прошло много времени с тех пор, как я перестал даже рассматривать FTP как альтернативу практически чему угодно.