bookmarks-on-tranquilizers

Я труслив :) Во-первых, я делаю бэкапы. Во-вторых, я их боюсь передать без шифрования и, в третьих, иногда и храню их зашифрованными.

Как правильно организовать передачу бэкапов с одного сервера на другой? Дампы этого блога у меня передаются по http. Они зашифрованны, да и особо ценных данных здесь нет, поэтому http меня не смущает. А как поступить с данными по-важнее? Конечно, ssh. А как при этом запретить пользователю выполнять какие-либо действия, кроме как копирования к себе бэкапа? Представим себе, что бэкап-сервер находится во вражеском дата-центре или просто вы не можете проконтролировать к нему доступ (в т.ч. физический). Нас выручит опция command файла authorized_keys.

Например, если необходимо предоставить доступ только к файлу backup.tgz, то в authorized_keys в самом начале соответствующей строки можно дописать следующее “command=’cat backup.tgz’”. Теперь при каждом коннекте будет автоматически выполняться команда cat backup.tgz, вам остается только перенаправить вывод в файл. Если дампов несколько, то можно написать небольшой скриптик вида:#!/bin/sh
read file
case "$file" in
"foo") cat foo.tgz ;;
"bar") cat bar.tgz ;;
esac И прописать его в качестве команды по умолчанию. Да, не лишним было бы добавить опции no-port-forwarding, no-pty и все прочие no-*

Теперь копировать файл с удаленной машины можно вот такой командой:echo "foo" | ssh backup@server > foo-`date +%Y-%m-%d`.tgz

Кроме как для бэкапов, такое же решение может подойти и для мониторинга. Когда нагиос стучится на удаленный сервер, чтобы собрать какую-либо статистику, полный ssh-доступ ему не нужен.

По-моему, все, что я описал примитивно по сложности и вместе с тем весьма надежно. Так может быть прекратим без надобности дописывать authorized_keys на серверах? Одна запись для себя, любимого, одна для бэкапов, одна для мониторинга.. ой, еще каких-то две.. дальше продолжать? :)

Кстати, а есть ли способы более тонко настраивать уровень доступа к ssh?

В некоторые моменты чувствую себя очень неуютно из-за того, что нет возможности посмотреть, что конкретно делают с моим сервером некоторые персоны. Я долго искал возможность логгировать все, в том числе и POST запросы клиентов и нашел способ – через mod_security.

Устанавливается он элементарно apxs -cia mod_security.c (см документацию, правда, для его работы в наиболее удобном, “Concurrent”, режиме логгирования, нужен модуль unique_id. После установи модуля следует добавить следующую секцию в httpd.conf:


ltIfModule mod_security.cgt
SecAuditEngine On
# У mod_security есть два механизма логгирования, Concurrent - более быстрый и продвинутый.
SecAuditLogType Concurrent
# Здесь будет храниться индекс - файл, по структуре похожий на access_log + идентификаторы, по которым можно найти полную информацию в StorageDir
SecAuditLog /var/log/www/audit/index
# Тут хранятся все данные запросов. Каждый запрос в отдельном файле. Запросы разнесены по каталогам (вместе все запросы одной транзакции, вместе все транзакции одного дня)
SecAuditLogStorageDir /var/log/www/audit/data/
# Наиболее полное логгирование (man)
SecAuditLogParts ABCDEFGHZ
# Добавить обработку POST данных.
SecFilterScanPOST On
SecFilterEngine On
# Следующие строки нужны для сохранения загруженных на сервер файлов:
SecUploadDir /var/log/www/audit/upload
SecUploadKeepFiles On
</IfModule>

Включать это имеет смысл при подозрении, что кто-то пытается использовать вашу систему не по назначению, теперь любой шаг проходимца будет записан.

p.s. Работоспособность конфига проверялась в apache 1.3.37, mod_security 1.9.4, но работать должно и в 2.0/2.0

Сегодня обнаружил, что текстовое поле в конце файла id_rsa.pub – просто комментарий. Это значит, что после копирования его на удаленный хост в authorized_keys можно заменить свой настоящий логин и имя хоста на строку “тут был Вася” и никто никогда не поймет, кто такой Вася и как он сюда попал.
И еще. Можно работать на удаленном хосте, не светясь ни в auth.log, ни в `who` ни в `last`, без возможности посмотреть, что творится в консоли через watch – для этого достаточно запускать ssh-сессию так: ssh user@host “bash”.

Мораль здесь одна: если у человека есть ssh аккаунт на машине, то контроллировать его действия практически невозможно.