Отключение аутентификации Nginx для заданных ip-диапазонов

Удобный инструмент для защиты разного рода тестовых/разработческих сайтов — аутентификация на уровне веб-сервера по паролю. Она закрывает сайты от ненамеренного индексирования поисковиками и от входа третьих лиц. В Nginx такая делается директивой auth_basic, которая дополняется файлом с пользователями и паролями. Кто-то из разработчиков заходит со статических адресов, поэтому в им аутентификация не нужна и её можно отключить. Делается это следующим образом:

satisfy  any;
allow XX.XX.XX.XX/ZZ;
allow YY.YY.YY.YY/WW;
allow ...
deny   all;

auth_basic            "restricted area";
auth_basic_user_file  htpasswd/example.com;

Таким образом пользователи со статических адресов могут заходить на сайт без ввода паролей. Таким же образом можно открыть сайт для интернет-тестеров разных возможностей сайта, в частности оптимизации (google pagespeed, gtmetrix), безопасности и т.п.

Отключение телеметрии в Windows 10

Наконец-то нашёл хорошую и вменяемую утилиту для отключения телеметрии, шпионства и сбора данных в Windows 10. Работает также в версиях 7 и 8.x и поддерживается автором. Из решающего задачу приватности в windows аналогичного софта, эта утилита одна из лучших.

Удаляем в postfix лишние заголовки

Postfix — отличное типовое решение для корпоративного почтового сервера. Относительно легко ставится, хорошо интегрируется, доступно много всяких фич … что ещё нужно?

Безопасность. Если не конфигурировать явно, то postfix пропускает все заголовки, добавленные до него. Это могут быть:

  1. IP-адрес пользователя во внутренней сети, если он посылает сообщение с помощью клиента. Тогда в полученном письме увидим что-то вроде:

    Received: from [192.168.0.116] (broadband-xxx-xxx-xxx-xx.example.com [xxx.xxx.xxx.xxx])
    by srv.example.com (Postfix) with ESMTPSA id 7AE4D122165
    for ; Sun, 8 Jan 2017 19:13:57 +0000 (UTC)

    Таким образом раскрывается внутренняя структура сети, а если есть ещё и внутренний релей и он добавляет свои заголовки — то и он тоже попадает в заголовки. Ясно дело, что это нежелательно.
    Хорошее решение: срезать все заголовки Received из письма на конечном отправляющем сервере.
    Отдельно замечу, что некоторые из публичных почтовых сервисов тоже светят адрес отославшего письмо, что не всегда хорошо для его безопасности. Вообще, это отдельная тема, что лучше выбрать.

  2. Сообщения, раскрывающию внутреннюю стуктуру почтовика, если в связки используются антивирус/антиспам и подобные решения. Тогда появляется localhost:

    Received: from localhost (localhost [127.0.0.1])
    by srv.example.com (Postfix) with ESMTP id 6466E12216D
    for ; Sun, 8 Jan 2017 19:47:46 +0000 (UTC)

  3. Полезной информации это не несёт, а значит лучше это и не дописывать в каждое сообщение.

  4. User-Agent (почтовый клиент) пользователя:

    User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101
    Thunderbird/45.6.0

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

    User-Agent: Roundcube Webmail/1.2.3

    и сразу открывается ещё одна потенциально опасная точка входа.

  5. Разного рода автоматически добавляемые скриптами заголовки, например

    Received: by srv.example.com (Postfix, from userid 33)
    id 51C4212216F; Sun, 8 Jan 2017 20:07:31 +0000 (UTC)
    X-PHP-Originating-Script: 0:rcube.php

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

  6. Другие заголовки, которые я здесь не перечислил, но такие точно есть.

Далее →

Ссылки для теста https

Сайты с поддержкой протокола https становятся все более и более популярны. Ниже короткий список наиболее полезных ресурсов для проверки корректности работы SSL/TLS и проверки безопасности.

  1. Наиболее полезный тест безопасности есть на сайте SSL Labs. Проверяет поддерживаемые протоколы, обмен ключей и многое другое. Если что не так, сразу видно и можно пофиксить.

  2. Ещё один очень информативный тест от High-Tech Bridge https://www.htbridge.com/ssl/
    Также здесь можно протестировать SSL на почтовых протоколах POP/IMAP/SMTP.

  3. Проверить цепочки сертификатов можно
    https://www.sslchecker.com/sslchecker
    https://www.geocerts.com/ssl_checker
    https://www.sslshopper.com/ssl-checker.html
    Из них первый проверяет цепочку полностью, но на деле корневой сертификат не всегда нужно явно указывать в настройках сервера.

  4. Тест безопасности от Симантек. У них же есть и более широкая подборка утилит.

  5. Ещё полезные тесты:
    https://www.wormly.com/test_ssl
    https://www.digicert.com/help/
    https://sslanalyzer.comodoca.com/

  6. Также проверка клиента, особенно если подключение идёт со старых машин
    https://www.howsmyssl.com/

