id: Гость   вход   регистрация
текущее время 01:09 07/04/2020
Автор темы: quartz22, тема открыта 25/09/2013 22:32 Печать
Категории: инфобезопасность, атаки, операционные системы
http://www.pgpru.com/Форум/ПрактическаяБезопасность/ЗащитаПростогоСервераНаWindows7
создать
просмотр
ссылки

Защита простого сервера на windows 7 или XP


Привет всем. Хотел бы решить вот такую задачу. Работает у меня windows ноутбук. Интернет по adsl модему он же роутер. Для работы на нём подключаюсь к нему по rdp с андроид планшета.
На нем работает клиент получающий реалтайм данные, пусть будут к примеру температура воздуха и интенсивность солнечного света.
Обработанные данные способны повлиять на ход геополитических процессов в мире:), откуда можно оценить степень параноидальности.
Можно ли обеспечить гарантированную защиту без учёта физического доступа к ноутбуку?
Linux с wine опробованы, с моей win прогой не справились. Благодарю.


 
На страницу: 1, 2 След.
Комментарии
— Беня (25/09/2013 23:03)   <#>
Защиту чего от кого? От взлома ноута или от проникновения в домашнюю сетку через взлом роутера?
— quartz22 (25/09/2013 23:27)   профиль/связь   <#>
комментариев: 5   документов: 1   редакций: 0
Думаю лучше то и другое. Гарантия что кроме меня никто не увидит результаты обработанных данных, выводимые на экран, и невозможность заполучения алгоритма(программы) обработки этих данных.
— Беня (26/09/2013 01:26)   <#>
Предположим, что роутер правильно настроен и оснащен надежной прошивкой. Не имеющей ни заводских мастер-паролей от производителя, ни уязвимостей в коде прошифки. А за счет файервола на роутере достучаться можно только на один порт машины с виндой и никуда больше. На этом порту вращается идеальный rdp-сервер, в котором нет никаких уязвимостей. Аутентификация двухсторонняя идеальна и вы можете быть уверены на 100%, что подключились именно к своему компу, а не какому-то чудаку-по-середине, который решил проксировать ваш трафик. И ваш сервачок на 100% уверен, что вы таки действительно работаете с ним по собственной воле, а не под принуждением.
Дальше возникает вопрос утечки данных через дешифровку перехваченного трафика. И вот тут всплывает, а на базе какого генератора случайных чисел работает это шифрование? В виндах они все уязвимые и запрещены к использованию в криптографических целях даже при работе с данными уровня "сыкрэтно", не говоря уже о "гостайна" :)
Потому и придется заворачивать rdp-трафик в дополнительный туннель, средствами сродни openssh или openvpn. Это проще, чем переделывать rdp-сервер.
— gyhsal (26/09/2013 02:15)   <#>
про нюансы настройки RDP.
— quartz22 (26/09/2013 17:29)   профиль/связь   <#>
комментариев: 5   документов: 1   редакций: 0
Спасибо ребята. Завернув rdp-трафик в openvpn, пробадает ли смысл использования двухсторонней аунтефикации? opensource всё таки

Под двухсторонней авторизацией я понимаю сторонний сервис, который мне например пришлёт sms с кодом подтверждения. Или что то ещё?
— gegel (26/09/2013 21:43)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
без учёта физического доступа к ноутбуку

Если это утверждение в силе, то можно сделать реализацию намного проще и надежнее.
При установке ПО на ноутбук выбираете и сохраняете AES-ключ, которым будет шифроваться ответ, и ключ аутентификации для HMAC. Запрос содержит timestamp в качестве nonce для ответа. На ноутбуке поднимаете udp-сервер, отвечающий только если в поле timestamp значение строго больше такого в последнем запросе. Запрос аутентифицируете HMAC. Для шифрования ответа используете CTR. Аутентифицируете ответ с помощью HMAC.
Возможные пути атак:
– на ПО роутера и далее на Windows;
– переполнение буфера в вашем сервере (надо везде перепроверять при разработке ПО сервера).
— Гость (27/09/2013 03:03)   <#>

... Kerberos?
— Гость (27/09/2013 03:07)   <#>
Вообще, в качестве дополнительной меры для безопасной авторизации часто используется:
  1. Блокировка всех IP файерволлом кроме некоторых, с которых совершается легитимное соединение.
  2. Статическое прописывание MAC-адресов для всех сторон.
  3. Включение аудита (например, логов файерволла), который будет писать обо всех подозрительных попытках авторизации, сканирования портов и т.д.
— quartz22 (27/09/2013 20:24, исправлен 27/09/2013 20:26)   профиль/связь   <#>
комментариев: 5   документов: 1   редакций: 0

gegel думаю круто, но не мой уровень познаний и практики


... Kerberos?


вроде opensource, значит пригодный? надо про него углубится, что там за третья сторона


Блокировка всех IP файерволлом кроме некоторых, с которых совершается легитимное соединение.

они всеж динамические сейчас


Статическое прописывание MAC-адресов для всех сторон.

