Защита простого сервера на windows 7 или XP
Привет всем. Хотел бы решить вот такую задачу. Работает у меня windows ноутбук. Интернет по adsl модему он же роутер. Для работы на нём подключаюсь к нему по rdp с андроид планшета.
На нем работает клиент получающий реалтайм данные, пусть будут к примеру температура воздуха и интенсивность солнечного света.
Обработанные данные способны повлиять на ход геополитических процессов в мире:), откуда можно оценить степень параноидальности.
Можно ли обеспечить гарантированную защиту без учёта физического доступа к ноутбуку?
Linux с wine опробованы, с моей win прогой не справились. Благодарю.
комментариев: 5 документов: 1 редакций: 0
Дальше возникает вопрос утечки данных через дешифровку перехваченного трафика. И вот тут всплывает, а на базе какого генератора случайных чисел работает это шифрование? В виндах они все уязвимые и запрещены к использованию в криптографических целях даже при работе с данными уровня "сыкрэтно", не говоря уже о "гостайна" :)
Потому и придется заворачивать rdp-трафик в дополнительный туннель, средствами сродни openssh или openvpn. Это проще, чем переделывать rdp-сервер.
комментариев: 5 документов: 1 редакций: 0
Под двухсторонней авторизацией я понимаю сторонний сервис, который мне например пришлёт sms с кодом подтверждения. Или что то ещё?
комментариев: 393 документов: 4 редакций: 0
Если это утверждение в силе, то можно сделать реализацию намного проще и надежнее.
При установке ПО на ноутбук выбираете и сохраняете AES-ключ, которым будет шифроваться ответ, и ключ аутентификации для HMAC. Запрос содержит timestamp в качестве nonce для ответа. На ноутбуке поднимаете udp-сервер, отвечающий только если в поле timestamp значение строго больше такого в последнем запросе. Запрос аутентифицируете HMAC. Для шифрования ответа используете CTR. Аутентифицируете ответ с помощью HMAC.
Возможные пути атак:
– на ПО роутера и далее на Windows;
– переполнение буфера в вашем сервере (надо везде перепроверять при разработке ПО сервера).
... Kerberos?
комментариев: 5 документов: 1 редакций: 0
gegel думаю круто, но не мой уровень познаний и практики
вроде opensource, значит пригодный? надо про него углубится, что там за третья сторона
они всеж динамические сейчас
MAC в открытом виде идёт?
Да, opensource, но подумайте, нужно ли это в вашем случае. Вроде Kerberos — сервер аутентификации, который аутентифицирует одну сторону перед другой, сам при этом являясь третьей стороной.
Тогда разве что port knocking или целиком перейти на инфраструктуру скрытых сервисов Tor, но это может быть совершенно неоправданным переусложнением для вашего случая.
Да, но виден только в локальной сети. Его статическое прописывание есть некоторая мера против ARP spoofing'а в локалках. Плюс, к тому же, ядро в логах обычно ругается на попытки ARP spoofing'а, что есть плюс для аудита.
комментариев: 393 документов: 4 редакций: 0
Представьте себе пусковую установку ядерных ракет, к которой прикрутили rdp и завернули в openvpn для надежности: наверное, для совместимости, чтобы пускать можно было с ноута под Win32, андроидного планшета и в крайнем случае, айфона :)
Не стоит искать себе приключений. Используйте статические ключи с обеих сторон, стандартное шифрование и аутентификацию: никаких особых знаний для этого не надо, и в итоге написание такого приложения умещается в пару десятков строчек кода и несравненно проще, чем прикручивать все вышеописанное.
Если уж так хочется использовать готовое, то, мне кажется, достаточно использовать одну openvpn со статическими ключами, а на роутере оставить открытым один UDP-порт для нее и запретив все остальные. Для надежности можно добавить каскадом еще один роутер от другого производителя, желательно с открытым ПО (типа Микротика).
А разве РоутерОС (то ПО, что на Микротиках) не проприетарное решение, пускай и на базе Линуксов?
Некоторые крэкнутые версии РоутерОС
идутшли одно время с откровенными бэкдорами. На рутрекере был топик соответствующий.Топикстартер нам не сообщил никаких деталей, но сказал абстрактное «хочу, чтобы всё было и от всех было защищено». Гипотетический противник (АНБ) может атаковать и через локалку, т.к. договориться с провайдером ему не проблема. Вот тут статический MAC может помочь. Это вообще правильная идея: для всех компьютеров в локалке, с которыми общаемся, прописывать статически MAC, а пакеты от остальных банить по MAC-адресу.
Наконец, на тему защиты серверов пишут целые книжки, рассматривая разные угрозы и методы защиты от них. Пример: «простой сервер» FH находился полностью в виртуалке, доступ к нему был только через Tor, админ на него тоже, скорей всего, ходил только через Tor, но, как мы знаем, ничего из перечисленного не спасло FH от взлома. И мы даже не знаем, каким образом он был взломан: используя уязвимости в ПО или методом отслеживанием местоположения с последующим подключением к нему с правами хостинг-провайдера.
Не бывает в мире гарантированной защиты точно так же, как не бывает идеально безопасного софта. Да и вообще, граница между понятиями «баг/уязвимость» и «фича» очень размыты. Часто уязвимости — это по сути часть самой корявой архитектуры или протокола, поэтому не зря говорят, что чем система проще, тем безопасней.
комментариев: 393 документов: 4 редакций: 0
По идее, надо бы изначально предполагать, что провайдер тоже злонамеренный и может в своей локалке делать все, чтобы получить доступ к серверу. А отснифить сеть и затем подделать МАС сейчас даже дети умеют. Так что это лишь иллюзия безопасности, и уводит в сторону от реально важных проблем.
Золотые слова.
Сама по себе это не безопасность, а полезная опция. Может, атаковать будет не сам провайдер, а дополнительный человек с ящиком и своим компьютером. Будет ли у него какой-то стандартый MAC, и если да, то чей — спекулятивный вопрос. Настройка MAC не делает хуже, поэтому не вижу причин не затянуть эту гайку.
Ещё стоит логировать все пакеты, предназначенные машине, средствами файерволла и время от времени читать лог. Пусть это и не IDS, но хотя бы что-то информативное.