Странности nginx ssl

Параметры SSL в конфигурации nginx могут быть описаны как в глобальной http-секции, так и в настройках локальных серверов server. В контексте server по логике настройки должны применяться только на этот сервер.

Интересно, что поддержка TLS v1.2 включается только если её включить в server-секциях всех виртуальных хостов, а не только нужного.

Парольная безопасность

Всем информационным безопасникам известны стандартные схемы повышения парольной безопасности. В частности, к таковым относятся:

  • Обязательная смена паролей по истечении определённого срока,
  • Автогенерация «бессмысленного» пароля с хорошим разнообразием символов и длиной, но который проблематично запомнить.

Эти новшества в последнее время вводят начиная от панелей хостинга, заканчивая интернет-банками. Я вижу всего два варианта, почему их вводят: чисто для бюрократии — что у нас есть парольный аудит и мы блюдём безопасность (с пониманием, что такая мера плохо работает) и когда инициатор действительно верит в то, что этим самым делает продукт безопаснее. Последнее в корне неверно.

А дело в том, что не будет пользователь, какой бы квалифицированный он не был, каждые 3 месяца получать «белибердовый» 12-значный пароль и запоминать его. А тётя Маша-бухгалтер и тем более не будет этого делать. Будут обходные пути и саботаж: пароль запишут на бумажку или ещё хуже — в файлик на компьютере. Причем, «тётя Маша» сделает это очевидным способом на самое видное место — рабочий стол, и ещё подпишет куда это вводить надо…

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

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

Господа безопасники, если читаете это: применяйте схемы разумно. Давайте выбирать пароль пользователю самому, проверку на сложность и длину сделать — элементарная программисткая задача. Срок действия пароля тоже должен быть разумый. И обучайте пользователей: один долгий пароль в памяти намного лучше десятка сменных, но на бумажке или в файлике.

Вырезание заголовков в exim4

exim4 — отличный почтовый сервер для исходящей почты. По умолчанию он сохраняет заголовки полностью и добавляет ещё свои. В большинстве случаев эти заголвки делают письмо излишне информативным для получателя и этого желательно избежать.

Первое, что стоит сделать в типовой конфигурации сервера — скрыть внутреннюю структуру сети в отправляемых сообщениях, поскольку exim оставляет в заголовках оригинального отправителя. В типичном случае получатель увидит примерно следующее:

Received: from srv12 ([10.0.0.12])
	by mymail.example.com with esmtp (Exim 4.84)
	(envelope-from )
	id 1cPEo3-0003N7-Jj
	for user@example.com; Thu, 05 Jan 2013 20:38:39 +0000

или следующее

x-originating-ip: [10.54.14.36]

Как видим, почтовый сервер раскрывает адрес отправителя. Этим отправителем может быть сервер во внутренней сети или обычный пользователь с почтовым клиентом. В любом случае эта информация излишняя для получателя: адрес и имя самого почтового сервера в заголовках вполне достаточно. Почистить историю до почтовика можно срезав заголовки Received на этапе получаения почтовиком письма.

Если письмо генерируется автоматически, некоторые интерпретаторы по умолчанию добавляют информацию о себе и о запускаемом скрипте. В частности, этим отличается PHP:

X-PHP-Originating-Script: 0:myscript.php

Поэтому, также вырезаем заголовок X-PHP-Originating-Script.

Если же почтовый сервер обслуживает офис, то из заголовков можно узнать используемый почтовый клиент. Например,

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0)
 Gecko/20100101 Thunderbird/45.5.1

или

X-Mailer: Microsoft Outlook 14.0

Обычно, эта информация вполне безопасна. Информацию о клиенте оставляют многие публичные почтовые сервисы. Однако, её тоже не всегда имеет смысл раскрывать. Особенно, если это веб-клиент или внутренняя CRM. Таким образом, можно ещё срезать заголовок User-Agent.

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

system_filter = /etc/exim4/filter

А в самом /etc/exim4/filter прописать вырезаемые заголовки. Например:

