Предотвратить чтение iptables при физическом доступе к компьютеру.

[dim-mik]

Предотвратить чтение iptables при несанкционированном физическом доступе к компьютеру с Ubuntu Server.

Работаю с несколькими предприятиями по следующей схеме.

В офисе:
Рабочие места - Ubuntu (Lubuntu) Desktop + Rdesktop.
Сервер - Ubuntu Server - интернет шлюз, прокси сервер, проброс портов, адрес 192.168.0.1

В дата-центре:
Терминальные сервера - Windows Server 2003 + 1C + MSOffice …

Пользователи подключаются к удалённому рабочему столу (например 192.168.0.1:3397), а Ubuntu Server пробрасывает данный порт на ip-адрес нужного терминального сервера в дата-центре. У пользователей создаётся впечатление, что они работают на локальном сервере и никто не знает где находится терминальный сервер.

Но на  Ubuntu Server находится файл /home/dima/iptables, в котором прописаны все правила iptables с ip-адресами терминальных серверов в дата-центрах.

Как предотвратить чтение данного файла при  несанкционированном физическом доступе к компьютеру с Ubuntu Server?
Пароль суперпользователя Ubuntu Server не знает никто, кроме меня.
Достаточно ли шифрования домашней папки?

[censor]

iptables-save покажет все правила загружнные в фильтр.
мягко говоря зада бредовая, просто исключите несанкционированный доступ пользователей к серверу.

[dim-mik]

На Ubuntu Server один пользователь, пароль знаю только я.
Но ведь можно получить доступ непосредственно к жесткому диску.
Исключить несанкционированный доступ пользователей к серверу я могу.
Я не могу исключить возможность несанкционированного доступа к серверу проверяющих органов.
И будет очень нехорошо если они узнают где фактически находятся вся информация предприятия.

[fisher74]

Не нарушайте закон и не нужно будет прятать информацию предприятия от проверяющих органов.
А там работают. поверьте, серьёзные специалисты (не те которые по по конторам ходят, а особые отделы) и Ваши потуги скорее всего только усугубят ситуацию.

[astrobeglec]

Топикстартеру - если контролирующий орган захочет (действительно захочет), то сломает сначала Вас (они это делать умеют, причем в отличии от дешевых фильмов не бьют, а просто дают выбор - или сам или их сисадмин, а Вы ближайшие лет 15-20 отправитись админить нары на Колыме, причем выбор и срок за несогласие вполне реален), а потом Вы сами сломаете любую установленную Вами защиту на сервер. Чисто технически имея физический доступ к серверу толковый системщик вытащит все правила iptables т.к. у каждой ОС есть возможность восстановления данных при забыто пароле.
Кстати в отличии от периода 5-7 лет назад для контроля сегодня привлекают профи, а не лохов как раньше.

[dim-mik]

Варианты развития событий при различных раскладах я отлично представляю. Мне их рассказывать не надо, спасибо.
Вопрос только один:
как максимально усложнить чтение файла /home/dima/iptables при несанкционированном физическом доступе к компьютеру с Ubuntu Server?

[xkool]

Варианты развития событий при различных раскладах я отлично представляю. Мне их рассказывать не надо, спасибо.
Вопрос только один:
как максимально усложнить чтение файла /home/dima/iptables при несанкционированном физическом доступе к компьютеру с Ubuntu Server?

Ограничить физический доступ к серверу,закрой его в сейф.

[saymon21root]

владелец рут, chmod 600 и стоит начать изучать pam.
Логировать все попытки входа, + уведомления админа в жаббер или мыло

[astrobeglec]

Ну, раз последствия известны...
Самый надежный но не простой выход это:
Создаешь пользователя Vasya (ну или кто тебе больше нравится) - это твоя бомба. logout при каждом отходе от компьютера.
При проверке заходишь под Васей, при этом обнуляешь правила iptables и гробишь файлик. Резервную копию прячешь поглубже в систему через sudo cp

[dim-mik]

Наверное не правильно объяснил ситуацию.
Главные опасения вызывает, что компьютер с Ubuntu Server просто выключат и заберут.
И уже у себя будут компьютер (либо жесткий диск непосредственно) насиловать.
Возможности зайти под каким-либо пользователем и что-либо стереть не будет.
Необходимо защитить файл от чтения на уровне файловой системы,
чтоб без логина и пароля пользователя Ubuntu нельзя было прочитать.
Например на файловой системе NTFS есть Encrypting File System (EFS).
Почему я и задавал вопрос: достаточно ли шифрования домашней папки?

[astrobeglec]

Наверное не правильно объяснил ситуацию.
Главные опасения вызывает, что компьютер с Ubuntu Server просто выключат и заберут.
И уже у себя будут компьютер (либо жесткий диск непосредственно) насиловать.
Возможности зайти под каким-либо пользователем и что-либо стереть не будет.
Необходимо защитить файл от чтения на уровне файловой системы,
чтоб без логина и пароля пользователя Ubuntu нельзя было прочитать.
Например на файловой системе NTFS есть Encrypting File System (EFS).
Почему я и задавал вопрос: достаточно ли шифрования домашней папки?

В целом достаточно, пароль только знаков в 20 поставь

[Alie Alexandross]

Вам только шифрование данных поможет. chmod, PAM и GRUB пароль обходятся банальной загрузкой с liveCD или с другой системы linux с последующим монтированием раздела с искомой информацией. Пароль на BIOS сбрасывается с батарейкой. Всякие "спрячешь поглубже" находятся через find и grep.
Читайте dm-crypt.

P.S. На ачате предлагали ещё забить весь раздел /dev/urandom, чтоб скрыть начало шифруемого контента.

[dim-mik]

Спасибо. Буду экспериментировать.

[Lion-Simba]

Если файл будет зашифрован - он в таком виде будет бесполезен не только для "злоумышленника", но и для самой системы.

Стало быть, система при загрузке должна расшифровывать этот файл с целью активации правил, в нём прописанных.

И здесь есть два варианта:

1) Ключ шифрования хранится где-то в самой системе. В этом варианте система сможет корректно загрузиться и применить правила без участия пользователя. Однако, раз ключ физически расположен в этой же системе, он может стать доступным "злоумышленнику" при получении контроля над жестким диском.

2) Ключ хранится "где-то ещё" (в голове пользователя, на флешке, в интернете). В этом случае доступ к шифрованным файлам при завладении жестким диском исключен. Но и загрузка сервера без участия того же пользователя оказывается невозможной. Вместо ключа "где-то ещё" можно хранить и сам файл с правилами - степень безопасности от такой процедуры может только повыситься. Скажем, затягивать файл с правилами с какого-нибудь файлохостинга. В момент Ч файл на файлохостинге подменяется на поддельный и не представляющий интереса.

И да, я согласен с fisher74.

[dim-mik]

Вполне логично. Спасибо.
Компьютер перезагружается редко.
После загрузки:
1. Скачал файл с ftp.
2. Запустил iptable-restore \"имя файла".
3. Файл удалил.

А восстановить удаленный файл всякими там утилитами возможно?