безопасность

warning: Creating default object from empty value in /usr/local/www/drupal6/modules/taxonomy/taxonomy.pages.inc on line 33.

Учусь пользоваться OpenVPN

Начал разбираться, чем и как лучше поднимать шифрованные тунели. Один из вариантов OpenVPN.

На вскидку плюсы и минусы:

Плюсы:

  • по описаниям, надежное шифрование
  • использование одного порта для работы или UDP или TCP, может работать через прокси сервер
  • автоматически поддерживает соединение, т.е. не надо контролировать обрывы связи
  • позволяет управлять роутингом клиентов
  • разные механизмы авторизации: логин/пароль, ключи, сертификаты X.509
  • кросплатформенность
  • открытость
  • возможность поиграться в PKI
  • возможность как P2P (маршрутизируемого) соединения, так и моста (при необходимости прокинуть не IP трафик или прохождения широковещательных пакетов)

Минусы:

  • Отдельный продукт, который необходимо устанавливать, а не работает "искаропки", что требует определенных привилегий
  • Не совсем привычная настройка
  • не получилось повесить один сервер на разные порты (возможно, руки кривые)

По сертификатам X.509

Создаем/получаем корневой доверенный сертификат, с помощью которого, подписываем сертификаты клиентов и серверов.

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

Клиент и сервер определяются по их личным сертификатам, ключам и именам в сертификате (Common Name).

0
Your rating: Нет

VPN через ssh на FreeBSD

Обычно объединял сети через тунели между FreeBSD шлюзы через gif-интерфейсы. Легко, просто, быстро, удобно.

Но захотелось прикрутить к этому шифрование. IPSEC не понравился, т.к. нужно много ставить и настраивать, а тут все компоненты есть в коробке.

Последовательность:

  1. Настраиваем sshd: разрешаем тунелирование и вход от root только по ключу.
  2. Создаем ключи и копируем на сервер.
  3. Настраиваем тунель и автоматизируем процес.

Настраиваем sshd: разрешаем тунелирование и вход от root только по ключу

в /etc/ssh/sshd_config добавляем

# For SSH tunel
PermitTunnel yes
PermitRootLogin without-password
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

Создаем ключи и копируем на сервер

На клиенте создаем ключ и публичный ключ копируем на сервер.

На клиенте

ssh-keygen -t rsa -b 4096
# cat /root/.ssh/id_rsa.pub | ssh user@server "cat - >> ~/.ssh/authorized_keys"

На сервере помещаем ключ нужному пользователю:

cat authorized_keys >> /root/.ssh/authorized_keys

После этого на клиенте запускаем

ssh -w5:5 -f -CT -o ServerAliveInterval=10 root@server "ifconfig tun5 10.0.1.1 10.0.1.2" && ifconfig tun5 10.0.1.2 10.0.1.1

Прописываем роутинги и далее, все должно быть хорошо.

0
Your rating: Нет

Внедрение цифровой подписи и шифрования для организации

Черновик.

Потребовалось начать использовать шифрование в организации, начал искать, через что это можно сделать.

Сначала смотрел в сторону GnuPG, но не смог разобраться, как внедрить ее в почтовые клиенты от Microsoft.

В итоге наковырял, что для шифрования и подписи писем есть S/MIME с сертификатами X.509.

И итоге для использования необходимо на компьютер под виндой установить:

  1. GnuGP - для создания запросов на сертификат и возможности шифрования и подписи файлов
  2. OpenSSL - для того, чтобы GnuGP шифровал файлы с помощью сертификатов X.509.

Сначала разбираемся с тем, кто будет удостоверяющим центром и как он будет подписывать сертификаты.

Удостоверяющим центром являюсь я, и обработка запросов сертификатов у меня под FreeBSD.

Создаем структуру под OpenSSL и самоподписанный корневой сертификат:

#Создаем структуру для хранения сертификатов
mkdir newcerts
mkdir private
echo 10000 > serial
touch index.txt

# Создаем самоподписанный корневой сертификат
openssl req -new -x509 -newkey rsa:3072 -keyout private/cakey.pem -out cacert.pem -days 3650
# Конвертируем в понятный для Windows сертификат
openssl x509 -outform der -in cacert.pem -out cacertificate.crt
# Просматриваем, что у нас получилось
openssl x509 -text -in cacert.pem
 

После этого через Kleopatra создаем для пользователя запрос на сертификат X.509 и передаем его на сервер. После чего на сервере создаем сертификат:

0
Your rating: Нет

Резервыне копии данных в FreeBSD через snapshot

Черновик

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

Фо FreeBSD, и наверное не только, есть такое понятие как моментальная копия файловой системы, или snapshot.

При этом, чисто теоретически, должно неплохо экономиться место.

Из первых неудобств - делается некоторое время (60 гб делалось около 20 минут) и снять процесс создания снепшота нельзя. Возникает ощущение, что процес завис и больше счастья не будет. Ощущение обманчивое.