MAC в открытом виде идёт?

— Гость (28/09/2013 03:24)   <#>

Да, opensource, но подумайте, нужно ли это в вашем случае. Вроде Kerberos — сервер аутентификации, который аутентифицирует одну сторону перед другой, сам при этом являясь третьей стороной.


Тогда разве что port knocking или целиком перейти на инфраструктуру скрытых сервисов Tor, но это может быть совершенно неоправданным переусложнением для вашего случая.


Да, но виден только в локальной сети. Его статическое прописывание есть некоторая мера против ARP spoofing'а в локалках. Плюс, к тому же, ядро в логах обычно ругается на попытки ARP spoofing'а, что есть плюс для аудита.
— gegel (29/09/2013 00:47)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
Исходя из поставленной задачи, напрашивается вопрос: зачем в данном решении нужны авторизация, Kerberos, согласование сессионных ключи и т.п., если речь идет об физическом доступе админа к обоим сторонам? Также зачем нужна привязка по МАС, если речь идет о работе через интернет?
Представьте себе пусковую установку ядерных ракет, к которой прикрутили rdp и завернули в openvpn для надежности: наверное, для совместимости, чтобы пускать можно было с ноута под Win32, андроидного планшета и в крайнем случае, айфона :)
Не стоит искать себе приключений. Используйте статические ключи с обеих сторон, стандартное шифрование и аутентификацию: никаких особых знаний для этого не надо, и в итоге написание такого приложения умещается в пару десятков строчек кода и несравненно проще, чем прикручивать все вышеописанное.
Если уж так хочется использовать готовое, то, мне кажется, достаточно использовать одну openvpn со статическими ключами, а на роутере оставить открытым один UDP-порт для нее и запретив все остальные. Для надежности можно добавить каскадом еще один роутер от другого производителя, желательно с открытым ПО (типа Микротика).
— Гость (29/09/2013 02:52)   <#>

А разве РоутерОС (то ПО, что на Микротиках) не проприетарное решение, пускай и на базе Линуксов?
Некоторые крэкнутые версии РоутерОС идут шли одно время с откровенными бэкдорами. На рутрекере был топик соответствующий.
— Гость (29/09/2013 06:07)   <#>

Топикстартер нам не сообщил никаких деталей, но сказал абстрактное «хочу, чтобы всё было и от всех было защищено». Гипотетический противник (АНБ) может атаковать и через локалку, т.к. договориться с провайдером ему не проблема. Вот тут статический MAC может помочь. Это вообще правильная идея: для всех компьютеров в локалке, с которыми общаемся, прописывать статически MAC, а пакеты от остальных банить по MAC-адресу.

Наконец, на тему защиты серверов пишут целые книжки, рассматривая разные угрозы и методы защиты от них. Пример: «простой сервер» FH находился полностью в виртуалке, доступ к нему был только через Tor, админ на него тоже, скорей всего, ходил только через Tor, но, как мы знаем, ничего из перечисленного не спасло FH от взлома. И мы даже не знаем, каким образом он был взломан: используя уязвимости в ПО или методом отслеживанием местоположения с последующим подключением к нему с правами хостинг-провайдера.


Не бывает в мире гарантированной защиты точно так же, как не бывает идеально безопасного софта. Да и вообще, граница между понятиями «баг/уязвимость» и «фича» очень размыты. Часто уязвимости — это по сути часть самой корявой архитектуры или протокола, поэтому не зря говорят, что чем система проще, тем безопасней.
— gegel (29/09/2013 09:57)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
Топикастер сообщил одну важную деталь, которая отличает данный случай от большинства других: сервер будет установлен самим админом непосредственно на компьютере, впоследствии физически защищенным от злоумышленников. Это в корне меняет концепцию и радикально отличается, например, от случая FH, где сервер расположен на хостинге (предполагаем – злонамеренном/подконтрольным врагу) и должен обслуживать всех желающих (в т.ч. злоумышленников).
Гипотетический противник (АНБ) может атаковать и через локалку, т.к. договориться с провайдером ему не проблема.

По идее, надо бы изначально предполагать, что провайдер тоже злонамеренный и может в своей локалке делать все, чтобы получить доступ к серверу. А отснифить сеть и затем подделать МАС сейчас даже дети умеют. Так что это лишь иллюзия безопасности, и уводит в сторону от реально важных проблем.
чем система проще, тем безопасней
Золотые слова.
— Гость (29/09/2013 10:17)   <#>

Сама по себе это не безопасность, а полезная опция. Может, атаковать будет не сам провайдер, а дополнительный человек с ящиком и своим компьютером. Будет ли у него какой-то стандартый MAC, и если да, то чей — спекулятивный вопрос. Настройка MAC не делает хуже, поэтому не вижу причин не затянуть эту гайку.

Ещё стоит логировать все пакеты, предназначенные машине, средствами файерволла и время от времени читать лог. Пусть это и не IDS, но хотя бы что-то информативное.
На страницу: 1, 2 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3