Форум русскоязычного сообщества Ubuntu


За новостями русскоязычного сообщества и Ubuntu в целом можно следить на нашей страничке в Google+

Автор Тема: Предотвратить чтение iptables при физическом доступе к компьютеру.  (Прочитано 3055 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Оффлайн dim-mik

  • Автор темы
  • Участник
  • *
  • Сообщений: 104
    • Просмотр профиля
Предотвратить чтение 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 не знает никто, кроме меня.
Достаточно ли шифрования домашней папки?
« Последнее редактирование: 26 Ноябрь 2011, 18:00:53 от dim-mik »

Оффлайн censor

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

Оффлайн dim-mik

  • Автор темы
  • Участник
  • *
  • Сообщений: 104
    • Просмотр профиля
На Ubuntu Server один пользователь, пароль знаю только я.
Но ведь можно получить доступ непосредственно к жесткому диску.
Исключить несанкционированный доступ пользователей к серверу я могу.
Я не могу исключить возможность несанкционированного доступа к серверу проверяющих органов.
И будет очень нехорошо если они узнают где фактически находятся вся информация предприятия.
« Последнее редактирование: 28 Ноябрь 2011, 08:43:19 от dim-mik »

Оффлайн fisher74

  • Заслуженный пользователь
  • Старожил
  • *
  • Сообщений: 13746
    • Просмотр профиля
Не нарушайте закон и не нужно будет прятать информацию предприятия от проверяющих органов.
А там работают. поверьте, серьёзные специалисты (не те которые по по конторам ходят, а особые отделы) и Ваши потуги скорее всего только усугубят ситуацию.
Принимаю благодарности в WMR и WMZ на кошельки:
R158160676909 и Z313280060764

Оффлайн astrobeglec

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

Оффлайн dim-mik

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

Оффлайн xkool

  • Старожил
  • *
  • Сообщений: 1460
  • do not love my brain
    • Просмотр профиля
Варианты развития событий при различных раскладах я отлично представляю. Мне их рассказывать не надо, спасибо.
Вопрос только один:
как максимально усложнить чтение файла /home/dima/iptables при несанкционированном физическом доступе к компьютеру с Ubuntu Server?
Ограничить физический доступ к серверу,закрой его в сейф.
Лучше маленький доллар, чем большое спасибо.

Оффлайн saymon21root

  • Участник
  • *
  • Сообщений: 166
    • Просмотр профиля
    • https://saymon21-root.pro
владелец рут, chmod 600 и стоит начать изучать pam.
Логировать все попытки входа, + уведомления админа в жаббер или мыло
« Последнее редактирование: 28 Ноябрь 2011, 13:58:38 от denis32 »

Оффлайн astrobeglec

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

Оффлайн dim-mik

  • Автор темы
  • Участник
  • *
  • Сообщений: 104
    • Просмотр профиля
Наверное не правильно объяснил ситуацию.
Главные опасения вызывает, что компьютер с Ubuntu Server просто выключат и заберут.
И уже у себя будут компьютер (либо жесткий диск непосредственно) насиловать.
Возможности зайти под каким-либо пользователем и что-либо стереть не будет.
Необходимо защитить файл от чтения на уровне файловой системы,
чтоб без логина и пароля пользователя Ubuntu нельзя было прочитать.
Например на файловой системе NTFS есть Encrypting File System (EFS).
Почему я и задавал вопрос: достаточно ли шифрования домашней папки?
« Последнее редактирование: 28 Ноябрь 2011, 15:53:41 от dim-mik »

Оффлайн astrobeglec

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

Оффлайн Alie Alexandross

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

P.S. На ачате предлагали ещё забить весь раздел /dev/urandom, чтоб скрыть начало шифруемого контента.
« Последнее редактирование: 28 Ноябрь 2011, 16:34:25 от Alie Alexandross »
Подпись автора jillsmitt истинна...

Оффлайн dim-mik

  • Автор темы
  • Участник
  • *
  • Сообщений: 104
    • Просмотр профиля
Спасибо. Буду экспериментировать.

Оффлайн Lion-Simba

  • Старожил
  • *
  • Сообщений: 1126
    • Просмотр профиля
Если файл будет зашифрован - он в таком виде будет бесполезен не только для "злоумышленника", но и для самой системы.

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

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

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

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

И да, я согласен с fisher74.
Оказываю индивидуальную платную техподдержку широкого профиля. Обращаться в ЛС или Jabber.

Оффлайн dim-mik

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

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

 

Страница сгенерирована за 0.062 секунд. Запросов: 24.