headers remove X-PHP-Originating-Script
headers remove Received

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

Типовая настройка DMARC

Что есть DMARC

DMARC это очередной механизм защиты от спама и от несанкционированной рассылки почты с домена. Этот механизм используется для:

  • Информирования почтового сервера получателя о наличии записей DKIM, SPF и их использовании. Частично эта же задача решается ADSP и самим SPF, однако DMARC позволяет охватить оба;
  • Рекомендации почтовому серверу получателя об обработке почты с невалидными DKIM и SPF;
  • Получения обратной связи от серверов получаетелей в формате RFC 5969 и RFC 5070, которые позволяют, в частности, узнать о несанкционированной рассылке с домена.

Как работает DMARC

В DNS-зоне домена создается TXT-запись _dmarc, в которой прописываются его параметры. При доставке почты с домена получающий почтовый сервер использует значения параметров этой записи для обработки полученного письма. Типичный пример записи строится следующим образом:

$ORIGIN example.com.
_dmarc     IN    TXT "tag_0=value_0;tag_1=value_1;...tag_N=value_N"

Текст состоит из пар «переменная=значение» с разделителем «;».

Основные параметры DMARC-записи

Параметров DMARC много и все их можно найти в официальной конфигурации. Ниже наиболее важные.

  • v=, версия. Этот параметр обязательный и должен быть первым со значением DMARC1.
  • p=, policy. Обязательный параметр, который должен быть на втором месте. Рекомендуемые действия MTA получателя для невалидной почты. Возможные значения: none — нет рекомендации почтовику; quarantine — предлагает считать получающему MTA почту с невалидными SPF и DKIM подозрительной и проводить дополнительные проверки; reject — рекомендует отклонять любую почту с невалидными SPF/DKIM.
  • sp=, policy для субдоменов. Опциональный параметр и имеет те же значения, что и p.
  • adkim=, опциональный параметр, в значении s (strict) требует совпадения домена в параметре d= DKIM и отправителя. В r (relaxed, по умолчанию) разрешает использование субдоменов. То есть, почта с user@sub.example.com будет валидной при adkim=r и невалидной при adkim=s.
  • aspf=, опциональный параметр, со значениями s (strict) и r (relaxed, по умолчанию) для SPF, требующий совпадения ответа команды MAIL FROM и заголовка From письма. r разрешает субдомены.
  • pct=, опциональный параметр, доля обрабатываемых DMARC писем. По умолчанию 100 (100 %), и может быть снижена для отладочных целей.
  • fo=, fail policy, опциональный с значением по умолчанию fo=0. В значении 0, отсылает обратный отчёт если все проверки невалидны (DKIM, SPF); в значении 1 — если какая-либо из проверок не валидна. Также возможны значения s и d, соответственно для отчетов по DKIM и SPF.
  • ri=, опциональный, время между отчетами. По умолчанию сутки, т.е. 86400 секунд.
  • rua=, опциональный, список почтовых адресов через запятую, на которые высылать агрегированные отчеты. Если адрес находится в том же домене, работает без дополнительных настроек.
  • ruf=, опциональный, список почтовых адресов через запятую, на которые высылать fail-отчеты (о невалидной почте). Если адрес находится в том же домене, работает без дополнительных настроек.

Типовые конфигурации записей DMARC

С домена отправляется почта, мягкий вариант

Мягкий вариант DMARC-записи не указывает какой-либо явной политики (policy) принимающему почтовому агенту (MTA), что делать с нелегитимной почтой. Принимающий почтовый сервер действует в соответствии со своими настройками и обычно такая почта достигает ящика отправителя. Пример записи, с получением обоих типов отчетов (aggregated & fail):

_dmarc   TXT "v=DMARC1;p=none;fo=1;rua=mailto:admin@example.com;ruf=mailto:admin@example.com"

Этот вариант годится, когда почта потенциально может отправляться с серверов, не прописанных в SPF, или, если допускается отправка неподписанной DKIM почты.

С домена отправляется почта, строгий вариант

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

_dmarc   TXT "v=DMARC1;p=reject;sp=reject;pct=100;aspf=r;fo=1;rua=mailto:admin@example.com;ruf=mailto:admin@example.com"

С домена не отправляется почта вообще

На домене чаще не бывает почты, чем бывает. Такие «беспочтовые» домены лучше сразу настроить, чтобы сторонние сервисы воспринимали почту с них как спам. Ниже пример DMARC-записи в DNS, запрещающей отсылку почты с домена.

