Компьютерная безопасность, коды, доступы и т.д.
Как сделать неуязвимый сайт?
Создана: 18 Марта 2010 Чтв 16:46:14.
Раздел: "Компьютерная безопасность, коды, доступы и т.д."
Сообщений в теме: 16, просмотров: 5520
-
18 Марта 2010 Чтв 16:46:14Если хочется сделать сайт, надёжно защищенный от всякого рода наездов со стороны властей или каких-то иных злопыхателей, то вполне достаточно применить дешевую и эффективную схему, о которой я и хочу рассказать. Как раз эта схема в данный момент используется на Омском Форуме.
Смысл этой схемы в том, чтобы спрятать реальный, мощный сервер (или несколько серверов) своего ресурса, за двумя слоями дешевых арендованных промежуточных серверов.
Для посетителя из интернета виден только внешний слой (L3) - это могут быть дешевые VDS, какие-то Shared-хостинги, либо вообще какие-то компьютеры пользователей, которые дополнительно нагружены функцией внешнего слоя.
Идеально подходит для организации внешнего слоя NGINX - собственно говоря, эта штука как раз и предназначена для организации внешнего слоя (правда, официально - не для обеспечения секретности, а для распределения нагрузки).
Следующий слой (L2) - как раз и является буфером, обеспечивающим безопасность. Это могут быть, например, VDS арендованные где-то за рубежом - это если требуется обеспечить высокую степень защиты. Для того чтобы узнать местонахождение серверов L2 злоумышленнику потребуется сначала вскрыть защиту слоя L3 - в награду он получит IP-адрес сервер L2. На этом моменте весьма желательно отследить факт вскрытия безопасности и уничтожить "засвеченный" сервер L2, заменив его на другой. Множество готовых L2 серверов могут быть заранее настроены и "спать" в ожидании своего часа. Всё зависит от степени надёжности и безопасности, который требуется обеспечить. Если у злоумышленника скорее всего не получится получить доступ к серверам L2 (например. если они находятся в надёжном месте или где-то за рубежом), то можно и не рубить "засвеченные" сервера уровня L2. Если же наоборот, требуется максимальная надёжность но при этом нет надёжных "точек опоры", тогда на уровне L2 можно построить несколько дополнительных уровней безопасности, несколько раз перебросив соединения из одного дата-центра в другой. Тогда для вскрытия уровня L2 злоумышленнику придется пройти по всей цепочке и получить доступ к каждому промежуточному серверу.
И, наконец, самый секретный слой - L1, на котором находятся реальные сервера ресурса. Чтобы вычислить их местонахождение потребуется прежде вскрыть уровень L2.
Чтобы обеспечить надежность серверов на уровне L1 надо настроить один или несколько зеркальных серверов, на которые будет постоянно сбрасываться информация об изменениях, но никакие сервера L2 не должны указывать на эти зеркальные сервера.
Таким образом, если злоумышленнику удастся вскрыть уровень L2 и захватить сервер уровня L1 то в этот момент должна сработать защита, которая заблокирует все данные на сервере и злоумышленнику достанется лишь фарш из многих гигабайт данных, которые он может расшифровывать в течение нескольких лет.
Существуют готовые решения (например, www.truecrypt.org), которые позволяют сделать так, чтобы при включении сервер требовал пароль, без которого расшифровать данные на дисках невозможно. Поэтому, достаточно либо рубануть питание сервера, либо просто инициировать какой-то сбой, и злоумышленник гарантированно лишится доступа к данным на сервере.
На Омском Форуме, конечно, не требуется супер-безопасности, у нас нет ничего криминального, нет каких-то коммерческих данных, которые могли бы кого-то сильно заинтересовать. Тем не менее эта несложная схема реализована и работает. Все сервера, которые доступны по адресам [внешняя ссылка] и [внешняя ссылка] и другие - это сервера уровня L3, на которых нет никакой информации. От них идёт зашифрованный канал на L2 сервер, на котором к тому же система закрыта на TrueCrypt. А уже оттуда - канал на главный сервер L1. А если мы реализуем зеркальный L1, то система будет не только безопасной от "кавалерийских набегов", но и значительно более устойчивой. -
-
18 Марта 2010 Чтв 17:03:10уровнем L3 (или даже L4) может быть роутер на базе DD-WRT ?
Если так то можно было бы еще более "распределить нагрузку" по пользователям ОФ. Готов участвовать. -
18 Марта 2010 Чтв 17:24:35Нгинкс - это не только реверс прокси, но и самый быстрый сервер для отдачи файлов, работающий в режиме пользователя. Несколько уровней доступа, по-моему, замедляют работу: на кадом уровне необходимо полностью принять и распарсить заголовки http. Гораздо приятнее, если: 1) трехуровневая архитектура: база данных, сервис доступа к данным, интерфейс пользователя, 2) первые 2 отделены от третьего, 3) соединение инициирует не интерфейс пользователя к сервису доступа к данным, а наоборот, естесственно по ssl.
-
18 Марта 2010 Чтв 17:28:43MAXXX писал
:уровнем L3 (или даже L4) может быть роутер на базе DD-WRT ?
Именно L4.
Потому что L3 позволяет осуществить подмену IP-адресов.
Для создания слоя L4 необходимо либо:
-на уровне всего проекта переработать механизм авторизации юзеров. Добавить учёт цепочки IP-адресов, через которые юзер пришел на сервер. Адреса уровня L4 при этом считать наименее достоверными, и в основном опираться на адреса L3.
-либо вообще не доверять IP-адресам, сообщаемым с уровня L4 и считать всех юзеров, авторизующихся на такой точке, имеющими один IP-адрес. В этом случае возможна только подмена сессий в рамках юзеров, работающих через одну и ту же точку L4.
Теоретически, можно сделать специальную мини-версию nginx для её интеграции в прошивку точки. Можно даже подкинуть идею Сысоеву, я думаю, ничего сложного в этом нет. Это откроет возможность для реализации супер-распределённых и практически неуязвимых проектов.
MAXXX писал :Если так то можно было бы еще более "распределить нагрузку" по пользователям ОФ. Готов участвовать.
на данном этапе нам не требуется такой уровень распределённости. Он интересен теоретически, либо может пригодиться для реализации каких-то иных проектов. Или если вдруг в стране начнутся репрессии, "глобальные фаерволы" и прочая фигня, то можно будет при помощи такой технологии преодолеть все эти ограничения. -
18 Марта 2010 Чтв 17:33:20Если использовать эту схему на коммерческих проектах, то в этой схеме нехватает защиты от DDOS-атаки, хоть и серверов уровня L3 будет куча, но все же они остаются публично всем известны, а ресурсов на них мало и заддосить их будет несложно.
и вся система рухнет )). -
18 Марта 2010 Чтв 17:40:16GENA_DJ писал : Нгинкс - это не только реверс прокси, но и самый быстрый сервер для отдачи файлов
Ещё бы придумать как это использовать !
Если реализовать алгоритм "обратной закачки файлов", когда файлы, закачанные на "главный сервер" автоматом "всплывают" на сервера L3, то было бы очень здорово, это бы значительно увеличило быстродействие. Не вижу ничего нереального в таком алгоритме, может быть есть и готовые решения, только я их не знаю
GENA_DJ писал
:Несколько уровней доступа, по-моему, замедляют работу: на каждом уровне необходимо полностью принять и распарсить заголовки http.
Не совсем так. Между уровнем L2 и L1 осуществляется соединение не по протоколу http, а по протоколу обмена с базой данных. Этот переход в любом случае существует, так что тут никаких потерь нет.
Что же касается взаимодействия уровней L3-L2, то там однозначно лучше делать общение с юзером через nginx и потом переходить на другой сервер со скриптами, даже если это всё в одном датацентре.
GENA_DJ писал :Гораздо приятнее, если: 1) трехуровневая архитектура: база данных, сервис доступа к данным, интерфейс пользователя
А так оно и выходит - L1 это база данных, L2 - это сервис доступа к данным, L3 - это интерфейс пользователя.
GENA_DJ писал :соединение инициирует не интерфейс пользователя к сервису доступа к данным, а наоборот
я пока не осознал, в чём тут смысл и какой выигрыш от этого -
18 Марта 2010 Чтв 17:51:52boss_lexa писал :нехватает защиты от DDOS-атаки, хоть и серверов уровня L3 будет куча, но все же они остаются публично всем известны, а ресурсов на них мало и заддосить их будет несложно.
Наоборот, такая система способна совершенно защитить от DDOS-атак.
Необходимо реализовать алгоритм по следующему принципу:
1) каждый новый IP-адрес, пытающийся установить соединение с ресурсом, подвергается анализу и некоторое время находится под присмотром. Самая радикальная и пуленепробиваемая схема - это на уровне L3 потребовать ввести цифры с картинки. Если юзер проходит этот тест, то после этого айпишнику даётся доступ.
Менее радикальные схемы - подсчитывать запросы с каждого IP-адреса и в случае признаков участия в DDOS-атаке вносить этот адрес в блэк.
2) важно, что адреса блокируются на уровне L3. Причём надо апдейтить блэк-лист DDOS-ящих айпишников на все сервера L3. Таким образом DDOS будет фильтроваться на уровне L3 и не будет оказывать вообще никакого влияния на работоспособность системы в целом.
3) если DDOS-атака очень мощная, то для её отражения вышеописанным алгоритмом потребуется просто очень много L3-серверов. Думаю, тысяча (+/-) серверов L3 надёжно отразят DDOS любого уровня, то есть такая система будет просто не замечать никакого DDOSа, даже если несколько сотен тысяч айпишников будет долбиться со всего мира каждую секунду. Главное распределить L3-сервера по множеству различных дата-центров. -
18 Марта 2010 Чтв 17:59:13AlexAdmin, а что насчет моего вопроса выше:
Каким образом отследить факт вскрытия безопасности? -
18 Марта 2010 Чтв 18:16:28
Вопрос сложный - если знать как устроена система отслеживания надёжности безопасности, то это всё равно что этой системы нет, потому что сразу становится ясно как её обойти. Такая система должна быть чем-то вроде ноу-хау для каждой конкретной реализации.
Хотя с другой стороны, я вот сейчас подумал, что никакая система отслеживания не будет неэффективна при количестве серверов L3 больше 3-5 штук. Потому что выдумывать отдельную систему для каждого L3 будет хлопотно, а если делать всё по единому шаблону, то достаточно вскрыть один L3 чтобы понять систему и выяснить как её аккуратно обойти.
Поэтому если необходимо обеспечить действительно гарантированную неуязвимость серьёзного проекта, необходимо осуществлять ротацию серверов L2 не по факту вскрытия L3, а просто по времени. Скажем, каждый сервер L2 живёт не более 2-3 дней и потом ему приходит таймаут. Можно даже вообще программировать эти сервера на самоуничтожения после некоторого кол-ва часов работы. -
18 Марта 2010 Чтв 18:33:42А что, если злоумышленник является гос.органом типа интерпола, фбр и т.д
и ему готовы оказать содействие хостинг-провайдеры всех трех уровней.
Например если бы я был сотрудник ФБР:
1. Договариваюсь с провайдером уровня L3, мониторю трафик на предмет на какой IP адрес больше всего соединений. так узнаю сервер L2.
2. На L2 поступаю аналогично.
3. Узнаю местанахождение реального главного сервера, выдвигаюсь на место...
При все этом, провайдеры не разглашают эти действия клиенту и администрация проекта ничего об этом не знает.
Что дальше? Можно ли вытащить данные с сервера с работающей системой крипто-графической защиты (truecrypt.org) , при этом не нарушая его работу? -
18 Марта 2010 Чтв 19:23:58boss_lexa писал :А что, если злоумышленник является гос.органом типа интерпола, фбр и т.д и ему готовы оказать содействие хостинг-провайдеры всех трех уровней.
В этом случае в некоторой степени поможет вынесение слоя L2 в некую недружественную страну. Тогда проблема автоматически выходит на межгосударственный уровень и договариваться спецслужбам будет гораааздо сложнее.
Если же проблема реально решаться на международном уровне, то тогда конечно у ресурса шансов на выживание значительно меньше.
boss_lexa писал :Например если бы я был сотрудник ФБР:
1. Договариваюсь с провайдером уровня L3, мониторю трафик на предмет на какой IP адрес больше всего соединений. так узнаю сервер L2.
Да, реально. Ты вскрываешь L3, узнаёшь L2.
Далее твоя задача - попасть на сервер L2. Он находится, допустим, в США или Канаде. В общем, в какой-то совсем другой стране, и желательно не дружественной по отношению к той стране, в которй L3.
boss_lexa писал :2. На L2 поступаю аналогично.
Вот тут загвоздка. Тебе понадобится на международном уровне получить разрешение на следственные действия по серверу L2. При этом, напомню, сервер L2 умрёт по таймауту через 1-2 дня, и к тому времени как ты получишь разрешение, оно потеряет смысл.
Хотя есть надежда, что тебе помогут оставшиеся логи провайдера L2. Однако, и здесь можно создать проблемы для следствия.
Можно установить не одно соединение с сервером L1, а допустим двадцать соединений с серверами-пустышками. Просто создать в нескольких направлениях шифрованные OpenVPN каналы и прогонять по ним бессмысленный трафик, и только в одном направлении трафик будет реальным. Ни снифером, ни по логам не отличишь реальные направления от фиктивных. Соответственно, придётся отрабатывать все 10 (или сколько ты сделаешь) направлений, 9 из которых приведут "в никуда", и только одно - реально укажет на L1.
И ещё один простой момент (о котором я говорил в самом начале) - можно соединения между L2 и L1 устанавливать не напрямую, а, например, прогнать через несколько промежуточных роутеров в разных дата-центрах. В этом случае я не завидую тем, кто захочет выйти на L1 через всю эту катавасию.
boss_lexa писал :Можно ли вытащить данные с сервера с работающей системой крипто-графической защиты (truecrypt.org) , при этом не нарушая его работу?
Думаю, это крайне проблематично. Если сервер стоит и работает, пароли на него не известны, то зайти не получится (а попытки входа можно зафиксировать и уложить систему). Можно стоять рядом с сервером и смотреть на него. Начнёшь трогать - уже нет гарантии что не отреагируют датчики. В любом промышленном сервере есть датчики вскрытия, а если сильно надо - можно и свои собственные изобрести и прикрутить. Каналы между L1 и прочими направлениями, разумеется, зашифрованные, снифером ничего не добьёшься.
Единственное полезное что можно от этого поиметь - это получить снифером информацию о всех направлениях, в которых подключается этот сервер, и таким образом попытаться найти во-первых, организаторов ресурса, во-вторых, возможные зеркальные сервера.
Лучше всего чтобы на уровне L1 была бы "красная кнопка", при помощи которой хозяин дата-центра информировал бы о приходе гостей. Поэтому если бы я был на месте ФБР, то даже бы не пытался физически проникнуть к серверу, а все наблюдения вёл бы со стороны провайдера. Но здесь уже требуется чтобы сотрудники спецслужбы были бы достаточно умными, чтобы это всё понимать и не "натыкаться на сигнализацию", а не вбегали бы в масках вырывать провода... -
03 Апреля 2010 Суб 20:54:17
1. Спрятать сервис за firewall или за NAT, вероятно, в другой стране.
2. Замаскировать трафик под HTTP(S).
3. Сервис сам управляет размером пула на основании собственной загрузки.
4. Соединения создаются заранее и автоматически, меньше задержка для клиента. -
03 Апреля 2010 Суб 23:21:57Для мониторинга безопасности вполне сойдет Nagios и ему подобные системы.
На внешнем уровне L3 можно развернуть honeypots и ip-адреса тех, кто в них попадается заносить в blacklist. -
04 Апреля 2010 Вск 0:12:03млин, из-за этих экскекриментов с внешней базой сегодня днём 50% переходов по страницам были холостые, либо проблема коннекта с базой пишет, либо тупо старая обновляется, я уж молчу про глюки с авторизацией, "бегушкой", стилем и проблемами при переходах в большие многостраничные темы. Кстати, как-бы сделать чтобы юзверь мог настраивать кол-во постов на странице у себя в профиле? Лично для меня крайне полезная функция, думаю для других пользователей тоже :)
