Личная вики в моей домашней сети - как мне это защитить?

Question

Я бы хотел посвятить низкоэнергетическую коробку Debian/Ubuntu для настройки на ней личной вики (а именно Instiki). Информация, которую я ищу в ней, очевидно, будет носить очень конфиденциальный характер; любой, кроме меня, получит к нему доступ, будет катастрофой. И мои навыки сетевого администрирования и безопасности довольно слабые. Высокие требования, низкие навыки; не очень хорошая комбинация

Я знаю, что по своей природе настройка приложения для прослушивания и открытие порта для внешнего мира подвергает меня определенному уровню опасности. Но как мне минимизировать эту опасность?

• Насколько я понимаю, пока он работает за моим маршрутизатором, который имеет встроенный межсетевой экран, он по умолчанию недоступен для внешнего мира; правильный?
• И если я явно открою порт для компьютера (настроив запись "Виртуальный сервер" в конфигурации моего маршрутизатора), я в основном буду зависеть от силы моего сочетания имени пользователя и пароля, которое теоретически любой сценарий сканирует детишку для открытые порты могут угадать грубой силой.

Есть ли практическая середина между полным отключением внешнего доступа и использованием комбинации порт / имя пользователя / пароль? Я мог бы жить только с доступом к моей вики, когда я дома, но это было бы неудобно.

Какие у меня есть другие варианты? SSH туннелирование? Аутентификация пары ключей? Пожалуйста, порекомендуйте. Мне особенно хотелось бы получить дополнительные советы по настройке туннеля или VPN через SSH.

Answer 1

Вот подход, который я бы выбрал:

Шаг 1 (локальная безопасность)

• прочитайте о Instiki, убедитесь, что вы укрепите веб-сервер, который он использует
• выбирайте хорошие пароли для root, admin и личных учетных записей, храните их в менеджере паролей, а не на бумаге!
• убедитесь, что только пользователи веб-сервера (никакие другие, например, гостевые) не могут читать данные локально [не уверены, как это относится к рельсам]
• научиться шифровать локальные файлы (например, truecrypt)
• узнайте, как делать зашифрованные резервные копии (нет резервной копии => нет данных)

шаг 2 (ограничения доступа)

• сделать сервер доступным только через https (никто не читает ваш трафик в пути)
• разрешить вход в Ubuntu только через ssh [порт 22] или локальную консоль
• для безопасного доступа к вашей домашней сети из диких сетей, загляните в OpenVpn

Answer 2

Я бы делал HTTP-аутентификацию по HTTPS и перенаправлял любой HTTP-трафик в HTTPS. Ограничьте доступ к определенным IP-адресам или сетям, если вам не нужен доступ отовсюду. Вы можете использовать клиентский сертификат HTTPS, но этот сертификат должен быть установлен на любом компьютере, к которому вам нужен доступ. Вы можете использовать какое-то USB-устройство для хранения, но вам нужно убедиться, что оно было удалено после того, как вы закончите. В зависимости от вашей паранойи, вы не сможете доверять ни одному компьютеру, который не находится под вашим контролем, и даже тогда насколько они безопасны?

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

Answer 3

Если я собираюсь управлять автономными браузерами, которые я буду использовать для доступа к ресурсам дома, я использую аутентификацию сертификата клиента X.509 по SSL. Таким образом, даже если у кого-то будут мои имя пользователя и пароль, веб-сервер откажется общаться с ними, потому что у них нет сертификата моего клиента.

Это немного сложнее в настройке, и если вы используете тонкий веб-сервер, встроенный в некоторые из вики-продуктов, это может оказаться невозможным. Я использую nginx в качестве своего веб-сервера, и моя вики (WikkaWiki) работает на php-fastcgi.

Проблема в том, что у вас может быть несколько сайтов, к которым вам нужно получить доступ, и из-за того, как работает SSL, вы не можете иметь несколько виртуальных хостов на одном IP и комбинации портов. Вы можете решить эту проблему, разместив все сайты под одним хостом и иметь подкаталог для каждого (https://my.domain.com/wiki, https://my.domain.com/blog) или использовать отдельные доменные имена и использовать разные порты.

В последнем случае вы можете столкнуться с проблемами отправки трафика из корпоративных сетей на произвольные порты, на которых вы используете SSL (они блокируют весь трафик, кроме известного, пытаясь предотвратить открытие туннелей в их сети с использованием SSH).