7 бесплатных сервисов для проверки сайтов (о которых вы могли и не знать) / Хабр
Мне достаточно часто приходится использовать различные онлайн-сервисы для проверки доступности сайтов и их поверхностных тестов и проверок.
Как показал краткий опрос коллег — почти у всех эти наборы сервисов отличаются. Я хочу показать вам свой, прошу в .
LoadImpact: http://loadimpact.com, сервис нагрузочного тестирования сайтов (за деньги — до 5к одновременных подключений) у которого есть бесплатный тест на 50 одновременных соединений. Если вы хоститесь у безжалостного и беспощадного отечественного хостера за $0,01/месяц и у вас всего тысяча сайтов на сервере — попробуйте проверить свой, с высокой вероятностью он даже 50 одновременных подключений не выдержит.
BrowserMob: http://browsermob.com, дополнительный простой, но симпатичный сервис, позволяющий проверить скорость загрузки целевого сайта из 4 разных мест и показывающий много подробных метрик загрузки для каждого из них. А основная задача BrowserMob — автоматическое кросс-браузерное тестирование сайтов.
Alertra: http://alertra.com, сервис мониторинга аптайма, на сайте которого можно бесплатно проверить доступность (и время ответа) сайта из 11 разных мест. Работает быстро и надежно, никаких капч и прочей дребедени.
site24x7: http://site24x7.com, похожий на Alertra сервис, который использует уже 23 географически распределеные точки проверки.
You get signal: http://www.yougetsignal.com, отличный сервис позволяющий проверить открытые порты на любом хосте/IP. Частенько помогает для проверки проброса портов через NAT-ы.
Теперь перейдем от проверок доступности к чуть более сложным вещам. Писать про w3c-шные продукты я не буду, надеюсь все и так их знают и используют.
CSE HTML Validator: http://www.onlinewebcheck.com альтернатива известнейшему validator.w3.org, построенная [судя по всему] на своем отдельном ядре анализа. Выгодно отличается очень подробными и понятными рекомендациями по исправлению ошибок и потенциальных проблем.
Built with: http://builtwith.com/ анализирует заданный сайт и выдает целое досье о нем: веб-сервер, CMS, какая служба статистики используется и так далее. Показателей очень много, для беглого анализа конкурентов вполне подходит. Также, интересно покопаться в trends.builtwith.com где владельцы сервиса выдают статистику по всем отслеживаемым параметрам. Например подавляющее большинство сайтов до сих пор использует старый блокирующий JS-код для Google Analytics.
А какие сервисы есть у вас в закладках?
Анализ сайта онлайн, проверка ИКС, рейтинга и авторитета
24ho.ru – Ведущий Сео сервис для вебмастеров, дающий полную характеристику и оценку сайта. Другими словами наш сервис предлагает полноценный сео аудит, благодаря которому вы сможете улучшить показатели качества и сео оптимизацию своего портала. Чтобы получить отчет по сайту достаточно лишь ввести его адрес в строку анализа, и дождаться результата. Все отчеты и советы даются бесплатно. Количество проверок в день не ограничено.
Анализируем ваш сайт… — 70% Готово!
Сео сервис раскроет название, описание, ключевые слова, количество заголовков (h2-h6), покажет число картинок без указанных атрибутов alt, процент текста по отношению к коду (text to html ratio), статус редиректов, GZIP компрессию, стоимость ресурса, даст советы по ссылкам, покажет число проиндексированных страниц и число обратных ссылок на вашу площадку. Помимо этого сервис предоставит данные WHOIS, даст точную оценку его качества и глобальный рейтинг в мире. Укажет на битые ссылки и скорость по Google PageSpeed insights, ошибки в HTML и CSS коде.Вопрос — Ответ
Нажмите на вопрос, чтобы просмотреть ответ
Ответ: Надо понимать, что у каждого ресурса свой путь и своя история. Кто-то продвигается через рекламные компании и на сео оптимизацию не обращает никакого внимания. Есть многолетние сайты, которые уже давно получили признание и известность в широких массах. Их не ищут в поиске. Их просто вбивают в адресную строку. Либо это сайты известных компаний. Будет ли-кто нибудь искать сайт sberbank.ru?
Ответ: Наш сервис, как и многие другие подобные сервисы, периодически посещает все сайты и проводит его анализ, в том числе и ссылочный. Если какие то ссылки не обнаружены нашим сервисом, значит он пока не посетил те страницы, на которых они размещены.
Ответ: Значит у них настроена качественная рекламная компания. Дай Бог здоровья этому директологу!
Ответ: Можем исправить все ошибки и помочь с продвижением. Пишите на почту [email protected].
Ответ: Скорее всего у вас достаточно молодой сайт. Для молодого сайта очень важно выждать период «песочницы». Это тот период, когда поисковые системы относятся с подозрением к вашему сайту, и длится он от полугода до года. После этого периода вы уже сможете спокойно конкурировать с устоявшимися старичками и даже возможно обогнать их в позициях. Ну а до тех пор, ни о каком нахождении в топе и речи быть не может. Даже если вы создадите самый качественный сайт в мире. Старайтесь постоянно улучшать свой сайт. Добавляйте контент, наращивайте ссылочную массу. В общем проводите как внутреннюю так и внешнюю сео оптимизацию. Если не хотите долго ждать, то всегда можно выйти в топ с помощью контекстной рекламы.
Любому вебмастеру или владельцу сайта, который нанял seo специалиста, периодически надо проводить экспресс анализ своего проекта на основные сео показатели. Это как зарядка утром для поддержания здоровья. Наш анализатор возможно откроет вам те ошибки, о существовании которых вы не знали. Также он даст вам общую картину и направление куда двигаться и что предпринимать, чтобы усилить и закрепить движение к росту.
2.Check Point на максимум. HTTPS-инспекция / Блог компании TS Solution / Хабр
В предыдущем уроке мы затронули проблему человеческого фактора в Информационной безопасности. В итоге мы сделали вывод, что не важно на сколько качественное и дорогое оборудование вы используете, т.к. все “упрется” в настройку, которая должна быть выполнена грамотно. В этом уроке мы рассмотрим https-инспекцию. Довольно многие недооценивают важность этой функции без которой немыслима современная защита сети. Но обо всем по порядку.
Защита веб-трафика
HTTPS
Думаю, что нет особого смысла рассказывать что такое HTTPS и на сколько он важен для организации безопасного Интернета. Благодаря HTTPS можно быть уверенным, что между клиентом (браузер) и сервером (web-server) невозможно перехватить или изменить передаваемую информацию. Согласно статистике за 2017 год, доля HTTPS-трафика превысила 50%.
Более того, современные браузеры (например google chrome) будут помечать http-сайты с формой авторизации как недоверенные, а google будет понижать их в поисковой выдаче. Все это спровоцирует еще более стремительное увеличение доли HTTPS-трафика.
Как было сказано ранее, HTTPS используется для защищенного общения между двумя узлами в сети Интернет. При этом HTTPS не является каким-то новым протоколом, в целом это обычный HTTP, просто для защиты трафика в качестве транспортного протокола используется SSL или TLS. Именно эти протоколы и отвечают за аутентификацию, шифрование и целостность трафика. Мы не будем подробно рассматривать работу этих протоколов, но всем кто интересуется очень рекомендую вот эту статью. В грубом приближении работа HTTPS выглядит следующим образом:
Т.е. клиент инициирует TLS-запрос к Web-серверу и получает TLS-ответ, а также видит цифровой сертификат, который естественно должен быть доверенным. Пример сертификата при обращении на сайт vk.com изображен выше. В нем содержатся параметры защищенного соединения и открытый ключ. Кроме того, браузер может “подсказать” какая именно версия TLS используется. Повторюсь, что это очень упрощенное описание работы TLS.
После успешного TLS Handshake, начинается передача данных в шифрованном виде. Казалось бы, что это очень хорошо (так оно и есть). Однако для “безопасника” в компании это настоящая головная боль. Поскольку он не “видит” этот трафик и не может проверять его содержимое ни антивирусом, ни системой предотвращения вторжений (IPS), ни DLP-системой, ничем… А это в свою очередь представляет собой очень серьезную уязвимость. Т.к. большинство сайтов переходят на HTTPS, то без HTTPS инспекции ваш интернет-шлюз не может проверять большую часть Web-трафика (т.к. он зашифрован). Кроме того, злоумышленники все чаще используют облачные файловые хранилища для распространения вирусов, которые также работают по HTTPS. Таким образом, каким бы качественным и дорогим не был ваш межсетевой экран (будь то UTM или NGFW решение), он будет пропускать абсолютно все вирусы и зловреды без включенной HTTPS инспекции. Даже пресловутый тестовый вирус EICAR, который детектится любым антивирусом, будет успешно проходить вашу защиту через HTTPS. Мы это обязательно рассмотрим на примере.
HTTPS-инспекция
Решить проблему безопасников призвана технология HTTPS-инспекции. Ее суть до безобразия проста. Фактически, устройство, которое организует HTTPS-инспекцию, совершает атаку типа man-in-the-middle. Выглядит это примерно следующим образом:
Т.е. Check Point перехватывает запрос пользователя, поднимает с ним HTTPS-соединение и уже от себя поднимает HTTPS-сессию с ресурсом, к которому обратился пользователь. В данном случае клиенту предъявляется сертификат, который выпустил сам Check Point. Само собой, что данный сертификат должен быть доверенным. Для этого в Check Point-е есть возможность импортировать сертификат от доверенного CA (subordinate certificate). При импортировании убедитесь, что сертификат имеет алгоритм подписи не ниже sha256, т.к. если он будет например sha1, то современные браузеры будут “ругаться” на такие сертификаты. Либо же вы можете сгенерировать самоподписанный сертификат, который затем необходимо сделать доверенным для всех компьютеров. Именно этот способ мы рассмотрим на примере.
Таким образом, оказавшись посередине между двумя шифрованными соединениям, Check Point получает возможность проверять трафик и все файлы, как с помощью антивируса, так и с помощью остальных блейдов (IPS, Threat Emulation и т.д.). Более подробно о HTTPS-инспекции Check Point вы можете почитать здесь.
Ограничения HTTPS-инспекции
Однако, не все так просто. Метод man-in-the-middle работает далеко не всегда. Есть случаи когда расшифровать https-трафик просто невозможно. Вот несколько примеров:
1) Используются отечественные криптоалгоритмы (ГОСТ) вместо стандартных SSL/TLS.
На данный момент ни одно иностранное решение не может обеспечивать корректную расшифровку подобного HTTPS-трафика (хотя и отечественных решений умеющих делать подобную https-инспекцию лично я не знаю). В качестве решения можно настроить исключения в HTTPS-инспекции для сайтов данной категории.
2) Используется Certificate Pinnig.
Т.е. приложение клиента заранее знает сертификат сервера, к которому он обращается. Обычно проверяется серийный номер сертификата. В этом случае приложение просто не будет смотреть в локальное хранилище доверенных сертификатов и при попытке подмены естественно будет возникать ошибка. Чаще всего данная проблема относится к толстым клиентам (такие как Skype, Telegram), которые используют SSL/TLS в качестве транспорта. Кроме того, буквально на днях обнаружил, что обновленная версия google chrome также начала использовать технологию certificate pinning для своих сервисов (youtube, google drive, gmail и так далее). Это делает невозможным использование https-инспекции. Компания Google активно заботится о безопасности пользователей, но значительно усложняет жизнь безопасникам. В этом случае есть два выхода:
- Настроить исключения в https-инспекции для сервисов Google. Уверен, что для компаний это крайне нежелательно.
- Использовать другой браузер… Например Firefox.
Уверен, что многих интересует проблема таких приложений как telegram и т.д. К сожалению (или к счастью) на данный момент расшифровывать этот трафик не предоставляется возможным. Либо вы блокируете эти приложения, т.к. на сетевом уровне невозможно “видеть” этот трафик, либо используете дополнительный уровень защиты в виде каких-то агентов на компьютерах пользователей, например CheckPoint SandBlast Agent, который сможет проверять на зловредность уже расшифрованный трафик (например полученные файлы через мессенджер).
3) Используется аутентификация не только сервера, но и клиента.
Это характерно для сайтов из категории финансовых услуг, когда для доступа к какому-нибудь банк-порталу клиент использует специальный ключ или токен. Естественно, что в данном случае устройство, которое осуществляет HTTPS-инспекцию просто не сможет организовать https-соединение с сервером, т.к. не обладает нужным ключем. Проблема решается только настройкой исключений в HTTPS-инспекции.
4) Используется отличный от SSL/TLS протокол.
В данном случае речь уже не о ГОСТ-шифровании, а об относительно новом протоколе от google — quic. Компания гугл начинает активно переводить свои сервисы именно на этот протокол. При этом на текущий момент невозможно обеспечить его расшифровку. Единственным решением в данном случае является блокировка протокола quic, после чего сервисы google начинают использовать стандартный SSL/TLS.
Настройка
Описать настройку в формате текста довольно трудоемко, поэтому мы сделали небольшое видео. В первой части рассказывается вышеописанная теория, а во второй части мы пробуем скачать вирус по HTTPS, а затем настроим HTTPS-инспекцию и сравниваем результат.
Вывод
Самое главное, что нужно вынести из этого урока — HTTPS-инспекция это ОБЯЗАТЕЛЬНЫЙ компонент современной защиты. Без этой функции в вашей сети огромная черная дыра с точки зрения безопасности. И это относится не только к Check Point-у, но и ко всем другим решениям. Обязательно протестируйте свою сеть подобным образом. Все что нужно, это какой-нибудь тестовый вирус и клиентская машина, желательно без антивируса, чтобы тот не смог заблокировать скачивание файла (для чистоты эксперимента).
На этом мы заканчиваем второй урок, спасибо за внимание!
Провести бесплатный аудит настроек безопасности Check Point можно здесь
P.S. Хотелось бы поблагодарить Алексея Белоглазова за помощь в подготовке урока.
Nginx и https. Получаем класс А+ / Хабр
Недавно вспомнилось мне, что есть такой сервис — StartSsl, который совершенно бесплатно раздаёт trusted сертификаты владельцам доменов для личного использования. Да и выходные попались свободные. В общем сейчас напишу, как в nginx настроить HTTPS, чтобы при проверке в SSL Labs получить рейтинг А+ и обезопасить себя от последних багов с помощью выпиливания SSL.
Итак, приступим. Будем считать, что у вы уже зарегистрировались на StartSsl, прошли персональную проверку и получили вожделенный сертификат. Для начала опубликую итоговый конфиг, а после этого разберу его.
Вот что у меня получилось:
server {
server_name dsmirnov.pro www.dsmirnov.pro;
listen 80;
return 301 https://dsmirnov.pro$request_uri;
}
server {
listen 443 ssl spdy;
server_name dsmirnov.pro;
resolver 127.0.0.1;
ssl_stapling on;
ssl on;
ssl_certificate /etc/pki/nginx/dsmirnov.pro.pem;
ssl_certificate_key /etc/pki/nginx/dsmirnov.pro.clean.key;
ssl_dhparam /etc/pki/nginx/dhparam.pem;
ssl_session_timeout 24h;
ssl_session_cache shared:SSL:2m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers kEECDH+AES128:kEECDH:kEDH:-3DES:kRSA+AES128:kEDH+3DES:DES-CBC3-SHA:!RC4:!aNULL:!eNULL:!MD5:!EXPORT:!LOW:!SEED:!CAMELLIA:!IDEA:!PSK:!SRP:!SSLv2;
ssl_prefer_server_ciphers on;
add_header Strict-Transport-Security "max-age=31536000;";
add_header Content-Security-Policy-Report-Only "default-src https:; script-src https: 'unsafe-eval' 'unsafe-inline'; style-src https: 'unsafe-inline'; img-src https: data:; font-src https: data:; report-uri /csp-report";
}
В первой секции всё вроде понятно, любой вход по http с любым URI редиректит с этим-же URI в схему https.
Начнём разбор секции server для https. Директивой listen 443 ssl spdy; сразу включаем spdy. Вот на картинке разница:
Следущим шагом включаем ssl_stapling on; — позволяем серверу прикреплять OCSP-ответы, тем самым уменьшая время загрузки страниц у пользователей. Цепочка сертификатов (доменный — промежуточный центр авторизации — корневой центр авторизации) может содержать 3-4 уровня. И на каждый уровень браузер должен устанавливать соединение и получать сертификат. Можно отправить все сертификаты (включая промежуточный: именно за этим была настройка TCP-окон отправки, чтобы цепочка сертификатов гарантированно поместилась в в одну пересылку пакетов) разом, тогда браузер проверит всю цепочку локально, а запросит только корневой (который в большинстве случаев уже находится на клиенте). Для работы этой функции обязательно описать resolver — у меня поднят свой собственный DNS сервер, поэтому в качестве значения указан 127.0.0.1, Вы можете указать 8.8.8.8, но многие в последнее время на него ругаются. Что такое ssl on; я думаю нет смысла рассказывать.
Далее директивами ssl_certificate и ssl_certificate_key указываем пути к полученным через StartSsl сертификатам. У вас уже есть 3 файла: domain.ru.key, domain.ru.crt и sub.class1.server.ca.pem. Копируем ключи в ( моём случае ) /etc/pki/nginx.
Не забываем, что pem файл для nginx должен быть смержен с сертификатом CA ( Должно получиться из 3х — 2 файла. ):
cp domain.ru.key /etc/pki/nginx
cat domain.ru.crt sub.class1.server.ca.pem > /etc/pki/nginx/domain.ru.pem
Теперь о ssl_dhparam /etc/pki/nginx/dhparam.pem; — это нужно, чтобы у нас заработал Forward Secrecy. Прямая секретность означает, что если третья сторона узнает какой-либо сеансовый ключ, то она сможет получить лишь доступ к данным, защищенным лишь этим ключом. Для сохранения совершенной прямой секретности ключ, используемый для шифрования передаваемых данных, не должен использоваться для получения каких-либо дополнительных ключей. Также, если ключ, используемый для шифрования передаваемых данных, был получен (derived) на базе какого-то еще ключевого материала, этот материал не должен использоваться для получения каких-либо других ключей.
Сгенерировать ключ можно так:
openssl dhparam -out /etc/pki/nginx/dhparam.pem 4096
Далее несложные настройки ssl_session_timeout 24h; и ssl_session_cache shared:SSL:2m;, которые не требуют особенных описаний — срок истечения сессии и размер памяти, выделяемой для хранения кеша — у меня бложик маленький, поэтому 2 Мб вполне достаточно.
Дальше — важные параметы: ssl_protocols TLSv1 TLSv1.1 TLSv1.2; и ssl_ciphers kEECDH+AES128:kEECDH:kEDH:-3DES:kRSA+AES128:kEDH+3DES:DES-CBC3-SHA:!RC4:!aNULL:!eNULL:!MD5:!EXPORT:!LOW:!SEED:!CAMELLIA:!IDEA:!PSK:!SRP:!SSLv2; — тут мы указываем, что мы желаем только TLS и второй строкой выжигаем калёным железом все SSL. В свете последних фейлов с SSL — очень актуально, что и Вам советую. Ну и директивой ssl_prefer_server_ciphers on; принуждаем nginx это всё строго соблюдать.
Директива add_header Strict-Transport-Security «max-age=31536000;»; указывает браузерам сколько они должны помнить данные требования безопасности для моего домена. В данном случае — 1 год. Кстати, если директиву написать вот так: add_header Strict-Transport-Security «max-age=31536000; includeSubDomains; preload»;, то данные условия будут применимы ко всем доменам третьего и выше уровня вашего домена. Тут будте осторожны! Я изначально описал именно так, но так, как StartSsl выдаёт сертификаты на ограниченное количество поддоменов, я наткнулся на невозможность даже попасть на свои поддомены, которые обслуживают разнообразные админки, работали только те, на которые были выписаны trusted сертификаты. Поэтому я для себя выбрал первый вариант.
Далее — add_header Content-Security-Policy-Report-Only «default-src https:; script-src https: ‘unsafe-eval’ ‘unsafe-inline’; style-src https: ‘unsafe-inline’; img-src https: data:; font-src https: data:; report-uri /csp-report»; — я толком глубоко ещё не изучил свойства данного заголовка. Content Security Policy (CSP) — новый стандарт, определяющий HTTP-заголовки Content-Security-Policy и Content-Security-Policy-Report-Only, которые сообщают браузеру белый список хостов, с которых он может загружать различные ресурсы.
Временно я взял данную строку из статьи Яндекса про применение у них CSP, почитать подробно можно тут: http://www.html5rocks.com/en/tutorials/security/content-security-policy/.
Вот вроде-бы и всё. Несколько ссылкок, где можно проверить результаты своих и чужих трудов:
1. SPDY Check — это результат моего труда.
2. SSL Labs — проверка качества защиты вашего сервера.
Удачной защиты, коллеги!
Авторизация клиентов в nginx посредством SSL сертификатов / Хабр
Введение:
Потребовалось мне тут как-то написать небольшой API, в котором необходимо было помимо обычных запросов принимать запросы с «высокой степенью секретности».
Не я первый с этим столкнулся и мир давно уже использует для таких вещей SSL.
Поскольку на моём сервере используется nginx, то был установлен модуль SSL
Гугл не выдал ни одного работоспособного howto, но информация в сети есть по частям.
Итак, пошаговое руководство по настройке nginx на авторизацию клиентов через SSL-сертификаты.
Внимание! В статье для примера используются самоподписанные сертификаты!
Перед стартом создадим папку в конфиге nginx, где будут плоды наших трудов:
cd /path/to/nginx/config/
mkdir ssl && cd sslШаг 1. Создание собственного самоподписанного доверенного сертификата.
Собственный доверенный сертификат (Certificate Authority или CA) необходим для подписи клиентских сертификатов и для их проверки при авторизации клиента веб-сервером.
С помощью приведенной ниже команды создается закрытый ключ и самоподписанный сертификат.
openssl req -new -newkey rsa:1024 -nodes -keyout ca.key -x509 -days 500 -subj /C=RU/ST=Moscow/L=Moscow/O=Companyname/OU=User/CN=etc/[email protected] -out ca.crtОписание аргументов:
req Запрос на создание нового сертификата.
-new Создание запроса на сертификат (Certificate Signing Request – далее CSR).
-newkey rsa:1023 Автоматически будет создан новый закрытый RSA ключ длиной 1024 бита. Длину ключа можете настроить по своему усмотрению.
-nodes Не шифровать закрытый ключ.
-keyout ca.key Закрытый ключ сохранить в файл ca.key.
-x509 Вместо создания CSR (см. опцию -new) создать самоподписанный сертификат.
-days 500 Срок действия сертификата 500 дней. Размер периода действия можете настроить по своему усмотрению. Не рекомендуется вводить маленькие значения, так как этим сертификатом вы будете подписывать клиентские сертификаты.
-subj /C=RU/ST=Moscow/L=Moscow/O=Companyname/OU=User/CN=etc/[email protected]
Данные сертификата, пары параметр=значение, перечисляются через ‘/’. Символы в значении параметра могут быть «подсечены» с помощью обратного слэша «\», например «O=My\ Inc». Также можно взять значение аргумента в кавычки, например, -subj «/xx/xx/xx».
Шаг 2. Сертификат сервера
Создадим сертификат для nginx и запрос для него
openssl genrsa -des3 -out server.key 1024
openssl req -new -key server.key -out server.csrПодпишем сертификат нашей же собственной подписью
openssl x509 -req -days 365 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crtЧтобы nginx при перезагрузке не спрашивал пароль, сделаем для него беспарольную копию сертификата
openssl rsa -in server.key -out server.nopass.keyКонфиг nginx
listen *:443;
ssl on;
ssl_certificate /path/to/nginx/ssl/server.crt;
ssl_certificate_key /path/to/nginx/ssl/server.nopass.key;
ssl_client_certificate /path/to/nginx/ssl/ca.crt;
ssl_verify_client on;
keepalive_timeout 70;
fastcgi_param SSL_VERIFIED $ssl_client_verify;
fastcgi_param SSL_CLIENT_SERIAL $ssl_client_serial;
fastcgi_param SSL_CLIENT_CERT $ssl_client_cert;
fastcgi_param SSL_DN $ssl_client_s_dn;теперь сервер готов принимать запросы на https.
в переменных к бекенду появились переменные с информацией о сертификате, в первую очередь SSL_VERIFIED (принимает значение SUCCESS).
Однако если вы попытаетесь зайти на сайт, он выдаст ошибку:
400 Bad Request
No required SSL certificate was sentЧто ж, логично, в этом-то и вся соль!
Шаг 3. Создание клиентских сертификатов
3.1 Подготовка CA
Создадим конфиг
nano ca.config
со следующим содержимым:
[ ca ]
default_ca = CA_CLIENT # При подписи сертификатов # использовать секцию CA_CLIENT
[ CA_CLIENT ]
dir = ./db # Каталог для служебных файлов
certs = $dir/certs # Каталог для сертификатов
new_certs_dir = $dir/newcerts # Каталог для новых сертификатов
database = $dir/index.txt # Файл с базой данных подписанных сертификатов
serial = $dir/serial # Файл содержащий серийный номер сертификата (в шестнадцатеричном формате)
certificate = ./ca.crt # Файл сертификата CA
private_key = ./ca.key # Файл закрытого ключа CA
default_days = 365 # Срок действия подписываемого сертификата
default_crl_days = 7 # Срок действия CRL
default_md = md5 # Алгоритм подписи
policy = policy_anything # Название секции с описанием политики в отношении данных сертификата
[ policy_anything ]
countryName = optional # Поля optional - не обязательны, supplied - обязательны
stateOrProvinceName = optional
localityName = optional
organizationName = optional
organizationalUnitName = optional
commonName = optional
emailAddress = optionalДалее надо подготовить структуру каталогов и файлов, соответствующую описанной в конфигурационном файле
mkdir db
mkdir db/certs
mkdir db/newcerts
touch db/index.txt
echo "01" > db/serial3.2. Создание клиентского закрытого ключа и запроса на сертификат (CSR)
Для создания подписанного клиентского сертификата предварительно необходимо создать запрос на сертификат, для его последующей подписи. Аргументы команды полностью аналогичны аргументам использовавшимся при создании самоподписанного доверенного сертификата, но отсутствует параметр -x509.
openssl req -new -newkey rsa:1024 -nodes -keyout client01.key -subj /C=RU/ST=Moscow/L=Moscow/O=Companyname/OU=User/CN=etc/[email protected] -out client01.csrВ результате выполнения команды появятся два файла client01.key и client01.csr.
3.3. Подпись запроса на сертификат (CSR) с помощью доверенного сертификата (CA).
При подписи запроса используются параметры заданные в файле ca.config
openssl ca -config ca.config -in client01.csr -out client01.crt -batchВ результате выполнения команды появится файл клиентского сертификата client01.crt.
Для создания следующих сертификатов нужно повторять эти два шага.
3.4. Создание сертификата в формате PKCS#12 для браузера клиента
Это на тот случай, если к вашему серверу подключаются не бездушные машины, как в моём случае, а живые люди через браузер.
Запароленный файл PKCS#12 надо скормить браузеру, чтобы он смог посещать ваш сайт.
openssl pkcs12 -export -in client01.crt -inkey client01.key -certfile ca.crt -out client01.p12 -passout pass:q1w2e33.5 Подключение к полученному ssl cерверу с помощью curl
curl -k --key client.key --cert client1.crt --url "https://site.com"Использована опция -k, потому что сертификат в примере самоподписанный
Использованное ПО
Ubuntu Server 10.10 (Linux 2.6.35-22-server #35-Ubuntu SMP x86_64 GNU/Linux)
nginx 0.9.3
OpenSSL 0.9.8o 01 Jun 2010
Полезные ссылки
Надеюсь, был кому-то полезен.
P.S. Этот пост был моей первой публикацией 16 января 2011 года, старая копия удалена (по желанию администрации сайта и потому, что она не была привязана к моему аккаунту).
Настольное приложениеHTTPS Checker | Проверка HTTPS
Что проверяет приложение?
- Активное смешанное содержимое
- Пассивное смешанное содержание
- Отправка небезопасных форм
- Небезопасные страницы, запрашивающие пароли или данные кредитной карты (предупреждение Chrome «Небезопасно»)
- Небезопасные перенаправления внутри сайта
- Канонические ссылки на страницы без HTTPS
- Несогласованные ссылки с HTTPS на URL-адреса HTTP на вашем сайте
- Социальные ссылки на страницы без HTTPS
- Карта сайта содержит ссылки HTTP
- Проверить наличие современных заголовков безопасности
- Действительный SSL-сертификат
- Срок действия SSL-сертификата не истек
- Мы также будем добавлять дополнительные функции в будущем, которые будут автоматически доступны через нашу систему обновлений
Будет ли HTTPS Checker работать на моем компьютере?
Загружаемое приложение работает на 64-разрядных машинах под управлением Mac OSX 10 как минимум.8 или Windows 7. Большинство машин, приобретенных за последние 3-5 лет, будут работать с 64-разрядной версией. Если сомневаетесь, просто попробуйте бесплатную версию.
Могу ли я доверять этому приложению: оно не содержит вирусов?
Да, Wildfire Internet — это установленный британский бизнес-трейдер с 2008 года, который зарегистрирован в Программе разработчиков Apple и использует аутентифицированные сертификаты подписи кода Digicert.
Могу ли я сканировать ЛЮБОЙ веб-сайт?
Приложение обычно может сканировать веб-сайты, которые придерживаются передовых методов работы с пауками поисковых систем.Обратите внимание, что некоторые сайты блокируют пауков и, следовательно, мешают работе приложения. Совет: вы можете переключить User Agent на настольный или мобильный браузер и попробовать еще раз. Файлы robots.txt также можно настроить так, чтобы блокировать доступ к определенным частям веб-сайта, однако вы можете игнорировать это в дополнительных настройках, чтобы обеспечить доступ ко всем страницам.
Сколько страниц вы сканируете?
Это зависит от приобретенной лицензии. Мы начинаем с 500 страниц бесплатно и до 250 000 страниц в загружаемом приложении.Мы можем найти несколько проблем на странице, поэтому мы ограничиваем найденные проблемы. По умолчанию установлено ограничение в 50 000 проблем, после чего мы останавливаем сканирование, чтобы вы могли изучить и решить эти проблемы, а затем повторно запустить отчет. Вы можете изменить это на более или менее проблемы с помощью дополнительных настроек. Если у вас более 250 000 страниц, свяжитесь с нами, чтобы обсудить, как мы можем удовлетворить ваши требования, по телефону 0845 643 1290
.Могу ли я сканировать ВСЕ материалы на веб-сайте?
Нет абсолютной гарантии, что мы сможем сканировать все, поскольку могут быть проблемы, которые не позволяют нам получить доступ к страницам, такие как проблемы с тайм-аутом или ресурсы, глубоко встроенные в код, который изменяет содержимое, например, интенсивное использование AJAX.Мы рекомендуем использовать HTTPS Reporter для сбора данных обо всех нарушениях после запуска HTTPS Checker, так как это удалит все области, недоступные для приложения.
Сколько времени занимает сканирование?
Это зависит от того, сколько у вас страниц, характеристик вашего локального компьютера и скорости интернет-соединения. Наши тесты позволяют сканировать около 5000 страниц в час. Мы отображаем количество просканированных страниц, и вы можете остановить сканирование в любой момент.
Могу ли я ускорить сканирование?
Помимо работы на более быстром оборудовании, есть возможность запускать только «Проверки смешанного содержимого», которые могут помочь.
Могу ли я запускать приложение на определенных частях веб-сайта, а не на других?
Да, вы можете ввести URL-адрес в качестве отправной точки для сканирования, например https://www.mydomain.com/blog. Вы также можете использовать «Дополнительные правила стиля robots.txt», чтобы запретить сканирование определенных частей сайта с использованием стандартного синтаксиса robots.txt.
Могу ли я сканировать страницы, для просмотра которых необходимо войти в систему, включая области администратора?
Да, используя «Сканирование сеанса при входе в систему» и следуя инструкциям.ВАЖНО: разрешение пауку сканировать ссылки на странице администратора означает, что он будет выполнять все действия, связанные с этой ссылкой, например Изменить пароль, добавить пользователя, удалить учетную запись и т. Д. Перед тем, как запустить это, убедитесь, что у вас есть проверенная резервная копия вашего сайта или запускайте ее в отдельной тестовой версии и правильно ввели правила в «Дополнительные правила стиля файла Robots.txt» «поле для предотвращения удаления или изменения данных. ПРИМЕЧАНИЕ. Мы не несем ответственности за любой ущерб, причиненный запуском этой программы.
Как лучше всего использовать это на большом сайте?
Доказано, что приложение выполняет непрерывное сканирование 250 000 страниц на отдельном сайте, однако вы сталкиваетесь с ограничением, когда возникает множество десятков или даже сотен тысяч проблем. Они хранятся в локальной памяти компьютера (так что у вас есть потенциальные физические ограничения), плюс файл отчета будет настолько большим, что вы не сможете его открыть. Вот почему существует расширенная настройка, ограничивающая количество обнаруженных проблем.Большие сайты, то есть 100 000 страниц, обычно делятся на разделы, такие как: / blog, / news, / products и т. Д. Рекомендуется запускать приложение в каждом разделе по очереди, вводя начальный URL для каждого раздела, например. https://www.mydomain.com/blog и установите реалистичные ограничения «Ограничение количества проблем» и «Ограничение страницы» в дополнительных настройках. Тогда домашнюю страницу можно будет запустить как отдельную страницу.
Как часто следует запускать проверку HTTPS?
Изначально запустите его как часть процесса перед миграцией при переходе с HTTP на HTTPS, чтобы определить, что необходимо изменить.Как только вы перейдете на HTTPS, запустите его, чтобы убедиться, что все в порядке. Мы рекомендуем запускать это регулярно в рамках процессов администрирования веб-безопасности, чтобы быть уверенным в том, что все остается в порядке, например, после добавления нового контента, импорта, изменений дизайна и т. Д. В качестве альтернативы можно использовать HTTPS Reporter для обнаружения нарушений CSP в реальном времени. время.
Полезные ссылки
,5 примеров плагинов Nagios check_http для HTTP / HTTPS
Что такое check_http?
5 примеров check_http
Синтаксис и параметры
Связанные команды
Что такое check_http?
Плагин check_http используется для проверки статуса HTTP-сервера (или HTTPS), который работает на удаленном хосте. Если вы установили Nagios из исходного кода, команда check_httpd будет расположена в каталоге / usr / local / nagios / libexec.
5 Примеры команд check_http
1.Проверить HTTP
Проверьте, работает ли Apache HTTP на удаленном сервере, используя check_http.
$ check_http -H 192.168.1.50 HTTP OK HTTP / 1.1 200 OK - 332 байта за 0,004 секунды | время = 0,004144 с ;;; 0,000000 размер = 332 Б ;;; 0
2. Проверьте HTTPS
Проверьте, работает ли Apache HTTPS на удаленном сервере, используя check_http.
$ check_http -H 192.168.1.50 -S HTTP OK HTTP / 1.1 200 OK - 332 байта за 0,004 секунды | время = 0,004144 с ;;; 0,000000 размер = 332 Б ;;; 0
Если удаленный сервер использует только HTTP, а не HTTPS, вы получите сообщение «HTTP CRITICAL — Невозможно открыть сокет TCP», как показано ниже.
$ check_http -H 192.168.1.50 -S В соединении отказано HTTP CRITICAL - невозможно открыть сокет TCP
3. Проверьте HTTP (или HTTPS) на другом порту
Вы можете проверить сервер Tomcat, сервер Apache, Glassfish или любой сервер, работающий на другом порту, указав номер порта, как показано ниже.
$ check_http -H 192.168.1.50 -p 8080 HTTP OK HTTP / 1.1 200 OK - 332 байта за 0,004 секунды | время = 0,004144 с ;;; 0,000000 размер = 332 Б ;;; 0
Если HTTPS работает на другом порту, сделайте следующее.
$ check_http -H 192.168.1.50 -S -p 8443 HTTP OK HTTP / 1.1 200 OK - 332 байта за 0,004 секунды | время = 0,004144 с ;;; 0,000000 размер = 332 Б ;;; 0
4. Проверить конкретный URL
Чтобы проверить, доступна ли конкретная веб-страница, используйте параметр -u, как показано ниже.
$ check_http -H 101hacks.com -u https://linux.101hacks.com/toc
5. Проверьте срок действия сертификата SSL
Вы можете проверить, истекает ли срок действия SSL-сертификата веб-сайта в течение следующих X дней, как показано ниже.В следующем примере мы проверяем, истекает ли срок действия сертификата веб-сайта в ближайшие 365 дней. В выводе указано, что срок его действия истекает через 300 дней.
$ check_http -H 101hacks.com -C 365 ВНИМАНИЕ! Срок действия сертификата истекает через 300 дней (01.01.2011 10:10).
Синтаксис и параметры
check_http -H имя хоста (или) -I ip-адрес {дополнительные параметры}
| Короткий вариант | Длинный вариант | Опция Описание |
|---|---|---|
| -H | –hostname | имя хоста сервера, на котором запущен демон HTTP (или HTTPS) |
| -I | –IP-адрес | IP-адрес HTTP (или HTTPS) сервера |
| -p | – порт | Номер порта, на котором работает HTTP-сервер.По умолчанию 80 |
| -4 | –use-ipv4 | Будет использоваться соединение IPv4 |
| -6 | –use-ipv6 | Будет использоваться соединение IPv6 |
| -S | –ssl | Это будет использовать HTTPS с использованием порта 443 по умолчанию |
| -C | –сертификат | Минимальное количество дней, в течение которых сертификат SSL должен быть действительным. |
| -e | – ожидать | Ожидаемая строка ответа.По умолчанию HTTP / 1 |
| -с | — струна | Ожидаемая строка содержимого. |
| -u | –url | URL для проверки |
| -П | — столб | URL-кодированные данные HTTP POST |
| -N | — без кузова | Не ждать, пока загрузится весь документ. Остановитесь, как только заголовки будут загружены. |
| -М | –максимальный возраст | Проверить, не старше ли документ x секунд.Используйте 5 в течение 5 секунд, 5 минут в течение 5 минут, 5 часов в течение 5 часов, 5 дней в течение 5 дней. |
| -T | — тип содержимого | Укажите тип содержимого в заголовке для запроса POST |
| -l | — размах | Регулярное выражение может охватывать новую строку (используйте это с параметром -r или -R) |
| -r | –regex, –ereg | Используйте это регулярное выражение для поиска строки на странице HTTP |
| -R | –eregi | То же, что и выше, но без учета регистра. |
| -a | – авторизация | Если базовая аутентификация пользователя сайта отправляет uid, pwd в формате uid: pwd |
| -A | –пользователь | Передайте указанную строку как «Пользовательский агент» в заголовке HTTP. |
| -к | –заголовок | Добавьте дополнительные теги, которые должны быть отправлены в заголовке HTTP. |
| -L | — ссылка | Вывод упакован как HTML-ссылка |
| -f | –onredirect | Когда URL-адрес перенаправлен, используйте это либо для перехода по URL-адресу, либо для отправки ОК, предупреждения или критического уведомления |
| -м | –размер страницы | Укажите минимальный и максимальный размер страницы в байтах.Формат минимум: максимум |
| -w | – предупреждение | Время отклика в секундах на предупреждение |
| -м | –размер страницы | Укажите минимальный и максимальный размер страницы в байтах. Формат минимум: максимум |
| -w | – предупреждение | Время отклика в секундах на предупреждение |
| -c | –критический | Время отклика в секундах для критического состояния |
| -т | — тайм-аут | Количество секунд ожидания до истечения времени ожидания соединения.По умолчанию 10 секунд |
Связанные команды
check_ping
check_ftp
| ||||||||||||
Port Checker — Тест переадресации портов
Port Checker — это онлайн-инструмент, который проверяет доступность удаленного компьютера или устройства из Интернета.
Его можно использовать для проверки открытых портов или Ping порта на удаленном сервере. TCP Port Checker пытается установить соединение
с нашего сервера, и если соединение будет успешным, вы сможете его увидеть. Вы не можете использовать этот инструмент для проверки локальных портов на вашем компьютере.
Когда возможно тестирование открытого порта?
Проверка открытого порта возможна только в том случае, если ваш компьютер доступен по внешнему / общедоступному IP-адресу. Стоит учесть, что если ваш компьютер подключен к Интернету через роутер, результаты теста точно соответствуют роутеру. Проверка статуса порта для компьютера внутри подсети возможна только с переадресацией портов.
Также обратите внимание, что если вы тестируете открытый порт для своего локального IP-адреса, т.е. если ваш IP-адрес похож на 192.168.1.xxx, вы пытаетесь проверьте открытый порт на внутреннем IP, и он не будет работать. Если вы не уверены в IP-адресе и порте, прочитайте больше о [Перенаправление портов в Википедии]
Что такое переадресация портов?
Port Forwarding — это своего рода специальная конфигурация на маршрутизаторе, которая позволяет перенаправлять внешние запросы (из Интернета) на компьютеры или другие устройства на локальном компьютере. сеть.Фактически, это способ указать, с какого локального компьютера будут отправляться запросы на данные и соединение, которые поступают на определенный порт маршрутизатора. У нас есть три разных способа сделать это:
- Faux-DMZ : DMZ означает демилитаризованную зону, которая представляет собой своего рода конфигурацию сетевой безопасности, в которой все входящие запросы отправляются на определенный компьютер в сети.
- Перенаправление портов :
- Перенаправление портов UPnP : аналогично перенаправлению портов, но в этом случае настройка перенаправления выполняется компьютерным программным обеспечением, которое проживающие в Сети.Очень распространенный пример сценария — настройка переадресации портов UPnP, выполняемая Skype. Skype конференц-звонок на самом деле выполняется таким образом.
Допустим, у вас есть домашняя игра или веб-сервер, подключенный к Интернету через маршрутизатор. Все компьютеры, подключенные к одному маршрутизатору, находятся в одной сети, поэтому могут подключаться к серверу. Однако за пределами Интернета подключиться к вашему серверу без переадресации портов не получится.Если ваш компьютер подключен к Интернету напрямую (без маршрутизатора / маршрутизатора), то требуется перенаправление портов. Все ваши открытые порты должны быть доступны из Интернета (конечно, если у вас есть выделенный IP-адрес).
Как проверить мой брандмауэр
Если вы настроили узел DMZ и хотите проверить, работает ли ваш брандмауэр или нет, это можно проверить с помощью инструмента проверки портов.Используйте свой общедоступный IP-адрес и проверьте порты, которые вы настроили для блокировки от вашего брандмауэра.
Что такое порты? Для чего они нужны?
Переносит этот виртуальный адрес на ваш компьютер или сетевое устройство, что позволяет ему связываться с другим компьютером или устройствами. Если программа или сервис планируют работу с сетью, она открывает порт с уникальным номером, через который может работать с удаленными клиентами / серверами.На человеческом языке это будет звучать примерно так: «Я, программа-сервер, открываю порт 1234. Если на сетевом кабеле будет порт данных с номером 1234 — то мне».
Какие номера портов можно открыть?
Порты обозначаются номерами от 0 до 65 535 включительно. Любой другой порт открыть, соответственно и проверить тоже нельзя. Это ограничение протокола TCP / IP. Стоит отметить, что клиентская программа всегда должна знать порт, к которому ей необходимо подключиться к удаленному серверу или другому сетевому устройству.По этой причине в наиболее популярных протоколах зарезервированы порты в диапазоне от 0 до 1023. Например, во время серфинга в Интернете ваш браузер подключается к порту 80 на удаленном сервере, на котором размещен сайт. В ответ браузер получает набор данных и кода, который загружает и отображает веб-страницу.
Если вы не уверены в номерах портов, выполните поиск номеров портов в стандартной базе данных.
Как закрыть открытый порт?
В первую очередь необходимо устранить причину — запущенная программа или служба, открывшая порт; надо закрыть / остановить.Если причина открытого порта не ясна — антивирус просканирует ваш компьютер, удалите дополнительные правила переадресации портов на маршрутизаторе и установите расширенный брандмауэр (Firewall).
Часто используемые порты
| Протокол | Порт | Описание |
|---|---|---|
| FTP | 21 | Протокол передачи файлов — Протокол передачи файлов. Порт для команд. |
| SSH | 22 | Secure SHell — «безопасная оболочка».Операционная система протокола удаленного управления. |
| Telnet | 23 | Терминальная сеть. Реализация протокола текстового интерфейса по сети. |
| SMTP | 25 | Simple Mail Transfer Protocol — простой протокол передачи почты. |
| WHOIS | 43 | «Кто есть». Протокол получения регистрации права собственности на доменные имена и IP-адреса |
| DNS | 53 | Domain Name System — Система доменных имен. |
| DHCP | 67 | Протокол динамической конфигурации хоста — Протокол динамической конфигурации хоста. Динамический IP |
| TFTP | 69 | Trivial File Transfer Protocol — простой протокол передачи файлов. |
| HTTP / Web | 80 | HyperText Transfer Protocol — протокол передачи гипертекста. |
| POP3 | 110 | Post Office Protocol Version 3 — протокол приема электронной почты, версия 3 |
| SFTP | 115 | SSH File Transfer Protocol.Протокол безопасной передачи данных. |
| IMAP | 143 | Протокол доступа к сообщениям Интернета. Протокол прикладного уровня для доступа к электронной почте. |
| SNMP | 161 | Простой протокол сетевого управления — Простой протокол сетевого управления. Управление устройством. |
| HTTPS | 443 | HyperText Transfer Protocol Secure) — протокол HTTP, поддерживающий шифрование. |
| LPD | 515 | Line Printer Daemon.Протокол удаленной печати на принтере. |
| IMAP SSL | 993 | Протокол IMAP, поддерживает шифрование SSL. |
| POP3 SSL | 995 | Протокол POP3 поддерживает шифрование SSL. |
| НОСКИ | 1080 | SOCKet Secure. Протокол приема безопасного анонимного доступа. |
| Прокси | 3128 | В настоящее время в порту часто используются прокси. |
| MySql | 3306 | База данных Mysql |
| RDP | 3389 | Протокол удаленного рабочего стола — удаленный рабочий стол для Windows. |
| PostgreSql | 5432 | База данных Postgres |
| VNC | 5900 | Virtual Network Computing — система удаленного доступа к настольному компьютеру. |
| TeamViewer | 5938 | TeamViewer — Система удаленного управления для обеспечения вашего компьютера и обмена данными. |
| HTTP / Web | 8080 | Альтернативный порт для протокола HTTP. Иногда использовали прокси. |
Могу ли я проверить заблокированные порты с помощью инструмента проверки портов?
Да, вы можете проверить наличие открытых и заблокированных портов на компьютере или сервере. При тестировании определенного порта, если результат возвращается как «Закрыто» означает, что конкретный порт заблокирован или недоступен.
Команда для проверки открытого порта на вашем компьютере
Если вы используете машину Windows или Linux, вы можете легко найти открытые порты или порты, которые используются, используя следующие команды:
Windows: Пуск → «cmd» → Запуск от имени администратора → «netstat -bn»,
Linux: a В терминале выполните команду: «ss -tln»