Небольшой совет как обезопасить себя при изъятии сервера, гипотетический демон (в терминах unix).
Исходя из того, что где -то в новостях пробегала информация о том, что со скорого времени владельцы ресурсов не будут нести ответственность за размещаемый пользователями контент (и высказывания).
Вкратце — для тех, кому лень читать. Задача сводится к тому, что бы никто без вас не мог скомпроментировать ФС вашего сервера без вас.
1. Как предложение — полагаю, что есть смысл хранить(дублировать) логи системы на удаленном сервере (за рубежом), а также на локальном, но и там и там в зашифрованном виде. Смысл затеи в том, что если владельца сайта будут обвинять в том, что это именно он залил и держит файл, например, с детским порно и сотрудники органов будут указывать на файл, например, лежащий в /opt/some_public_service/childporno.mkv, то в суде, вы сможете показать свои логи, их копию с удаленного сервера и на основании этого доказать, что файл был залит не вами, а появился неизвестным образом во время нахождения сервера «где то за пределами площадки хостера». Технически реализовать это несложно.
Конечно, ваши логи, скорее всего не будут нотариально заверены, но суд их может принять во внимание.
/* следовательно — не вы распространяете ДП, а сотрудники структуры :) */
2. Можно пойти немного дальше и реализовать следующий функционал/демон: При нахождении сервера за пределами площадки хостера, если демон не может пинговать определенный ip, то приложение/демон гасит внешние сервисы, параллельно шифруя их конфигурацию, и удаляя файлы конфигураций из привычных для сервиса/демона мест. Таким образом, вы можете обезопасить себя от того, что на ваш сервер будет залит компроментирующий материал через публичные сервисы.
3. Кроме того, нашему гипотетическому демону: Есть смысл настроить параметры безопасности (например SE Linux) либо зоны(Solaris zones?) таким образом, что при недоступности или наоборот, доступности определенного ресурса — сообщения в твиттере, текстового файла на удаленном сервере или иного подконтрольного вам, но независимого ресурса параметры системы меняются — файловая система RO, либо полный запрет на запись из любого контекста. В общем — можно много чего придумать, главное — разработать механизм и модель безопасности, позволяющие четко определить, что появилось на сервере в момент его контроля вами, а что «самозародилось» потом.
Например, можно ввести оценочные критерии включения read-only контекста для ФС или ее самоуничтожения:
некорректный шатдаун
неполучение keep-alive сообщения из внешнего источника
доступность/недопуступность кодового слова/файла, например remove_all.txt на удаленном ресурсе
3 попытки неверного ввода пароля
нехарактерная картина сети (необычные маршруты, необычные пинги и т.п.)
и т.п.
в любых, настроенных владельцем ресурса комбинациях/критериях.
4. В любом случае, все стирать/самоуничтожать ФС, на мой взгляд не стоит, но стоит оставить возможность включить сервер/получить доступ к ФС только вам и сделать вы сможете это в присутствии адвоката/понятых и тп.
Имейте ввиду, что не совсем разумно уничтожать ФС сервера, т.к. это могут попытаться классифицировать как уничтожение улик.
Исходя из того, что где -то в новостях пробегала информация о том, что со скорого времени владельцы ресурсов не будут нести ответственность за размещаемый пользователями контент (и высказывания).
Вкратце — для тех, кому лень читать. Задача сводится к тому, что бы никто без вас не мог скомпроментировать ФС вашего сервера без вас.
1. Как предложение — полагаю, что есть смысл хранить(дублировать) логи системы на удаленном сервере (за рубежом), а также на локальном, но и там и там в зашифрованном виде. Смысл затеи в том, что если владельца сайта будут обвинять в том, что это именно он залил и держит файл, например, с детским порно и сотрудники органов будут указывать на файл, например, лежащий в /opt/some_public_service/childporno.mkv, то в суде, вы сможете показать свои логи, их копию с удаленного сервера и на основании этого доказать, что файл был залит не вами, а появился неизвестным образом во время нахождения сервера «где то за пределами площадки хостера». Технически реализовать это несложно.
Конечно, ваши логи, скорее всего не будут нотариально заверены, но суд их может принять во внимание.
/* следовательно — не вы распространяете ДП, а сотрудники структуры :) */
2. Можно пойти немного дальше и реализовать следующий функционал/демон: При нахождении сервера за пределами площадки хостера, если демон не может пинговать определенный ip, то приложение/демон гасит внешние сервисы, параллельно шифруя их конфигурацию, и удаляя файлы конфигураций из привычных для сервиса/демона мест. Таким образом, вы можете обезопасить себя от того, что на ваш сервер будет залит компроментирующий материал через публичные сервисы.
3. Кроме того, нашему гипотетическому демону: Есть смысл настроить параметры безопасности (например SE Linux) либо зоны(Solaris zones?) таким образом, что при недоступности или наоборот, доступности определенного ресурса — сообщения в твиттере, текстового файла на удаленном сервере или иного подконтрольного вам, но независимого ресурса параметры системы меняются — файловая система RO, либо полный запрет на запись из любого контекста. В общем — можно много чего придумать, главное — разработать механизм и модель безопасности, позволяющие четко определить, что появилось на сервере в момент его контроля вами, а что «самозародилось» потом.
Например, можно ввести оценочные критерии включения read-only контекста для ФС или ее самоуничтожения:
некорректный шатдаун
неполучение keep-alive сообщения из внешнего источника
доступность/недопуступность кодового слова/файла, например remove_all.txt на удаленном ресурсе
3 попытки неверного ввода пароля
нехарактерная картина сети (необычные маршруты, необычные пинги и т.п.)
и т.п.
в любых, настроенных владельцем ресурса комбинациях/критериях.
4. В любом случае, все стирать/самоуничтожать ФС, на мой взгляд не стоит, но стоит оставить возможность включить сервер/получить доступ к ФС только вам и сделать вы сможете это в присутствии адвоката/понятых и тп.
Имейте ввиду, что не совсем разумно уничтожать ФС сервера, т.к. это могут попытаться классифицировать как уничтожение улик.