То же самое возникло при попытке удалить снепшот - т.е. создание и удаление снепшотов больших разделов достаточно длительный процесс.

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

Удобная утилита:

cd /usr/ports/sysutils/freebsd-snapshot
make install clean

По материаллам - snapshot UFS2 во FreeBSD.

При наличии ZFS снэпшоты можно делать так:

zfs snapshot -r system64@`date "+%Y-%m-%d-%H:%M"`

0
Your rating: Нет

Создание одноразового зашифрованного контейнера под FreeBSD

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

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

#Единожды, подготовка устройства/файла
dd if=/dev/zero of=test_img bs=1m count=100

#Каждый раз, при необходимости подключить шифрованное хранилище
mdconfig -a -t vnode -f test_img -S 4096 -u 5
geli onetime -l 256 -s 4096 /dev/md5
newfs /dev/md5.eli
mount /dev/md5.eli /mnt/

Ну и при необходимости размонтируем:

umount /dev/md5.eli
geli detach /dev/md5
mdconfig -d -u 5

После размонтрирования или перезагрузки системы данные востановить уже невозможно.

0
Your rating: Нет

Создание шифрованного раздела на работающем сервере FreeBSD с дополнительными возможностями

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

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

Итого для создание нужно выполнить следующие шаги:

  • создать файл контейнер необходимого размера
  • подключить его как устройство, иначе geli с ним работать не будет
  • зашифровать устройство
  • создаем на нем файловую систему ZFS

#Создаем файл контейнер
dd if=/dev/zero of=test_img bs=1m count=100

#Создаем ключевой файл
dd if=/dev/random of=test_img.key bs=64 count=1

#Подключаем контейнер как устройство
mdconfig -a -t vnode -f test_img -S 4096 -u 5

#Инициилизируем шифрованное устройство
geli init -s 4096 -K test_img.key /dev/md5

#Подключаем зашифрованное устройство
geli attach -k test_img.key /dev/md5

#Создаем на шифрованном устройстве файловую систему ZFS
zpool create -m /backup backup /dev/md5.eli

Полностью отключаем всю нашу конструкцию

zpool export backup
geli detach /dev/md5
mdconfig -d -u 5

0
Your rating: Нет

zfs - файловая система с кучей возможностей

Пока черновик.

Захотел собрать себе из старого железа собрать сервер для резервного хранения данных.

Основная проблема старого железа - неизвестно когда загнется, но скорее всего скоро. wink

Тут возник вопрос, как сделать чтобы при этом сохранность информации была на должном уровне и при этом можно было достаточно легко заменять и добавлять диск. Умный Stinky рассказал мне волшебное слово - ZFS. ZFS - файловая система, которая на ходу позволяет в нее добалять и удалять диски, готова сама создавать из них разные рейды, поддерживает квоты для разделов, сжатие и кучу разных вкусностей.

Из смешного, под Linux ее вроде потихоньку переносят, а под FreeBSD - уже перенесли и она штатно готова к работе.

Идея использования этой системы и старых винтов.

Ситуация с дисками:

  • диски старые - могут выйти из строя в любой момент, обязательно требуется дублирование - рейд 1 или 5 (mirror или raidz)
  • диски разного размера - стандартный рейд не проходит, т.к. тогда на каждом диске будет использоваться объем равный самому маленькому диску

Мое решение (пока в процессе размышления):

Чтобы наша ZFS система автоматически монтировалась rc.conf нужно добавить:

zfs_enable="YES"

0
Your rating: Нет

Придумалась идея файл-бэкап сервера

Давно уже мучает вопрос, как и куда бэкапить свои данные с минимальными издержками и максимальным результатом.

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

Какие вижу плюсы:

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

Минусы - точно есть, но на вскидку не придумал...

Какие??

0
Your rating: Нет

Отчеты по баннерной сети в системе БаннерБанк

Очень интересовало, насколько БаннерБанк живая система. Немного поиграл в те баннерные сети, которые казались интересными, ничего особого не нашел, но была надежда, что просто не в те сети у них играю.

Хотелось посмотреть отчет по всем баннерным сетям этой системы, но БаннерБанк на прямую таких отчетов не предоставляет.

Сегодня, просматривая отчет внешним ссылкам по своему сайту на Яндекс.Вебмастер, нашел ссылку ко мне с сайта БаннерБанка. Как оказалось, она ведет с отчета по сети «Home Banner Network».

График количества ежедневных публикаций на сайтах сети «Home Banner Network».

График количества ежедневных публикаций на сайтах сети «Home Banner Network»

Покрутив адресную строку и список баннерных сетей, в которых можно создать аккаунт, стало понятно, как получить доступ к статистике по нужной сети.

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

К сожалению, нельзя посмотреть общую табличку по всем сетям сразу, а нужно ручками смотреть каждую...

0
Your rating: Нет
Ленты новостей