_dmarc   TXT "v=DMARC1; p=reject; sp=reject; pct=100; aspf=s"

Естественно, SPF-запись тоже должна быть настроена, в наиболее коротком виде:

@        TXT "v=spf1 -all"

Дополнительно

Полную документацию по DMARC можно получить на их официальном сайте и RFC.
Проверить DMARC-запись вашего домена можно, например, с помощью этого сервиса.

О правильном мониторинге

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

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

Минимум настроек apache2 и nginx веб-серверов для повышения безопасности

Рассмотрим типовую схему веб-сервера: nginx используется в качестве фронтэнда (front-end), apache2 — бэкэнда (back-end). Установка пакетов из репозитариев дает стандартную конфигурацию, которая применима для сервера разработки и тестирования. Однако, стоковая конфигурация изначально подстроена под большой класс задач и требует доработки. В частности, в плане безопасности. Опишем минимум настроек, которые необходимо сделать, если настраиваемый сервер выходит в интернет для широкого использования.

apache2

Отключаем потенциально опасные и просто неиспользуемые модули, а также неиспользуемые подконфиги. Почти всегда можно (и нужно) отключить:

  • модуль autoindex, позволяющий просматривать содержимое директории при отсутствии индексного файла,
  • обработку cgi-bin, которая в deb-based системах лежит в конфиге serve-cgi-bin.conf и используется очень редко,
  • Другие неиспользуемые модули (список которых зависит от выкладываемого кода). Т.е. необходимо перешерстить директории mods-enabled, conf-enabled

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

Apache/2.4.10 (Debian) Server at ...

Этот параметр, как и некоторые другие настройки безопасности в debian-системах обычно находится в конфиге /etc/apache2/conf-available/security.conf. Переключаем в менее информативную и, соответственно, более безопасную версию:

#ServerTokens Minimal
#ServerTokens OS
#ServerTokens Full
ServerTokens Prod

Аналогичным образом стоит поступить с подписью сервера на «ошибочных» страницах

ServerSignature Off
#ServerSignature On

и трассировкой

TraceEnable Off

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

Код некоторых выкладываемых сайтов может содержать скрытые файлы, вроде .gitignore, .svn и других, раскрывающих стуктуру кода. Их желательно отключить здесь же, в апаче, или в фронт-энде. Можно отключить сразу все скрытые файлы:

<DirectoryMatch "/\.">
	Require all denied
</DirectoryMatch>

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

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

Отключим доступ к скрытым файлам — в секции виртуалхоста добавляем:

RedirectMatch 404 /\..*$

Такие файлы нередко встречаются в проектах. В частности, системы контроля версий вроде git, svn. Эта метаинформация не должна попадать в прошакш, тем не менее следует превентивно защититься от такой возможности.

Если VirtualHost на сервере не один, то также не плохо будет раскомментировать секцию


   AllowOverride None
   Order Deny,Allow
   Deny from all

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


	AllowOverride All
	Order Deny,Allow
	Allow from all

Я не описываю настройку прав доступа (пользователь:группа) на уровне ОС и файловой системы и использование модуля mpm_itk с директивой AssignUserID. Это тоже должно быть сделано для серверов, на которых такое разделение требуется.

nginx

Отключим отображение скрытых файлов:

location ~ /\. {
	deny all;
}

nginx используется как frontend, и если на нем отдается контент по https, то повышаем его безопасность. Для начала отключаем SSLv3 и другие небезопасные протоколы. Если nginx свежий, то в нем это уже и так отключено, поэтому лучше просто обновиться.
Генерируем параметры обмена ключами Diffie-Hellman (которые могут генерироваться достаточно долго, запаситесь временем)

openssl dhparam -out /etc/nginx/ssl/dhparam.pem 4096

и затем подключаем их в энжинксе

ssl_dhparam /etc/nginx/ssl/dhparam.pem;

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

ssl_ciphers 'AES256+EECDH:AES256+EDH:!aNULL';

Также имеет смысл включить кеширование

ssl_session_cache shared:SSL:10m;

После всех настроек желательно проверить их корректность в каком-нибудь сервисе, например, этом.

PHP

Как и в случае апача скрываем версию

expose_php = Off

В зависимости от задач можно отключить вывод ошибок:

error_reporting = 0
display_errors = Off

 

Проверки

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

HEAD example.com

Также побродим по сайту, в том числе по страницам, которые генерируют 4xx и 5xx ошибки, проверим, что версии софта не раскрываются и тем более не раскрывается внутренняя структура сервиса.

