По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Представьте ситуацию, пользователи пытаются получить доступ к вашему сайту, но он не открывается. Знаете в чём дело? Возможно, есть ошибки, которые не были выявлены и решены раньше. Разочарованные пользователи покидают ваш сайт, а вы теряете лояльных пользователей.
Как решить эту проблему? Как узнать о состоянии сайта раньше пользователей?
Существует два возможных способа - eсли вы не против потратить немного денег, то можно обратиться к таким мониторинговым решениям, как StartCake и т.п. Однако если вы разработчик или не готовы тратиться ежемесячно, можете воспользоваться преимуществами API Geekflare - Site Up?
Данный API проверяет доступность сайта из разных точек.
В данном материале рассмотрим Python код, который немедленно уведомит вас через Gmail, как только сайт станет недоступен. Начнем с изучения API «Is Site Up?»
API Is Site Up?
Перед началом работы с API необходимо установить пакет requests, который в Python используется для работы с API. Но не обязательно использовать Python. Можно использовать любой другой язык. В любом случае, убедитесь, что настроили все необходимое, чтобы сделать API запрос.
Итак, для тех, кто использует Python, установите пакет запросов с помощью команды:
pip install requests
Выполните настройку для других языков (если выбран другой язык, кроме Python) и переходите к следующим шагам.
Теперь перейдите на страницу API Geekflare.
Вы можете найти различные типы API, включая «Is Site Up?». Для использования API Geekflare нам нужен ключ API, который мы можем получить через RapidAPI.
Нажмите на кнопку GET API KEY, чтобы перейти к RapidAPI.
RapidAPI откроется в новой вкладке и выглядит следующим образом:
Чтобы получить ключ API нужно создать учетную запись. Создайте учетную запись в RapidAPI, если у вас ее нет.
Затем в верхней части всех доступных API Geekflare вы увидите API «Is Site Up?», который мы ищем. Если он не активен, найдите его с помощью поиска и нажмите на него. После этого в правой стороне должно отобразиться руководство по данному API. Из раздела Code Snippets в правой части выберите Python -> Requests.
Или же если вы не используете Python, выберите другой язык с соответствующим пакетом.
Вы получите код для вызова API «Is Site Up?». Давайте изменим его немного, чтобы потом легче было добавлять код. Посмотрите на измененный код в Python.
import requests
API_URL = "https://geekflare.p.rapidapi.com/up"
def make_api_request():
headers = {
'content-type': "application/json",
'x-rapidapi-host': "geekflare.p.rapidapi.com",
'x-rapidapi-key': "YOUR_API_KEY"
}
payload = r'{"url": "https://www.geekflare.com"}'
response = requests.request("POST", API_URL, data=payload, headers=headers)
return response.json()
if __name__ == '__main__':
data = make_api_request()
print(data)
Замените API_KEY своим собственным ключом API из RapidAPI в приведенном выше коде. Он будет разным для каждого пользователя. Вы найдете его в RapidAPI в разделе Параметры заголовка:
Тот же ключ API вы сможете найти в примере кода, как показано ниже.
Несколько расположений
В приведенном выше коде сайт проверяется из одного датацентра (Нью-Йорк, США). Но мы можем посылать запросы на сайт из разных мест с указав буквенные коды стран в теле запроса. Другие доступные места - Англия (Лондон) и Сингапур. Мы можем передать данные местоположения вместе с URL-адресом сайта следующим образом:
{
"locations": [
"uk",
"us",
"sg"
],
"url": "geekflare.com"
}
Вы можете передать предпочитаемые расположения из списка.
Мы написали код, чтобы сделать запрос API, который получает данные независимо от того, работает сайт или нет. Пришло время написать еще код, который отправляет почту, когда сайт не работает.
Получение уведомления на почту
В сети можно найти немало руководств о том, как отправлять электронные письма через Gmail в Python или же использовать следующий код, который использует пакет под названием yagmail специально разработан для отправки почты из Gmail.
Перед отправкой сообщения через учетную запись Gmail необходимо включить параметр Разрешить небезопасные приложения. Вы можете включить его здесь. Посмотрим код:
def send_mail():
gmail = yagmail.SMTP("gmail", "password")
receiver = "receiver@domain.com"
subject = "Testing Subject"
body = "This is a testing mail"
gmail.send(
to=receiver,
subject=subject,
contents=body,
)
Полное руководство по yagmail можно найти здесь.
Теперь у нас есть код для запросов API и отправки почты. Следующим шагом является вызов send_mail всякий раз, когда в ответе на запрос сайт указывается как недостпный.
Итак, откуда мы знаем, что наш сайт не работает или работает? Когда мы посылаем запрос к API «Is Site Up?», он возвращает нам Python словарь с некоторыми данными как следующем скриншоте:
В данном словаре есть ключ message. Значение этого ключа и показывает нам состояние сайта. Данный ключ может иметь два значения:
Site is up
Site is down
Итак, мы отправим почту, когда получим сообщение «Site is down». Окончательный код будет выглядеть так:
import requests
import yagmail
API_URL = "https://geekflare.p.rapidapi.com/up"
def make_api_request():
headers = {
'content-type': "application/json",
'x-rapidapi-host': "geekflare.p.rapidapi.com",
'x-rapidapi-key': "API_KEY"
}
payload = r'{"url": "https://www.abcd.com"}'
response = requests.request("POST", API_URL, data=payload, headers=headers)
return response.json()
def send_mail(content):
gmail = yagmail.SMTP("gmail", "password")
receiver = "email@domain.com"
subject = "Your Site is Down"
gmail.send(
to=receiver,
subject=subject,
contents=content,
)
if __name__ == '__main__':
data = make_api_request()
message = data['message']
## seding the mail
if message == 'Site is down.':
## extracting the errors from different locations
locations_data = data['data']
mail_content = "Your site is down due to unexpected error. See the useful data to resolve errors below.
"
for location in locations_data:
mail_content += f"{location['city']}, {location['country']} - {location['error']}
"
mail_content += "
Check the error and resolve them as soon as possible."
send_mail(mail_content)
Тело сообщения можете редактировать по своему усмотрению. Мы завершили код отправки почты всякий раз, когда наш сайт не работает. Смотри образец сообщения, полученного с помощью вышеуказанного кода.
Но, есть еще проблема.
Мы должны выполнить наш код, чтобы проверить, работает ли наш сайт или нет. Частота запуска данного скрипта зависит от ваших предпочтений. Допустим, мы должны проверять сайт каждые час.
Правда, мы можем каждый час открыть терминал и запустить скрипт. Но это скучно и неэффективно. Плюс к этому, никто так не делает. Решение напрашивается само: использовать cron для автоматического выполнения нашего кода каждый час. Посмотрим, как его настроить.
Настройка Cron
Рассмотрим шаги по настройке cron в операционной системе на базе UNIX.
Открыть терминал.
Выполните команду crontab -e, которая открывает файл crontab на терминале.
Нажмите клавишу i для перехода в режим ВВОДА.
Теперь добавьте шаблон cron, пути к исполняемому файлу Python и нашему файлу, как указано ниже:
0 * * * * /usr/bin/python3 /home/sample.py
Подробно про cron можно прочесть в этой статье.
Итак, мы настроили планировщик для ежечасного запуска кода. Если нужно будет указать другое расписание, можно воспользоваться разными утилитами для генерации шаблона расписания для cron.
Пожалуй, теперь все. Мы настроили проверку сайта каждый час и получение уведомления на почту, если сайт станет недоступен.
Заключение
Автоматизация экономит много времени и работает на нас. Можно настроить cron на каком-нибудь облаке, чтобы он постоянно работал, проверял состояние сайта и уведомлял нас при сбое.
Подход DevSecOps с частым систематическим сканированием приложений на наличие уязвимостей значительно увеличивает процент программного обеспечения с исправленными уязвимостями и сокращает время, необходимое для выпуска исправлений, что особенно важно в контексте критических ошибок. Согласно Veracode State of Software Security Vol. 10, по сравнению с 2018 годом процент уязвимых приложений увеличился в 2019 году с 52 до 56%. С другой стороны, в случае приложений, сканируемых один раз в месяц или реже, среднее время обновления составляло 68 дней, в то время как приложения, сканируемые не реже одного раза в день, имели в среднем 19 дней для обновления.
Эти результаты, а также выводы исследования Enterprise Strategy Group подтверждают, насколько сегодня важно последовательно и как можно раньше расширять процесс разработки приложений до стадии тестирования безопасности. В прошлом эта задача входила в обязанности отдела безопасности и выполнялась после завершения программирования. Сегодня сами разработчики также должны продемонстрировать соответствующие компетенции.
Новые модели и способы доставки программного обеспечения - общедоступное облако, контейнеры и микросервисы - положили конец большим выпускам приложений и редким обновлениям. Вместо них у нас есть молниеносные циклы публикации, а приложения разделены на более мелкие, независимо работающие модули. В результате программное обеспечение просто создается слишком быстро, и новые версии приложения, так называемые выпуски могут идти "в производство" в оптовых количествах даже на один день, чтобы проверка безопасности по методологии WaterFall была эффективной. Ситуация дополнительно осложняется тем фактом, что конечный продукт, то есть приложение с определенной функциональностью, содержит как код, созданный внутри компании, так и элементы, заимствованные из открытых бесплатных репозиториев или через менеджеры пакетов).
Следовательно, функционирование разработки, операций и безопасности как отдельных организационных структур не существует и не может существовать. Разработчикам следует понимать, что поддержка и защита программного обеспечения также зависят от них.
Умение настраивать VLAN (Virtual Local Area Network) или виртуальные локальные сети - одно из самых базовых умений, которым должен обладать системный администратор. Сегментирование сети с помощью VLAN-ов строго необходимо для PCI, HIPAA и прочих стандартов безопасности, и, кроме того, это помогает сохранять “чистоту” и порядок в больших сетях. Настройка VLAN-ов на маршрутизаторах MikroTik не является сложной задачей, подробнее о шагах настройки вы можете прочесть ниже.
Дизайн VLAN в организации
Первым шагом в сегментировании сети должен быть не настройка маршрутизатора, а понимание будущей схемы в целом - предпочтительно нарисовать схему на листе бумаги, использовать ПО наподобие Microsoft Visio и т.д. К тому же, если ваша сеть должна соответствовать стандартам безопасности, которые были перечислены выше, то практически не нужно ничего придумывать - в описании стандартов есть подробные инструкции что и как должно быть сегментировано. Однако, чаще всего, сегментирование происходит для общей оптимизации сети - и тут необходимо будет что-то придумать самому. На наш взгляд, проще всего отразить структуру организации в схеме VLAN-ов. Каждый департамент должен находится в собственном VLAN-е, т.к каждый департамент обладает своими собственными уникальными функциями, и, скорее всего, различными правами доступа. Также в отдельные VLAN-ы необходимо поместить сервера и дисковые хранилища.
Для серверов и хранилищ рекомендуется использовать отдельные коммутаторы, но, для маленьких компаний это часто невозможно из-за лимитированного бюджета.
К тому же, с помощью таких инструментов как Torch или NetFlow можно будет контролировать и мониторить трафик каждого департамента. Гостевая сеть также должна быть помещена в отдельный VLAN, который будет полностью изолирован от внутренней сети. Беспроводные сети также должны находится в своем VLAN, таким образом весь трафик мессенджеров, обновлений мобильных приложений и т.д будет полностью отделен от основной сети.
Транковые протоколы VLAN
В нашем сценарии у нас есть только один роутер, и создадим VLAN-ы для HR (192.168.105.0/24), бухгалтерии (192.168.155.0/24) и гостевую сеть (192.168.1.175.0/24). Если у вас получится создать три VLAN-а, то, очевидно, получится создать и сто - в нашем примере мы описываем создание только трех VLAN-ов для простоты и прозрачности примера. IP-адреса для каждого VLAN-а также были выбраны случайным образом - для вашей организации, скорее всего, адресация будет иной. В нашем случае, маршрутизатор подключен к коммутатору по интерфейсу ether2, с 802.1q транком между ними - эта схема также известна под именем “роутер на палке” (router on a stick). Мы не будем углубляться в детали касаемо свитча - это может быть Cisco, HP и т.д - потому что 802.1q транки одинаковы практически на всех платформах - если у вас какой-нибудь необычный свитч, то вам стоит просто обратиться к документации и прочесть, как выполняется конфигурация транкового порта. Наш маршрутизатор также обладает подключением к WAN на порту ether1 - все пользователи в VLAN-ах будут использовать его для доступа к интернету.
Создание VLAN-ов на MikroTik
Сперва необходимо создать VLAN-ы на маршрутизаторе и назначить их на интерфейс ether2. После этого, интерфейс ether2 будет автоматически настроен как 802.1q транк и не будет доступен для трафика без тэгов, что означает, что до конца настройки этот линк будет “лежать” - поэтому строго рекомендуется выполнять эти действия во в нерабочее время.
/interface vlan
add comment="HR" interface=ether2 name="VLAN 105 - HR" vlan-id=105
add comment="Accounting" interface=ether2 name="VLAN 155 - Accounting" vlan-id=155
add comment="Guests" interface=ether2 name="VLAN 180 - Guests" vlan-id=180
Крайне рекомендуется всегда давать понятные имена интерфейсам и писать комментарии - в дальнейшем это может сильно облегчить администрирование сети и обучение новых системных администраторов. Как мы упомянули выше, создание VLAN-ов и назначение их на физический порт ether2 автоматически изменит тип инкапсуляции на 802.1q, но вы нигде этого не увидите - даже если выведете всю информацию об интерфейсе.
Назначаем IP-адреса
Далее, необходимо назначить сетевые адреса, чтобы VLAN интерфейсы могли работать как шлюзы:
/ip address
add address=192.168.105.1/24 comment="HR Gateway" interface="VLAN 105 - HR"
add address=192.168.155.1/24 comment="Accounting Gateway" interface="VLAN 155 - Accounting"
add address=192.168.180.1/24 comment="Guests Gateway" interface="VLAN 180 - Guests"
На всякий случай, еще раз обращу ваше внимание на то, как важно комментировать интерфейсы для удобства в дальнейшем. На данном моменте у нас уже настроены VLAN-ы и у них назначены сетевые адреса. Если у вас не используется DHCP, а используется статическая адресация - на этом настройка VLAN в общем-то закончена. Следующим шагом (этот шаг, соответственно, опционален) является настройка DHCP на VLAN интерфейсах, для того чтобы клиенты внутри каждого VLAN могли автоматически получить динамический IP-адрес.
DHCP для VLAN
Для начала, необходимо установить адресные пулы для каждого из VLAN-ов:
/ip pool
add name=HR ranges=192.168.105.2-192.168.105.254
add name=Accounting ranges=192.168.155.2-192.168.155.254
add name=Guests ranges=192.168.180.2-192.168.180.254
Далее, настраиваем DHCP с опциями для DNS и шлюзов:
/ip dhcp-server network
add address=192.168.105.0/24 comment="HR Network" dns-server=8.8.8.8,8.8.4.4 gateway=192.168.105.1
add address=192.168.155.0/24 comment="Accounting Network" dns-server=8.8.8.8,8.8.4.4 gateway=192.168.155.1
add address=192.168.180.0/24 comment="Guest Network" dns-server=8.8.8.8,8.8.4.4 gateway=192.168.180.1
В данном случае мы используем DNS сервис от Google.
Далее, добавляем ранее настроенные пулы на VLAN интерфейсы:
/ip dhcp-server
add address-pool=HR disabled=no interface="VLAN 105 - HR" name=HR
add address-pool=Accounting disabled=no interface="VLAN 155 - Accounting" name=Accounting
add address-pool=Guests disabled=no interface="VLAN 180 - Guests" name=Guests
Адресные пулы соответствуют настроенным сетям, и именно такие DHCP опции как шлюз и DNS присваиваются конкретной DHCP инстанции. Смысл присвоения DHCP для каждого VLAN в том, чтобы у вас была возможность контролировать сроки выдачи адреса (lease times), опции и т.д для каждого сегмента сети, что дает большой простор для оптимизации и контроля DHCP в вашей организации.
Настройка VLAN на коммутаторе
На данном этапе настройки вам необходимо будет назначить порты доступа на ваших свитчах на конкретные VLAN-ы, и клиенты, которые будут подключены к этим портам будут находится в их VLAN и получать соответствующие IP-адреса по DHCP. Теперь уже вам решать, какие VLAN будут полностью изолированы друг от друга, а какие смогут “общаться” - осталось только настроить соответствующие правила на фаерволле. Как правило, мы разрешаем доступ только абсолютно необходимого трафика в VLAN - если разрешить весь трафик, тогда теряется смысл сегментирования.