РегистрацияСкрытый туннель между двумя системами + взаимное предоставление сервисов
Здравствуйте.
У меня есть сложная реальная задача, которую непременно требуется решить.
Есть два сервера, подключенных к интернету (в разных AS). Они предоставляют различные сервисы (в большом количестве), в том числе услуги прокси-серверов и NAT.
К обоим я, если постараюсь, могу получить доступ с высокими правами (и совсем никаким, нулевым, UID'ом). Пользоваться услугами обоих я могу и сейчас. Защищены обе системы, предположим, обычными "админами", старающимися не перетрудиться, но и премию не потерять, невысокуя квалификацию компенсируют непредсказуемостью маневров и используемого арсенала.
Требуется:
1) требуется связать эти системы туннелем:
– зашифрованным: траффик должен быть защищен от прослушивания;
– скрытым: траффик должен быть необнаружим с помощью распространенных IDS и анализа журналов серверов;
– защищенным от вторжения: его присутствие не должно ослабить надежность ни одной из систем, помешать правильной работе IDS;
Все параметры важны одинаково.
2) обеспечить возможность взаимного предоставления безопасных (защищенных как от внешних вторжений, так и от обнаружения администраторами) сервисов:
– HTTP proxy;
– Jabber proxy/server;
если с первым пунктом ясно, куда копать: ssh-туннель поверх http- или icmp-туннеля, то второй вызывает у меня мысли только о руткитах. Руткиты — это очень грустно: я о них знаю только, что они либо легко обнаруживаются, либо тяжело пишутся, и времени для глубокого изучения этой темы у меня нет.
Подскажите solution, пожалуйста.
комментариев: 9796 документов: 488 редакций: 5664
И вы уверены что это трудно обнаружить? А как же логи всего чего не попадя, начиная от fw который пишет разрешение коннекта по ssh и кончая системными сервисами типа syslog и прочих.
А это уже ближе к делу.
Кажется, можно показать, что в общем случае проблема такого характера сводится либо к модификации существующего софта либо к руткитам. В принципе, это почти одно и то же. Иначе, будет игра на том что "авось не обнаружат в логах" и "авось логи не смотрят" т.п.
По-моему, это можно сделать (по кр. мере почти эквивалентное этому по функционалу) посредством настроек fw (iptables, pf, ets).
Примерно как и предыдущее + устанавливать куда-то джаббер, а вот чтобы при рестарте он загружался... ну можно стартовые сервисы поправить в надежде что "не увидят" :))
И зачем для этого поднимать http и jabber туннели между хостами? Ssh не достаточно? Пессимист, вы unknown...
В общем, вопрос применения схемы на совести спросившего. Как по мне, так у руткитов тех же есть вполне мирное применение: стеганография для ряда сервисов, выполняемых на собственном десктопе (да, заметание логов от могущих внезапно нагрянуть маски-шоу), по сути схожее решение с шифрованием данных (crypto переводится как "скрытие").
Кстати, в логах пишется и изменение конфигурационных файлов системных сервисов, да и просто время от времени администратор может их просматривать (так то можно было лишь настроить легальным образом все конф. файлы в надежде что не заметят их изменений).
комментариев: 2 документов: 1 редакций: 0
Пока еще не надо заметать следы хака, надо сделать сам хак. Желательно — красивый. :)
в этой части задания говорится только о линке. Он должен быть, насколько возможно, скрыт от наблюдателей — промежуточных маршрутизаторов (среди которых есть достаточно умные).
Даже со штатным гнутым софтом можно немало наделать, если умеючи.
Угу, точно можно. Не знаю только, что лучше — всё в один ssh-туннель, или по отдельности? HTTP траффик сам по себе внимания привлекает гораздо меньше, чем всякие необычности.
Да стартовые сервисы править будет надо по-любому, даже если вся эта хакерская (в лучшем смысле этого слова) затея окажется черезчур заморочной.
Да, я знаю. Как и то, что администраторы упомянутых серверов в логи полезут только в случае серьезных проблем. И доступ к серверу журналирования я могу, теоретически, получить с теми же трудностями, что и к этим двум. Может и плох из меня кракер, но я осилю
%)))
P. S.: информация о технологии предоставляется на нейтральных основаниях и только спрашивающий несёт ответственность за её использование в целях противоречащих закону.