Завершающие замечания

Если на сервере хостится несколько сайтов, то многие из приведённых выше настроек повышают безопасность лишь частично. Сделать хорошую защиту между виртуалхостами на одной машине принципиально будет достаточно сложно. Если такое требуется — лучше смотреть в сторону виртуализации уровня операционной системы, по образцу OpenVZ или lxc.

Со временем пост будет пополняться.

Хорошие курсы по криптографии

Почти все MOOC при всех их преимуществах грешат одним недостатком — низкий уровень (что напрямую следует из требуемой для рекламы университетов популярности). Тем не менее, на курсере встречаются и действительно хорошие курсы. Например, по шифрованию:
Cryptography I
Cryptography II

Нельзя сказать, что это курсы продвинутого уровня, однако, они понятным языком покрывают обширные и весьма непростые разделы криптографии. Симметричное, несимметричное шифрование, хеши, MAC, HMAC, алгоритмы обмена ключами (Diffie-Hellman), введение в TLS/IPSec и многое другое. Причем, не только фактологически, но с объяснением внутренних связей, причин-следствий. Совмещение теории с практикой в хорошем смысле.
В общем, кто занимается Computer Security, Computer Science эти курсы будут полезны.

Защита от DDoS при помощи geoip

Основная задача любой оптимизации состоит в минимизации частоты исполнения медленного кода. Применительно к администрированию web-серверов, медленно генерируемые страницы должны запрашиваться нечасто, или такие страницы необходимо сделать быстро генерируемыми. Для многих «простых» сайтов на известных CMS и обвешанными плагинами любая страница генерируется с использованием значительных ресурсов. Это играет злую шутку на большой мусорной нагрузке, например при умном, но узким DDoS: даже такой сможет обвалить сайт.
В случае, если DDoS идёт из определённых стран, например из Китая и Индии (что происходит в большинстве случаев), то появляется быстрое и эффективное решение для защиты региональных сайтов — фильтр входящих запросов по географии и ответ только на запросы с нужных стран. Тогда, «вредные» запросы не доходят до backend, медленный код не исполняется и ресурсы серверы не тратятся, в результате чего сервер для локальных запросов сервер не падает и обычно даже работает с незаметным замедлением.

Делается это правилом вроде

$IPTABLES -A HTTP -m geoip ! --src-cc RU -j DROP

Перед этим правилом определяется стандартным образом цепочка HTTP (-p tcp --dport 80).

Способ, естественно, не годится на случай широких DDoS, нацеленных на заполнение канала (особенно udp-траффиком). Но для слабых, основанных на генерировании нагрузки, DDoS, он вполне годится.

PS: Естественно geiop модули к iptables должны быть поставлены заранее. Тогда этот способ будет действительно быстрым.

Ограниченный SFTP-доступ на сервер

Часто возникает задача дать доступ на сервер в определенную директорию по протоколу sftp, чтобы при этом не было доступа в весь корень файловой системы. Т.е. используя технику chroot. Делается это следующим образом.

Сначала создается пользователь в системе. Обычно по sftp заходят для правки контента и группа пользователя назначается общей для этого рода пользователей (например, www-data). Всё это делается опциями к adduser или useradd.

Далее в /etc/ssh/sshd_config созданному пользователю newuser добавляется кусок конфига, который определяет параметры входа и chroot:

Match User newuser
	ChrootDirectory %h
	ForceCommand internal-sftp
	AllowTcpForwarding no
	X11Forwarding no

После изменения конфига, естественно, нужно рестартануть sshd.

На этом все не заканчивается. Вот что гласит мануал sshd_config:

ChrootDirectory
Specifies the pathname of a directory to chroot(2) to after authentication. All components of the pathname must be root-owned directories that are not writable by any other user or group. After the chroot, sshd(8) changes the working directory to the user’s home directory.

Из соображений безопасности, чтобы работал chroot, директория пользователя должна быть от пользователя root (при этом группа может быть не рутовой). Выполняем это требование, voila и всё работает.

Также для безопасности обычно имеет смысл отключить шелл пользователя

	usermod newuser -s /bin/false

PS: Это все применимо именно для sftp. К сожалению, для scp это не работает и при попытке подключиться по ssh/scp произойдет ошибка.

Уязвимость SSLv3 POODLE

В протоколе SSLv3 обнаружена уязвимость, поэтому все сервисы, завязанные на него следует переконфигурировать. А если точнее, отключить SSLv3 вообще. Ниже кратко как это делается.

nginx

