Мониторинг SSL сертификатов в Zabbix
Надеюсь, многие со мной согласятся в том, что поддержка web-сайтом работы по защищённому протоколу HTTPS является отраслевым стандартом. Аналогичная тенденция наблюдается и с почтовыми серверами.
В связи с этим в последнее время большую популярность приобрёл сервис Let’s Encrypt, предоставляющий бесплатные SSL/TLS сертификаты всем желающим. Особенностью данного сервиса является довольно ограниченный срок действия выдаваемого сертификата — 90 дней.
И хотя существуют известные способы автоматизации процесса перевыпуска сертификатов от Let’s Encrypt, не лишним будет поставить данный вопрос на контроль. Контролировать будем посредством популярной системы мониторинга Zabbix.
Существует как минимум два подхода к SSL сертификатам: внешний, то есть через интернет, и внутренний — со стороны сервера. Первый способ становится единственным, когда нет доступа к операционной системе сервера, но в этом случае, как правило, нет и возможности настроить автообновление сертификатов.
Кроме того, если на одном сервере необходимо контролировать несколько сертификатов, то в Zabbix их придётся настраивать каждый в отдельности, что не очень удобно. В данной статье мы пойдём вторым путём: установим Zabbix-агента на сервер, и настроим проверку сертификатов через файловую систему.
Итак, приступим.
Установку и настройку ACME-клиента Let’s Encrypt я оставлю за рамками статьи. Приведу лишь ссылку на рекомендуемого данным сервисом клиента: Certbot.
Настройка Zabbix-агента
Подключаемся (через ssh) к серверу, который будем мониторить, и переходим в каталог с конфигурационными файлами Zabbix-агента (у меня это /etc/zabbix/). Если агент у вас до сих пор не установлен, то сделайте это сейчас, например, так:
sudo apt-get install zabbix-agent
В дальнейшем нам понадобятся калькулятор командной строки bc и потоковый редактор текста sed, поэтому устанавливаем их:
sudo apt-get install bc sed
Создадим папку scripts, в которой разместим два скрипта. Первый назовём certdiscovery.sh, он будет заниматься поиском установленных на сервере SSL/TLS сертификатов:
#!/bin/bash CERTS_DIR=/etc/letsencrypt/live certs=`ls $CERTS_DIR` if [[ -n ${certs} ]]; then JSON=”{ “data”:[” for CRT in ${certs}; do JSON=${JSON}”{ “{#CERTIFICATE}”:”${CRT}”},” done JSON=${JSON}”]}” echo ${JSON} | sed '$s/,]}$/]}/' fi
Второй скрипт назовём certdate.sh, он будет проверять количество дней, оставшихся до окончания срока действия сертификата:
#!/bin/bash CERTS_DIR=/etc/letsencrypt/live cert=$CERTS_DIR/$1/cert.pem end_date=`openssl x509 -noout -enddate -in $cert | cut -d '=' -f 2` if [ -n “$end_date” ]; then end_date_seconds=`date '+%s' –date “$end_date”` now_seconds=`date '+%s'` echo “($end_date_seconds-$now_seconds)/86400” | bc fi
В этих скриптах проверьте и исправьте, если необходимо, путь к каталогу с вашими сертификатами, указанный в первой строке. Не забудьте сделать эти скрипты исполняемыми:
chmod a+x /etc/zabbix/scripts/{certdiscovery.sh,certdate.sh}
Убедитесь, что zabbix-агент имеет доступ на чтение в каталоги /etc/letsencrypt/live и /etc/letsencrypt/archive (по умолчанию доступ есть только у root). Если доступ запрещён, то в качестве варианта решения проблемы предлагаю добавить пользователя zabbix, автоматически созданного при установке агента, в группу ssl-cert, которой дать право чтения указанных выше каталогов:
usermod -aG ssl-cert zabbix chgrp ssl-cert /etc/letsencrypt/{archive,live} chmod g+rx /etc/letsencrypt/{archive,live}
Можно проверить работу наших скриптов из командной строки. certdiscovery.sh вызывается без параметров и возвращает JSON-структуру, содержащую все найденные подкаталоги с сертификатами, а в certdate.sh нужно передать один параметр — значение любого поля {#CERTIFICATE} из вышеупомянутой JSON-структуры.
Далее переходим в каталог с пользовательскими файлами конфигурации zabbix-агента /etc/zabbix/zabbix_agentd.conf.d/, где создаём файл letsencrypt_certs_check.conf с таким содержимым:
UserParameter=certdiscovery,/etc/zabbix/scripts/certdiscovery.sh UserParameter=certdate[*],/etc/zabbix/scripts/certdate.sh $1
Настройка Zabbix-сервера
Самая трудная часть работы выполнена, осталось импортировать шаблон в сервер Zabbix. В веб-интерфейсе переходим в Configuration->Temlates->Import, и загружаем шаблон Template Letsencrypt Certs.zip, предварительно его разархивировав.
Теперь можно в веб-интерфейсе назначить хосту, для которого мы настраивали мониторинг, шаблон «Template Letsencrypt Certs» и подождать некоторое время, пока начнут поступать данные. По-умолчанию в шаблоне для скрипта автообнаружения установлен интервал обновления 1 час, проверка срока действия SSL сертификатов производится каждые 6 часов.
Засим откланиваюсь. Вопросы, пожелания, комментарии приветствуются.
Источник: https://linuxoid.pro/blog/
Мониторинг срока действия ssl сертификата в zabbix
У меня время от времени возникают ситуации, когда я пропускаю обновление какого-нибудь ssl сертификата.
Особенно часто это стало происходить с повсеместным распространением сертификатов на 3 месяца от letsencrypt. Автоматическое продление иногда не срабатывает по различным причинам.
Чтобы защитить себя от таких ситуаций, решил настроить полноценный мониторинг ssl сертификатов с помощью zabbix.
Содержание:
- 1 Введение
- 2 Проверяем средства для мониторинга
- 3 Настройка zabbix-agent
- 4 Настройка zabbix server для мониторинга ssl сертификатов
- 5 Возможные ошибки
- 6 Заключение
- 7 Дополнительные материалы по Zabbix
Введение
Традиционно, буду использовать самые простые подручные средства, завернутые в консольные скрипты, которые будут передавать значения в zabbix с помощью UserParameter. Для уменьшения ручной работы, добавление доменов в систему мониторинга будет осуществляться с помощью автообнаружения. Сами списки доменов с сертификатами ssl для проверки будут храниться в текстовых файлах.
У нас будут 2 отдельных списка для проверки:
- Домены с ssl сертификатами для веб сайтов.
- Домены с ssl сертификатами для почтовых серверов.
Поясню, почему 2 списка. Ведь по сути, сертификаты в обоих случаях будут совершенно одинаковые. Дело в том, что у меня есть почтовые сервера, которые используют сертификаты, но при этом не имеют сайтов с таким же доменным именем.
Для таких серверов заказаны отдельные сертификаты, которые установлены только на почтовом сервере и проверить их можно только по протоколам, которые используют почтовые серверы. Ниже я подробно раскрою все различия и способы проверки.
Если у вас еще нет готового сервера для мониторинга, предлагаю его настроить по моей статье — установка и настройка zabbix 3.4 на Centos 7. Если предпочитаете Debian, то вот материал на эту тему — установка и настройка zabbix 3.4 на Debian 9. В данном случае все можно сделать на одном сервере — достаточно на один сервер поставить zabbix-server и zabbix-agent.
Проверяем средства для мониторинга
Прежде чем приступим к написанию скриптов для мониторинга, предлагаю отдельно проверить технические средства, которые будем использовать. В данном случае это будет консольная утилита openssl с различными параметрами и преобразованием ее вывода.
Для начала просто запросим сертификат сайта и проверим вывод:
# openssl s_client -connect serveradmin.ru:443 -servername serveradmin.ru -tlsextdebug
Вы должны увидеть служебную информацию по ssl сертификату и сам сертификат. Обращаю внимание на параметр -servername. После него указано имя домена.
У вас может быть ситуация, когда на одном ip хостятся несколько сайтов. Параметр -connect фактически указывает только на ip адрес сайта.
Если не указать отдельно имя домена через -servername, то команда вернет сертификат первого домена.
Теперь посмотрим на срок действия сертификата. Для этого вывод предыдущей команды завернем на нее же, но с другими параметрами. Получится вот так:
# openssl s_client -connect serveradmin.ru:443 -servername serveradmin.ru -tlsextdebug 2>/dev/null | openssl x509 -noout -dates 2>/dev/nullnotBefore=Jul 11 14:55:00 2017 GMT
notAfter=Oct 9 14:55:00 2017 GMT
На выходе должны увидеть дату создания сертификата и дату завершения его действия. Обработаем этот вывод и оставим только последнюю дату без лишних символов.
# openssl s_client -connect serveradmin.ru:443 -servername serveradmin.ru -tlsextdebug 2>/dev/null | openssl x509 -noout -dates 2>/dev/null | grep notAfter | cut -d'=' -f2
Oct 9 14:55:00 2017 GMT
Получаем то, что надо. Именно с этой датой будет работать скрипт для отправки данных в zabbix сервер.
Вот пример похожего запроса, только на smtp сервер:
# openssl s_client -starttls smtp -connect mail.zeroxzed.ru:25 | openssl x509 -noout -dates 2>/dev/null | grep notAfter | cut -d'=' -f2
Перед выводом самой даты, выходят несколько строк со служебной информацией о сертификате. Я долго пытался понять, почему они не обрезаются через grep, но так и не понял. По факту, работе скрипта этот лишний вывод не вредит.
С теорией и подручными средствами разобрались. Переходим к настройке zabbix agent.
Настройка zabbix-agent
Создаем папку для скриптов в директории с настройками zabbix:
# mkdir /etc/zabbix/scripts
Первым делом создадим 2 текстовых файла для хранения списков доменов.
# touch /etc/zabbix/scripts/ssl_https.txt /etc/zabbix/scripts/ssl_smtp.txt
В эти файлы необходимо добавить домены по одному на каждую строку. Дальше добавляем скрипты для автообнаружения этих доменов и передачи в zabbix.
# mcedit /etc/zabbix/scripts/disc_ssl_https.sh#!/bin/bash JSON=$(for i in `cat /etc/zabbix/scripts/ssl_https.txt`; do printf “{“{#DOMAIN_HTTPS}”:”$i”},”; done | sed 's/^(.*).$/1/') printf “{“data”:[” printf “$JSON”
printf “]}”
# mcedit /etc/zabbix/scripts/disc_ssl_smtp.sh#!/bin/bash JSON=$(for i in `cat /etc/zabbix/scripts/ssl_smtp.txt`; do printf “{“{#DOMAIN_SMTP}”:”$i”},”; done | sed 's/^(.*).$/1/') printf “{“data”:[” printf “$JSON” printf “]}”
Делаем эти файлы исполняемыми:
# cd /etc/zabbix/scripts
# chmod 0740 disc_ssl_https.sh disc_ssl_smtp.sh
Для проверки достаточно выполнить один из скриптов. На выходе должен быть вывод списка доменов в формате JSON.
{“data”:[{“{#DOMAIN_HTTPS}”:”serveradmin.ru”}]}
Если доменов несколько, то они перечисляются через запятую.
Пишем скрипты, которые будут определять, сколько дней осталось до окончания срока действия сертификата. За основу они будут брать ту дату, что мы выводили на предыдущем шаге.
# mcedit /etc/zabbix/scripts/check_ssl_https.sh#!/bin/bash SERVER=$1 TIMEOUT=25 RETVAL=0 TIMESTAMP=`echo | date` EXPIRE_DATE=`echo | openssl s_client -connect $SERVER:443 -servername $SERVER -tlsextdebug 2>/dev/null | openssl x509 -noout -dates 2>/dev/null | grep notAfter | cut -d'=' -f2` EXPIRE_SECS=`date -d “${EXPIRE_DATE}” +%s` EXPIRE_TIME=$(( ${EXPIRE_SECS} – `date +%s` )) if test $EXPIRE_TIME -lt 0 then RETVAL=0 else RETVAL=$(( ${EXPIRE_TIME} / 24 / 3600 )) fi
echo ${RETVAL}
# mcedit /etc/zabbix/scripts/check_ssl_smtp.sh#!/bin/bash SERVER=$1 TIMEOUT=25 RETVAL=0 TIMESTAMP=`echo | date` EXPIRE_DATE=`echo | openssl s_client -starttls smtp -connect $SERVER:25 2>/dev/null | openssl x509 -noout -dates 2>/dev/null | grep notAfter | cut -d'=' -f2` EXPIRE_SECS=`date -d “${EXPIRE_DATE}” +%s` EXPIRE_TIME=$(( ${EXPIRE_SECS} – `date +%s` )) if test $EXPIRE_TIME -lt 0 then RETVAL=0 else RETVAL=$(( ${EXPIRE_TIME} / 24 / 3600 )) fi echo ${RETVAL}
Делаем скрипты исполняемыми:
# chmod 0740 check_ssl_https.sh check_ssl_smtp.sh
Проверить работу скриптов можно вот так:
# /etc/zabbix/scripts/check_ssl_https.sh serveradmin.ru 66 # /etc/zabbix/scripts/check_ssl_smtp.sh mail.zeroxzed.ru
87
Не забывайте подставлять значения своих доменов, чтобы наверняка быть уверенными в том, что они нормально отдают сертификаты. На выходе у вас должна быть только цифра с количеством дней актуальности ssl сертификата. Больше ничего. Это важно, иначе заббикс сервер будет выдавать ошибку.
Связываем все наши скрипты с самим zabbix.
В данном случае, вы можете расположить скрипты для мониторинга за сертификатами на любом сервере, где есть zabbix agent. Логичнее всего, как мне кажется, все проверки, не привязанные к конкретным хостам, располагать на самом zabbix server.
Создаем файл с расширением конфигурации заббикса:
# mcedit /etc/zabbix/zabbix_agentd.d/ssl.conf UserParameter=ssl_https.discovery[*],/etc/zabbix/scripts/disc_ssl_https.sh UserParameter=ssl_https.expire[*],/etc/zabbix/scripts/check_ssl_https.sh $1 UserParameter=ssl_smtp.discovery[*],/etc/zabbix/scripts/disc_ssl_smtp.sh
UserParameter=ssl_smtp.expire[*],/etc/zabbix/scripts/check_ssl_smtp.sh $1
Я еще рекомендую в основном файле /etc/zabbix/zabbix_agentd.conf увеличить параметр Timeout. По-умолчанию, он установлен в значение 3. Если вдруг внешней проверке не хватит трех секунд, чтобы получить информацию о сертификате, итем на сервере будет на некоторое время отключен. Рекомендую увеличить секунд до 10-ти.
Хотя сам я обычно всегда этот параметр выставляю в максимальное значение — 30. Я очень часто сталкиваюсь с тем, что забываю про timeout, а потом трачу очень много времени на дебаг ошибок, которые возникают в связи с этим.
Так что я взял за правило всегда увеличивать таймаут сразу после установки и во время первоначальной настройки агента.
Сохраняем все конфиги. Делаем пользователя zabbix владельцем всех наших скриптов. Это важно, так как если этого не сделать, то проверка в консоли будет успешно отрабатывать, а на самом сервере вы увидите ошибку item not supported и потратите какое-то время, пока не поймете, почему она появляется.
# chown -R zabbix. /etc/zabbix/scripts
Перезапускаем агента:
# systemctl restart zabbix-agent
Проверяем, как заббикс агент возвращает параметры для сервера. Важный этап перед тем, как приступать к настройке самого сервера.
# zabbix_agentd -t ssl_https.discovery
ssl_https.discovery [t|{“data”:[{“{#DOMAIN_HTTPS}”:”serveradmin.ru”}]}]# zabbix_agentd -t ssl_https.expire[serveradmin.ru]
ssl_https.expire[serveradmin.ru] [t|66]
Все работает так как и должно. Теперь можно переходить на сервер.
Настройка zabbix server для мониторинга ssl сертификатов
На самом деле, тут вам ничего настраивать не придется, потому что я уже все настроил и предлагаю скачать готовый шаблон. Он создан и протестирован на версии сервера 3.2. Скорее всего он будет работать практически на всех версиях, так как разработчики следят и стараются поддерживать совместимость шаблонов между версиями, за что им большое спасибо.
Ссылка на скачивание шаблона — ssl_cert_expiration.xml
Импортируйте этот шаблон себе на сервер.
Прикрепляйте этот шаблон к тому хосту, где вы настраивали скрипты и zabbix-agent. Дальше вам остается только подождать примерно 5 минут. Такой интервал установлен для автообнарудения.
Если вам не нужно мониторить за smtp хостами, то можете отключить smtp автообнаружение и оставить только https. После того, как отработает автообнаружение, в списке итемов вы увидите добавленные домены.
Еще примерно через 5 минут, вы получите информацию о сроке действия сертификатов указанных доменов.
В шаблоне настроен триггер, который срабатывает, если время жизни сертификата становится меньше 30-ти дней. В принципе, этот параметр можно уменьшить и до 10-ти дней. Сейчас продлить сертификат не составляет каких-то проблем. Так что можете этот параметр настраивать по своему желанию.
Я рекомендую отдельно настроить повторяющиеся уведомления для триггеров из текущего шаблона. Сделать интервал раз в день или через день. Сразу скорее всего не будешь заниматься обновлением, так как не срочно. А то, что отложено на потом легко забыть, что со мной не раз случалось.
Возможные ошибки
Самая распространенная ошибка, с которой можно столкнуться — скрипты не работают от системного пользователя zabbix. Причем вы никак не поймете, в чем реально ошибка.
Просто на сервере ваши правила обнаружения или итемы с доменами будут отключены с ошибкой item not supported.
Для того, чтобы убедиться, что все в порядке, проверьте, как ваши скрипты работают под нужным пользователем.
# sudo -u zabbix /etc/zabbix/scripts/disc_ssl_https.sh
# sudo -u zabbix /etc/zabbix/scripts/check_ssl_https.sh serveradmin.ru
Вторая ошибка, с которой иногда сталкиваешься — при копировании с сайта команды и скрипты не работают. Причины могут быть разные. то двойные тире теряются, то пробелы как-то ломаются. Если вроде бы все в порядке, но не работает, попробуйте скачать полный набор скриптов и файлов, которые я сохранил отдельным архивом.
Про еще одну одну ошибку я уже сказал ранее. Она связана с параметром timeout. Установите его значение выше стандартных трех секунд.
Заключение
Источник: http://problem-info.ru/monitoring-sroka-deystviya-ssl-sertifikata-v-zabbix.html
Мониторинг срока истечения SSL сертификата и домена
Ситуации, когда сайт внезапно перестает работать по банальной причине — истек срок действия сертификата или же вовремя не продлили домен — не так редки, как того хотелось бы.
Из опыта могу сказать, что это происходит как в небольших фирмах и личных проэктах, так и в компаниях с сотнями сотрудников. Причина банальна — пресловутый человеческий фактор.
Для решения этой проблемы ХостТрекер вводит новые функции, использование которых еще более повышает шансы сайта приблизиться к желанным 100% аптайма.
Инструменты контроля
Регистраторы доменных имен обязаны сообщать владельцам об окончании аренды доменных имен, но, как показывает практика, предотвращает беду это далеко не всегда:
- Письма попадают в спам
- Ответственные сотрудники уходят в отпуск/болеют/увольняются
- Всегда есть куча более важных дел, а домен истекает лишь через 10 (7..2,1, ой!) дней
Проблемы наподобие этих возникают сплошь и рядом. И, конечно же, когда они случаются — никто не может вспомнить, кто покупал домен, с какой карты он оплачивался, а бухгалтерия на это все денег вот так сразу не дает.
Чтобы не попадать в подобные ситуации, для контроля доменов и сертификатов безопасного соединения удобно использовать инструментарий ХостТрекера.
Сервис автоматически определит сроки окончания действия доменов и/или сертификатов, и оповестит вовремя всех ответственных сотрудников любым удобным способом — по СМС, электронной почте или же Skype, например.
Эти функции могут как использоваться отдельно, так и одновременно с регулярным мониторингом аптайма.
Настройка мониторинга доменов
Занимает считанные минуты:
Просто укажите доменное имя. Если сайтов много — то удобно воспользоваться опцией «Добавить списком». Кликните «Подписки» и отметьте галочками нужные функции:
• «Поднялся» — сообщения будут отправлены за месяц, 7 и 3 дня до окончания срока аренды домена. • «Упал» — информирование об отключении домена.
• «Повтор» — сообщения об отключении отправляются каждый день до продления домена.
Галочки ставьте напротив контактов людей, которых необходимо проинформировать о необходимости что-то предпринять или проконтролировать процесс.
Чтобы получать уведомления не только через почтовый ящик, а и другими способами (Skype, телефон, Hangouts), подключите их во вкладке «Добавить контакт» или через раздел «Рассылка» на главной странице сервиса.
Подключение мониторинга сертификатов
Источник: http://www.pvsm.ru/monitoring/108922
Записки ИТ специалиста
Продолжаю статью о настройке Zabbix. Следующим шагом в настройке Заббикса будет замена доступа к веб с помощью протокола http на протокол https.
Шаг первый — создадим папку, где будут храниться ключи и сертификаты
mkdir -p /etc/nginx/ssl
Выдадим нужные права
chmod 640 -R /etc/nginx/ssl
создадим закрытый ключ сервера
openssl genrsa -out private.key 2048
Создаем CSR запрос
openssl req -new -sha256 -key private.key -out server.csr
You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter ‘.
’, the field will be left blank.
—— Country Name (2 letter code) [XX]:RU State or Province Name (full name) []:Moscow Locality Name (eg, city) [Default City]:Moscow Organization Name (eg, company) [Default Company Ltd]:LLC Company Organizational Unit Name (eg, section) []:IT Common Name (eg, your name or your server’s hostname) []:monit.domen.ru
Email Address []:[email protected]
Please enter the following ‘extra’ attributes to be sent with your certificate request A challenge password []: string is too short, it needs to be at least 4 bytes long A challenge password []:
An optional company name []:
Пароль я не вводил
В файле server.csr получили файл запрос, содержимое которого необходимо передать в центр сертификации
cat server.csr ——BEGIN CERTIFICATE REQUEST—— ….
——END CERTIFICATE REQUEST——
У меня центр сертификации StartSSL, он подписал мой запрос, выслал в ответ архив с сертификатами для разных веб-серверов. Полученный файл копируем в /etc/nginx/ssl
Пусть это будет файл с именем monit_bundle.crt. Он уже содержит в себе сертификат сервера и ЦС.
Дальше настраиваем веб-сервер NGINX.
Пример настроек можно взять отсюда
Усиливаем безопасность
chmod 400 /etc/nginx/ssl/*
chown root:root /etc/nginx/ssl/*
Редактируем файл настроек
nano /etc/nginx/conf.d/zabbix.conf
Добавляем строки
В секцию server
listen 443 ssl; ssl_certificate /etc/nginx/ssl/monit_bundle.crt; ssl_certificate_key /etc/nginx/ssl/private.key; ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers HIGH:!aNULL:!MD5;
Проверяем корректность настроек
# nginx -t nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
Применяем новые настройки
systemctl reload nginx.service
Заходим по https://имя_сервера. Если все работает хорошо, то далее можно заняться оптимизацией ssl в nginx. Если все плохо, то исправляем ошибки и снова проверяем.
Пример файла конфигурации с ssl можно взять отсюда
Источник: https://blog.volobuev.su/zashhita-veb-dostupa-zabbix-s-pomoshhyu-ssl/
Проверка сертификата сервера из bash
Проверка сертификата сервера из bash может быть полезна для мониторинга, чтобы не пропустить дату продления сертификата. Такие проблемы как продление доменного имени и продление SSL-сертификата достаточно распространены, даже серьезные организации иногда забывают проплатить домен или купить новый сертификат.
Поэтому хорошей практикой является мониторинг даты окончания действия сертификата и доменного имени. С доменным именем разберемся в другой раз, а пока давайте посмотрим, как написать скрипт, который не только покажет поля сертификата на удаленном сервере, но и скажет, сколько дней осталось до окончания сертификата.
Что нам потребуется
Для проверки будем использовать, естественно, Linux. Именно на нем чаще всего стоят системы мониторинга, такие как Zabbix и Nagios. Кроме сервера с Linux'ом нам еще кое-что потребуется. Прежде всего OpenSSL (чем свежее, тем лучше), и, конечно же, bash, на котором мы и будем писать скрипт. Этот скрипт будет полезен как при ручной проверке, так и при автоматизированных проверках.
Вот как будет организована проверка. Мы открываем SSL-соединение с сервером, получаем сертификат, передаем его на обработку OpenSSL (openssl x509), получая таким образом информацию по полям, а если нам нужно посчитать, сколько времени осталось до истечения срока действия сертификата, будет использовать отдельный параметр, который нам просто выведет количество дней в формате “N days”.
Вот сам скрипт с комментариями:
| # Функция, которая выводит помощь по параметрам Script that fetches SSL certificate information from remote server and prints out certificate fields. Can be used for certificate expiration date monitoring. Usage: certinfo.sh hostname.or.ip.address port [parameters] –issuer – Certificate issuer –start-date – Certificate start date –end-date – Certificate end date –expires-in – Expiration in days –purpose – Certificate purposes –dates – Both start and end dates –fingerprint – Certificate fingerprint –alias – Certificate aliases –all – Full certificate information (the same as without any parameters)# Функция, которая показывает, сколько дней осталось до конца действия сертификата echo “” | openssl s_client -connect ${SERVERNAME}:${PORT} 2>/dev/null | sed -n '/—–BEGIN CERTIFICATE—–/,/—–END CERTIFICATE—–/p' | openssl x509 -noout -in – -enddate DAYS_LEFT=$(( ($(date -d “$EXP_DATE” +%s) – $(date -d “now” +%s) ) / 86400 ))# Сдвигаем параметры, пропуская сервер и порт# Анализируем параметры скрипта в цикле# Это позволяет указывать их в произвольном порядке –issuer) PARAMS+=”-issuer ” ;; –subject) PARAMS+=”-subject ” ;; –serial) PARAMS+=”-serial ” ;; –email) PARAMS+=”-email ” ;; –start-date) PARAMS+=”-startdate ” ;; –end-date) PARAMS+=”-enddate ” ;; –purpose) PARAMS+=”-purpose ” ;; –dates) PARAMS+=”-dates ” ;; –fingerprint) PARAMS+=”-fingerprint ” ;; –alias) PARAMS+=”-alias ” ;; –modulus) PARAMS+=”-modulus ” ;; –pubkey) PARAMS+=”-pubkey ” ;; –all) PARAMS+=”-text ” ;; –expires-in) expires_in ;;# Если параметры не указаны, то просто выводим полную информацию о сертификатеPARAMS=${PARAMS:-“-text “}# Проверка сертификата сервера из bash# Получаем сертификат удаленного сервера из вывода SSL клиента# Выделяем само тело сертификата и передаем на обработку openssl x509# Подставляем параметры, чтобы вывелась информация по нужным полямecho “” | openssl s_client -connect ${SERVERNAME}:${PORT} 2>/dev/null | sed -n '/—–BEGIN CERTIFICATE—–/,/—–END CERTIFICATE—–/p' | openssl x509 -noout -in – $PARAMS |
Что можно улучшить
Можно дописать свои функции, которые будут выводить информация в удобном для дальнейшего использования формате, если вы планируете куда-то передавать эти данные для статистики или обработки.
Плюс можно добавить проверку параметров (выводить текст о том, что недостаточно параметров), но в данном случае это не так важно, поскольку назначение этого скрипта – мониторинг, что значит, что, скорее всего, настраиваться он будет один раз.
Источник: https://mnorin.com/proverka-sertifikata-servera-iz-bash.html
OpenSSL: Проверка SSL Сертификата — Срок Действия
Из этой статьи вы узнаете, как подключиться к сайту по HTTPS и проверить срок действия SSL сертификата из командной строки в Linux.
Помимо срока действия, я покажу, как узнать кем выдан SSL сертификат, кому он выдан, его SHA1 отпечаток и другую полезную информацию.
Пользователи Linux могут легко проверить срок действия SSL сертификата из командной строки в Linux, с помощью утилиты openssl, которая может подключаться к удаленному сайту по HTTPS, декодировать SSL сертификат и извлекать из него всю необходимую информацию.
Дельный Совет: Если в скором времени оканчивается срок действия вашего SSL сертификата — вам будет необходимо сгенерировать новый CSR! В Linux это можно легко сделать с помощью одной строки! Читать далее →
Проверить Срок Действия SSL Сертификата
Выполните следующую команду из командной строки в Linux, чтобы узнать срок действия SSL сертификата, с помощью openssl:
$ echo | openssl s_client -servername ИМЯ -connect ХОСТ:ПОРТ 2>/dev/null | openssl x509 -noout -dates
Краткое разъяснение:
| -connect ХОСТ:ПОРТ | Хост и порт для подключения. |
| -servername ИМЯ | TLS SNI (Server Name Indication) расширение (имя сайта). |
Информация: Выполните man s_client, чтобы ознакомиться со всеми доступными опциями.
В качестве примера, воспользуемся openssl, чтобы проверить срок действия SSL сертификата установленного на сайте https://www.shellhacks.com:
$ echo | openssl s_client -servername www.shellhacks.com -connect www.shellhacks.com:443 2>/dev/null | openssl x509 -noout -dates notBefore=Mar 18 10:55:00 2017 GMT notAfter=Jun 16 10:55:00 2017 GMT
OpenSSL: Проверка SSL Сертификата — Дополнительная Информация
Помимо срока действия, SSL сертификат содержит много интересной информации.
Каждый SSL сертификат содержит информацию о том, кем он был выдан, кому он выдан, его срок действия, о чем уже говорилось выше, SHA1 отпечаток SSL сертификата и прочее.
Все эти данные могут быть извлечены из SSL сертификата сайта, с помощью программы openssl из командной строки в Linux.
Проверить кто выдал SSL сертификат:
$ echo | openssl s_client -servername shellhacks.com -connect shellhacks.com:443 2>/dev/null | openssl x509 -noout -issuer issuer= /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
Проверить кому выдан SSL сертификат:
$ echo | openssl s_client -servername shellhacks.com -connect shellhacks.com:443 2>/dev/null | openssl x509 -noout -subject subject= /CN=www.shellhacks.com
Проверить срок годности SSL сертификата:
$ echo | openssl s_client -servername shellhacks.com -connect shellhacks.com:443 2>/dev/null | openssl x509 -noout -dates notBefore=Mar 18 10:55:00 2017 GMT notAfter=Jun 16 10:55:00 2017 GMT
Показать всю перечисленную выше информацию об SSL сертификате одной командой:
$ echo | openssl s_client -servername shellhacks.com -connect shellhacks.com:443 2>/dev/null | openssl x509 -noout -issuer -subject -dates issuer= /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 subject= /CN=www.shellhacks.com notBefore=Mar 18 10:55:00 2017 GMT notAfter=Jun 16 10:55:00 2017 GMT
Дельный Совет: Если у вас где-то локально лежит файл с SSL сертификатом, его также можно декодировать с помощью openssl из командной строки в Linux! Читать далее →
Получить SHA1 отпечаток SSL сертификата:
$ echo | openssl s_client -servername www.shellhacks.com -connect www.shellhacks.com:443 2>/dev/null | openssl x509 -noout -fingerprint SHA1 Fingerprint=26:F8:D5:E4:3E:7A:7B:7E:72:20:15:77:FE:C7:89:E7:E4:8A:15:CF
Извлечь всю имеющуюся информацию из SSL сертификата (декодировать):
$ echo | openssl s_client -servername www.shellhacks.com -connect www.shellhacks.com:443 2>/dev/null | openssl x509 -noout -text Certificate: Data: Version: 3 (0x2) Serial Number: 03:86:f4:63:3d:34:50:a8:47:cc:f7:99:10:1f:79:1c:21:c8 Signature Algorithm: sha256WithRSAEncryption […]
Показать сам SSL сертификат (в закодированном виде):
$ echo | openssl s_client -servername shellhacks.com -connect shellhacks.com:443 2>/dev/null | openssl x509 —–BEGIN CERTIFICATE—– MIIFGDCCBACgAwIBAgISA4b0Yz00UKhHzPeZEB95HCHIMA0GCSqGSIb3DQEBCwUA MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0xNzAzMTgxMDU1MDBaFw0x […]
Обобщающая таблица:
| -text | Печатает сертификат в расшифрованном виде. |
| -noout | Запрещает вывод закодированной версии запроса. |
| -subject | Выводит тему сертификата. |
| -issuer | Выводит кем был выдан сертификат. |
| -dates | Печатает сроки действия сертификата. |
| -fingerprint | Печатает SHA1 отпечаток закодированной версии всего сертификата. |
Информация: Выполните man x509, чтобы ознакомиться со всеми доступными опциями.
Источник: https://www.shellhacks.com/ru/openssl-check-ssl-certificate-expiration-date/
Nagios проверка срока SSL сертификатов
#!/usr/bin/perl -w
# $Id: check_certexp,v 1.
1 2006/03/10 18:25:35 holger Exp $
#
# check certificate expiry
#
# Copyright (c) 2006 Holger Weiss
#
# This program is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License
# as published by the Free Software Foundation; either version 2
# of the License, or (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place – Suite 330, Boston, MA 02111-1307, USA.
#
#
#Changed by Kuleshov Sergey
use strict;
#use Socket6;
Socket6->import(qw(inet_pton getaddrinfo));
use IO::Socket::INET6;
#use Socket;
#use IO::Socket::INET;
use Getopt::Long;
use Net::SSLeay;
use Date::Manip;
use lib “/usr/local/libexec/nagios”;
use utils qw(%ERRORS $TIMEOUT &print_revision &support);
use vars qw($PROGNAME $PORT $CRIT $opt_H $opt_V $opt_c $opt_h $opt_p
$opt_t $opt_v $opt_w);
sub days_until_expiry ($$);
sub expiry_date ($$);
sub die_crit ($);
sub die_warn ($);
sub die_unknown ($);
sub print_usage ();
sub print_help ();
my ($ssl_port, $warning, $critical, $timeout, $days);
$PROGNAME = “check_certexp”;
$PORT = 443;
$CRIT = 28;
$SIG{'ALRM'} = sub { die_unknown(“Timeout”); };
$ENV{'PATH'} = '';
$ENV{'ENV'} = '';
$ENV{'TZ'} = 'CET';
Getopt::Long::Configure(“bundling”);
if (!GetOptions(“V” => $opt_V, “version” => $opt_V,
“h” => $opt_h, “help” => $opt_h,
# actually, we won't produce any verbose output
“v+” => $opt_v, “verbose+” => $opt_v,
“H=s” => $opt_H, “hostname=s” => $opt_H,
“c=i” => $opt_c, “critical=i” => $opt_c,
“p=i” => $opt_p, “port=i” => $opt_p,
“t=i” => $opt_t, “timeout=i” => $opt_t,
“w=i” => $opt_w, “warning=i” => $opt_w)) {
print “CERTEXP UNKNOWN – Error processing command line options
“;
print_usage();
exit $ERRORS{'UNKNOWN'};
}
if ($opt_V) {
print_revision($PROGNAME,'$Revision: 1.1 $ ');
exit $ERRORS{'OK'};
}
if ($opt_h) {
print_help();
exit $ERRORS{'OK'};
}
unless ($opt_H) {
print “CERTEXP UNKNOWN – No target host specified
“;
print_usage();
exit $ERRORS{'UNKNOWN'};
}
if ( ($opt_H=~/((25[0-5]|2[0-4]d|[01]?dd?).){3}(25[0-5]|2[0-4]d|[01]?dd?)/) or ($opt_H=~/((^|:)([0-9a-fA-F]{0,4})){1,8}$/) ) {
print “CERTEXP UNKNOWN – No target host specified
“;
print_usage();
exit $ERRORS{'UNKNOWN'};
}
$critical = $opt_c ? $opt_c : $CRIT;
$warning = $opt_w ? $opt_w : $critical;
if ($warning < $critical) {
print “CERTEXP UNKNOWN – Warning smaller than critical threshold
“;
print_usage();
exit $ERRORS{'UNKNOWN'};
}
$ssl_port = $opt_p ? $opt_p : $PORT;
$timeout = $opt_t ? $opt_t : $TIMEOUT;
alarm($timeout);
my @crit_ip;my @warn_ip;my $ret = 0;
my @ip4 = `/usr/bin/host $opt_H | /usr/bin/grep -v IPv6 | /usr/bin/awk '{print $4}'`;
chomp @ip4;
my @ip6 = `/usr/bin/host $opt_H | /usr/bin/grep IPv6 | /usr/bin/awk '{print $5}'`;
chomp @ip6;
my @ip = (@ip4, @ip6);
my $ipv;
foreach (@ip) {
$opt_H = $_;
if ($opt_H =~ /((^|:)([0-9a-fA-F]{0,4})){1,8}$/) {$ipv = 6} else {$ipv = 4}
$days = days_until_expiry($opt_H, $ssl_port);
$days =~ s/^-// && die_crit(“certificate expired $days days ago”) if $days < 0;
$ret = die_crit(“certificate expires in $days days for $opt_H;”) if $days < $critical;
if ($ret == 2) {push @crit_ip, $opt_H;next}
$ret = die_warn(“certificate expires in $days days for $opt_H;”) if $days < $warning;
if ($ret == 1) {push @warn_ip, $opt_H;next}
print “OK for $opt_H – cert expires in $days days;”;
#exit $ERRORS{'OK'};
}
exit 1 if @warn_ip;
exit 2 if @crit_ip;
sub days_until_expiry ($$) {
my ($host, $port) = @_;
(my $exp = expiry_date($host, $port)) =~ s/ GMT//;
int((&UnixDate(&ParseDate($exp),”%s”) – time) / 86400);
}
sub expiry_date ($$) {
my ($host, $port) = @_;
my ($buffer, $iaddr, $paddr, $ctx, $ssl, $crt, $end, $str);
# connect socket
$iaddr = $ipv eq '4' ? inet_pton(AF_INET,$host) : inet_pton(AF_INET6,$host)
|| die_unknown(“Invalid hostname/address: $host”);
$paddr = $ipv == 4 ? sockaddr_in($port, $iaddr) : sockaddr_in6($port, $iaddr);
if ($ipv == 4) {socket(SOCK, PF_INET, SOCK_STREAM, getprotobyname('tcp')) || die_unknown(“Socket error: $!”)}
else {socket(SOCK, PF_INET6, SOCK_STREAM, getprotobyname('tcp')) || die_unknown(“Socket error: $!”)}
connect(SOCK, $paddr) || die_unknown(“Error connecting to $host: $!”);
# initialize SSL
Net::SSLeay::load_error_strings();
Net::SSLeay::SSLeay_add_ssl_algorithms();
Net::SSLeay::randomize();
$ctx = Net::SSLeay::CTX_new();
$ssl = Net::SSLeay::new($ctx);
Net::SSLeay::set_fd($ssl, fileno(SOCK));
Net::SSLeay::connect($ssl) || die_unknown(Net::SSLeay::print_errs());
# get certificate
$crt = Net::SSLeay::get_peer_certificate($ssl)
|| die_unknown(Net::SSLeay::print_errs());
# get expiry date (string)
$end = Net::SSLeay::X509_get_notAfter($crt);
$str = Net::SSLeay::P_ASN1_UTCTIME_put2string($end);
# cleanup
Net::SSLeay::free($ssl);
Net::SSLeay::CTX_free($ctx);
close SOCK;
$str;
}
sub die_unknown ($) {
printf “CERTEXP UNKNOWN – %s
“, shift;
exit $ERRORS{'UNKNOWN'};
}
sub die_warn ($) {
printf “CERTEXP WARNING – %s”, shift;
# exit $ERRORS{'WARNING'};
return 1;
}
sub die_crit ($) {
printf “CERTEXP CRITICAL – %s”, shift;
# exit $ERRORS{'CRITICAL'};
return 2;
}
sub print_usage () {
print “Usage: $PROGNAME -H host [-p port] [-w warn] [-c crit]” .
“[-t timeout] [-v]
“;
}
sub print_help () {
print_revision($PROGNAME, '$Revision: 1.1 $');
print “Copyright (c) 2006 Holger Weiss
“;
print “Check certificate expiry date.
“;
print_usage();
print
Источник: http://unix-way.ru/index.php/perl-conv/nagios-proverka-sroka-ssl-sertifikatov
Проверка параметров SSL/TLS-серверов в консоли FreeBSD
Если Вы захотите выяснить параметры SSL/TLS некоторого публичного HTTPS-сервера, Вам поможет не нуждающийся в представлении SSL Server Test от Qualys SSL Labs.
А что делать, если потребуется проверить аналогичные параметры HTTPS-серверов, доступ к которым ограничен, или серверов FTP, IRC, IMAP, POP3, SMTP, XMPP и PostgreSQL, которые поддерживают SSL/TLS? Не думаю, что Вы сильно удивитесь, если я предложу воспользоваться популярными в мире Linux и Unix инструментами, к числу которых относятся OpenSSL, nmap и SSLScan.
Какие параметры мы будем проверять?
Эта заметка описывает относительно простые в использовании и доступные в большинстве операционных систем семейства Linux / Unix способы проверки таких параметров SSL/TLS-серверов, как свойства и отсутствие ошибок установки их собственных SSL-сертификатов (далее — сертификатов), свойства и корректность работы цепочек сертификатов, в состав которых входят серверные сертификаты, поддержка TLS-расширений Server Name Indication и OCSP stapling, поддержка SSL/TLS-протоколов (далее — протоколов), а также соответствующих им наборов шифров, и, наконец, наличие некоторых опасных уязвимостей. Невзирая на то, что для решения перечисленных задач хватит функциональности OpenSSL, я рекомендую Вам не игнорировать соответствующие возможности nmap и SSLScan, использование которых не требует специальной подготовки, а результаты работы предоставляются в более простой для восприятия форме.
Подготовка OpenSSL, nmap и SSLScan
Все действия, которые описаны в данной заметке, выполнялись на компьютере с операционной системой FreeBSD 9.3 RELEASE. Все упоминаемое программное обеспечение устанавливалось из обновленной коллекции портов.
Обязательно учтите, что для корректного решения поставленной задачи требуется заменить устаревший пакет OpenSSL, входящий в состав FreeBSD, более свежим аналогом из коллекции портов.
Для его установки необходимо выполнить команды:
cd /usr/ports/security/openssl
make WITH=”ZLIB” install clean
Следует отметить, что выбор опции [X] ZLIB zlib compression support (добавление WITH=”ZLIB” в команду make install) не является обязательным, но он будет полезен в том случае, если Вы планируете не только проверять параметры SSL/TLS-серверов, но и тестировать их на наличие уязвимостей.
После завершения установки OpenSSL нужно добавить в файл /etc/make.conf строку:
DEFAULT_VERSIONS+=ssl=openssl
Теперь устанавливаемые порты будут использовать обновленный OpenSSL (порты, установленные до обновления OpenSSL, придется пересобрать).
Для установки nmap и SSLScan необходимо выполнить команды:
cd /usr/ports/security/nmap
make WITH=”SSL” install clean
cd ../sslscan
make install clean
В связи с тем, что браузеры и другие SSL/TLS-клиенты используют корневые сертификаты из своих собственных хранилищ доверенных корневых сертификатов, поставщики сертификатов не рекомендуют устанавливать корневые сертификаты на серверы. Для избавления от проблем, связанных с отсутствием тех или иных корневых сертификатов, входящих в состав цепочек сертификации, достаточно установить порт security/ca_root_nss командами:
cd /usr/ports/security/ca_root_nss
make WITH=”ETCSYMLINK” install clean
После завершения установки / переустановки перечисленных портов можно приступать к проверке параметров TLS/SSL-серверов.
Общий случай использования команды openssl s_client
Команда openssl s_client предназначена для установки соединения с удаленным SSL/TLS-сервером, передачи ему команд, приема результатов их выполнения и отображения информации об используемых параметрах SSL/TLS. Если команда не содержит ключ -connect host:port, выполняется подключение к серверу localhost:4433.
По умолчанию сведения о параметрах SSL/TLS имеют среднюю детальность (на мой взгляд, она устроит подавляющее большинство системных администраторов), если добавить ключ -brief — минимальную, ключи -debug и / или -tlsextdebug — повышенную.
В общем случае для проверки параметров какого-либо SSL/TLS-сервера достаточно указать команду s_client и единственный ключ -connect host:port. Например, команда:
/usr/local/bin/openssl s_client -connect sergeysl.ru:443
отобразит примерно такие сведения о HTTPS-сервере, на котором размещается мой персональный сайт (для сокращения размера данной заметки значительная часть содержимого сертификата сервера (Server certificate) и мандата сессии TLS (TLS session ticket) заменена точками):
Источник: https://SergeySL.ru/check-parameters-of-ssl-tls-servers-on-freebsd-console/
Мониторинг доступности и работа сайта во время выходных
26 июня 2017 в 12:08 (МСК) | сохранено26 июня 2017 в 17:20 (МСК)<\p>
После покупки виртуального и/или выделенного сервера важно вовремя получать информацию о недоступности сервиса, то есть проводить мониторинг основных подсистем веб-сайта.
Надежный веб-сайт должен быть легкодоступен для пользователей 7 дней в неделю, поэтому его надо постоянно проверять как на предмет доступности, так и на предмет работоспособности:
- регулярная самостоятельная проверка работоспособности веб-сайта с помощью бесплатных инструментов;
- постоянный мониторинг доступности сайта, оптимальным для которого является часовой интервал: большинство пользователей попытаются вернуться на сайт в течение 1-2 часов, более частые проверки не гарантируют более оперативного исправления проблем быстрее, чем в течение часа;
- мониторинг компонентов проекта и анализ метрик приложений: скорости ответа, ошибок компонентов, сервисов, скорость ответов базы данных, мониторинг запросов без индексов или медленных запросов;
- мониторинг производительности веб-сайта: медленная загрузка страниц может стоить потери клиентов, в то время как в результате мониторинга приходит своевременное уведомление о проблемах, позволяющее оперативно их устранять и минимизировать последствия;
- мониторинг проблем заключается в отслеживании нескольких параметров сайта с частотой не менее раза в минуту из нескольких географических точек, для чтобы максимально покрыть минутный интервал проверками и установить возможные проблемы, связанные с географией пользователей.
Среди возможных критериев проверки можно выделить следующие проблемы:
- с DNS-сервером (когда в определенные интервалы времени адрес сайта не может быть определен, хотя сам сайт физически доступен);
- с большим временем ответа (при обновлении кэша, например, или при выполнении «тяжелых» задач на стороне сервера);
- с плановым выполнением задач (в результате которых сайт будет не доступен только в определенные моменты времени);
- с большим времени ожидания статических файлов (например, из-за сетевой инфраструктуры или проблем с физическим носителем);
- с подключением к базе данных.
Многие внешние сервисы уже сейчас предоставляют детальную информацию о проблемах, вплоть до логов ошибок на стороне клиента (при соответствующей настройке и ведения логов ошибок со стороны сервера). Подобные методы особенно хороши, когда требуется отловить какую-то «плавающую» ошибку — при включении детальных логов возникающей ошибки на стороне сервера, можно ее эффективно отследить и устранить. Есть задача: веб-сайт/сервер/сервис должен работать непрерывно несколько дней без человеческого вмешательства. Что может пойти не так? Обычные сбои время от времени случаются сами по себе. Только вот ночной сбой со вторника на среду решается перезаливом с бэкапа в среду утром. А на выходных нередки сбои «с пятницы на понедельник». Сколько в таком случае может лежать сайт во время праздников, зависит от длительности отпуска ответственных сотрудников. В целом, сайту бывает нехорошо, но в будние дни проблема решается быстро. Сколько времени заняло бы решение на майских, если бы не мониторинг? Вместо пары часов могло бы быть пару дней, и это не редкость. Не делайте серьезных изменений кода перед длительными выходными. Необходимо тщательно протестировать систему с внесенными правками, чтобы изменения работали должным образом. Рекомендуется откладывать внесение каких-либо серьезных изменений до того момента, когда веб-сайт испытывает меньше нагрузки на трафик. Кроме обычных проблем, сайты во время длительного отсутствия бдительных стражей любят также подхватить и другие недуги. Например, может закончиться срок действия домена или сертификата. Или надумает растолстеть база данных. Или он может угодить в списки DNSBL или Роскомнадзора. Важной функцией является проверка доменов в черных списках DNSBL (DNS blacklist или DNS blocklist) — списки хостов, хранимые с использованием системы архитектуры DNS. Обычно используются для борьбы со спамом. Эти списки независимы и формируются каждый по своему алгоритму, из-за чего в результате случайной ошибки там может оказаться даже безобидный сайт. IP адрес из вашей подсети может использоваться в злонамеренных целях, например, спамерами или другими злоумышленниками, в результате чего вся подсеть может оказаться заблокированной в черном списке соответствующей структуры. Чем это грозит именно вам? Письма от вас перестанут приходить клиентам, сайт станет хуже отображаться в поисковиках и так далее по нарастающей. Поэтому функция контроля и оповещения о попадании в наиболее популярные черные списки является весьма востребованной. Каждый администратор может настроить свой веб-сервер таким образом, чтобы, например, не получать письма от серверов, перечисленных в определенном списке. Это помогает бороться со спамом, распространением вредоносного ПО, DDoS-атаками и другими проблемами.
Онлайновые черные списки DNSBL, например, antispamsniper.com или syslab.ru, позволяют фильтровать спам, используя DNS для доступа к базам спамерских IP адресов.
Для проверки наличия заданного IP адреса в черных списках введите IP адрес (ваш текущий IP адрес указывается по умолчанию) и нажмите кнопку Проверить.
Если от доступности веб-сайта зависит прибыль, то следует подготовить его к возрастающим нагрузкам (например, во время сезонных распродаж или Черной пятницы) и возможным атакам конкурентов и/или злоумышленников, которые рассчитывают на увеличение времени отклика веб-сайта на входящие запросы или на частичную/полную недоступность.
Программное обеспечение сервера, на базе которого построен веб-сайт или иной ресурс, должно периодически обновляться. Планирование технических работ позволяет достигнуть двух целей: не присылать оповещения об ошибках и не записывать ошибки во время определенного интервала времени в статистику.
При этом проверки во время технических работ все так же идут и исправно пишутся в лог, а следовательно могут быть полезными для администраторов: лог позволяет определить, сколько именно длилось обновление или перезагрузка, какие ошибки при этом выдавались, какие проблемы при этом наблюдались и так далее.
Рекомендуется проводить плановые работы во время заметного уменьшения (редуцирования) клиентского трафика, а также во время отсутствия пиковой загрузки полосы пропускания.
Проблемы с продлением доменов и сертификатов возникают даже у больших компаний. Поэтому оповещение (по СМС или электронной почте), что данный домен необходимо продлить, является крайне полезным.
Например, ping-admin.ru предоставляет платные услуги оповещения о результатах мониторинга.
Проверить домен бесплатно можно с помощью сервиса nic.ru.
Проверить время действия домена бесплатно можно с помощью сервиса Whois Service.
Выполните следующую команду из командной строки в Linux, чтобы узнать срок действия SSL сертификата, с помощью openssl:$ echo | openssl s_client -servername ИМЯ -connect ХОСТ:ПОРТ 2>/dev/null | openssl x509 -noout -dates
Помимо срока действия, SSL сертификат содержит много интересной информации. Каждый SSL сертификат содержит информацию о том, кем он был выдан, кому он выдан, его срок действия и прочее. Все эти данные могут быть извлечены из SSL сертификата сайта с помощью программы openssl из командной строки в Linux. Проверить кто выдал SSL сертификат:$ echo | openssl s_client -servername site.com -connect site.com:443 2>/dev/null | openssl x509 -noout -issuer
issuer= /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
Проверить кому выдан SSL сертификат:$ echo | openssl s_client -servername site.com -connect site.com:443 2>/dev/null | openssl x509 -noout -subject
subject= /CN=www.site.com
Проверить срок годности SSL сертификата:$ echo | openssl s_client -servername site.com -connect site.com:443 2>/dev/null | openssl x509 -noout -dates
notBefore=Mar 18 10:55:00 2017 GMT
notAfter=Jun 16 10:55:00 2017 GMT
Показать всю перечисленную выше информацию об SSL сертификате одной командой:$ echo | openssl s_client -servername site.com -connect site.com:443 2>/dev/null | openssl x509 -noout -issuer -subject -dates
issuer= /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
subject= /CN=www.site.com
notBefore=Mar 18 10:55:00 2017 GMT
notAfter=Jun 16 10:55:00 2017 GMT
Для эффективной работы любого посещаемого веб-сайта необходима постоянная доступность его материалов для посетителей, а также возможность для администратора проекта иметь доступ к серверной части для внесения изменений или любых других действий. Вы легко можете проверить доступность сайта из командной строки в Linux и получить от сервера код со статусом HTTP, с помощью таких команд как TELNET или CURL. Выполните следующую команду для проверки доступности сайта и получения сообщения со статусом от сервера:$ curl -Is http://www.site.com | head -1
HTTP/1.1 200 OK
Статус код ‘200 OK’ означает что запрос был успешно выполнен и сайт доступен. Вот еще один пример, который показывает как curl отображает разные ответы сервера:$ curl -Is http://site.com | head -n 1
HTTP/1.1 301 Moved Permanently
Также с помощью curl можно проверить доступность отдельной страницы на сайте, например:$ curl -Is http://www.site.com/en/Bash-Colors | head -n 1
HTTP/1.1 200 OK
Вы также можете проверить доступность сайта и получить сообщения со статусом от сервера с помощью команды telnet:$ telnet www.site.com 80
Trying 91.206.200.119…
Connected to www.site.com.
Escape character is '^]'.
HEAD / HTTP/1.0
HOST: www.site.com
Вывод, означающий, что сайт доступен, будет выглядеть следующим образом:HTTP/1.1 200 OK
Server: nginx/1.1.10
Date: Sun, 26 May 2017 19:29:46 GMT
***
В заключении хочется отметить, что всегда есть вариант написать свой скрипт для проверки аптайма на PHP или Perl, или можно создать телеграм-бота для рассылки уведомлений, но подсчитав дневной доход с веб-сайтов и соотнеся его со стоимостью мониторинга, чаще дешевле использовать платные сервисы типа PagerDuty. Полезные статьи со обзорами сервисов мониторинга:
Источник: https://sohabr.net/habr/post/331648/?version=238263
Загрузка...