В энжинксе явно разрешаем только хорошие протоколы

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

apache2

В апаче и ниже — запрещаем.

SSLProtocol all -SSLv3 -SSLv2

dovecot

ssl_protocols = !SSLv3 !SSLv2

postfix

smtpd_tls_mandatory_protocols=!SSLv2, !SSLv3

Тесты SSL уязвимости

Здесь можно проверить на уязвимость свои серверы, а здесь — браузер.
Другие параметры SSL можно проверить с помощью этого теста, кроме этого легко гуглится ещё много подобных сервисов.

Дополнительно

Естественно, все демоны после изменения конфигов релодятся или рестартятся.

PS: Разработчики nginx отключили SSLv3 в конфигах. На новых версиях этого делать уже не требуется.

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

Бородатый анекдот:

Два геолога в тайге встречают медведя. Ружья нет. Один геолог бросается бежать, а второй кричит ему вслед:
— Бесполезно, ты всё равно не сможешь бежать быстрее медведя!
— А мне не нужно бежать быстрее медведя. Мне всего лишь достаточно бежать быстрее тебя!

 

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

Основы безопасности сайта

В последнее время распространена проблема автоматизированного взлома сайтов на известных CMS. Целью взлома обычно является: рассылка с сайта спама и размещение ссылок на внешние ресурсы. Несмотря на то, что проблема обычна вызвана уязвимостями в самой CMS, она может быть решена в общем виде.

Для решения как минимум нужно обеспечить условия:

  1. Исполняемый код должен быть защищен от записи от пользователя веб-сервера. Наиболее очевидный вариант как это сделать: назначить ему owner:group другого пользователя, от которого и работать с кодом на запись, а веб-серверу оставить права только на чтение.
  2. Запретить исполнение кода во всех директориях разрешенных на запись от веб-сервера (контент, кеш и подобные).
  3. Забыть про ftp и не сохранять пароли в файловых менеджерах. Взамен пользоваться scp/sftp, желательно с авторизацей по ключу.
  4. Для разных virtual hosts использовать разных системных пользователей, которые не читают данные друг друга.

Первый пункт из вышеприведенных гарантирует сохранность кода, даже в движке с дырами или бэкдором. Второй затрудняет исполнение залитых файлов: их можно исполнить с помощью include(), но для этого в read-only коде должна быть такая возможность (которая по сути является бэкдором).

Кроме этого, желательно:

  • Ограничить доступ в административные части сайта по IP-адресам на уровне веб-сервера только с рабочих компьютеров. Способ помогает даже при компрометации паролей, а также при человеческих конфликтах.
  • Использовать SSL-соединения (с префиксом https://) для входа в административные части и везде, где используется пароль для входа. Это защитит от компрометации паролей и данных по каналам связи, например при работе по незащищённому вайфаю.
  • Если точек входа на сайт небольшое количество, разрешить использовать только их, остальное запретить.

Проверка rar в amavis на почтовом сервере

Оказывается, стандартный unrar-free не распаковывает многоуровневые вложенные rar-архивы. Для того, чтобы такие архивы распаковывались и их содержимое проверялось необходимо включить «несвободную» unrar-библиотеку. Если конкретно, то изменить в конфиге amavis стоковую конфигурацию (которая находится в /etc/amavis/conf.d/01-debian:

#$unrar = ['rar', 'unrar']; #disabled (non-free, no security support)
$unrar = ['unrar-free'];

на свою:

$unrar = ['rar', 'unrar']; #disabled (non-free, no security support)
#$unrar = ['unrar-free'];

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

UPDATE:
Если закомментировать обе строки, то будет использоваться архиватор 7zip (который заранее, естественно, установить надо). Также его можно указать вручную. Это похоже наилучшее решение.

Безопасность Skype

Так уж повелось, что я не доверяю Skype и некоторым новомодным браузерам: рассматриваю их как разновидность неопасных троянских коней. Может, конечно, они плохого ничего и не делают, но свои данные я им открывать не хочу. Для огораживания подобных подозрительных приложений отлично подходит runas от другого непривелигерованного пользователя. Например:

%windir%\system32\runas.exe /profile /user:another_user "C:\Program Files\Skype\Phone\Skype.exe"

После этого софт не имеет возможности прочитать данные пользователя. Windows уже давно имеет этот функционал, жаль что мало кто им пользуется. Тоже самое применимо к браузерам, особенно поделкам от поисковиков. И не только в качестве защиты от самого браузера, но также и запуска в нем чего-нибудь левого.