По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Представьте ситуацию, пользователи пытаются получить доступ к вашему сайту, но он не открывается. Знаете в чём дело? Возможно, есть ошибки, которые не были выявлены и решены раньше. Разочарованные пользователи покидают ваш сайт, а вы теряете лояльных пользователей.
Как решить эту проблему? Как узнать о состоянии сайта раньше пользователей?
Существует два возможных способа - 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 на каком-нибудь облаке, чтобы он постоянно работал, проверял состояние сайта и уведомлял нас при сбое.
Одиннадцатая часть тут.
Если у вас есть сеть, подобная той, что показана на рисунке 1, и Вам нужно чтобы А распространятл тот же контент в G, H, M и N, как бы вы это сделали?
Вы можете либо сгенерировать четыре копии трафика, отправив по одному потоку на каждый из приемников с помощью обычной (одноадресной - unicast) переадресации, либо каким-то образом отправить трафик на один адрес, который сеть знает для репликации, чтобы все четыре хоста получили копию. Этот последний вариант называется многоадресной рассылкой (multicast), что означает использование одного адреса для передачи трафика нескольким получателям. Ключевая проблема, решаемая в многоадресной рассылке, заключается в том, чтобы пересылать и реплицировать трафик по мере его прохождения через сеть, чтобы каждый получатель, заинтересованный в потоке, получал копию.
Важно: набор устройств, заинтересованных в получении потока пакетов от источника многоадресной рассылки, называется группой многоадресной рассылки. Это может быть немного запутанным, потому что адрес, используемый для описания многоадресного потока, также называется группой многоадресной рассылки в некоторых ситуациях. Эти два применения практически взаимозаменяемы в том, что набор устройств, заинтересованных в получении определенного набора пакетов многоадресной рассылки, присоединится к группе многоадресной рассылки, что, по сути, означает прослушивание определенного адреса многоадресной рассылки.
Важно: в случаях, когда многоадресный трафик является двунаправленным, эту проблему гораздо сложнее решить. Например, предположим, что существует требование создать группу многоадресной рассылки с каждым хостом в сети, показанной на рисунке 2, кроме N, и далее, чтобы любая многоадресная рассылка, переданная по адресу группы многоадресной рассылки, доставлялась каждому узлу в группе многоадресной рассылки.
Ключевая проблема для решения многоадресной рассылки может быть разбита на две проблемы:
Как узнать, какие устройства хотели бы получить копию трафика, передаваемого в группу многоадресной рассылки?
Как вы определяете, какие устройства в сети должны реплицировать трафик и на каких интерфейсах они должны отправлять копии?
Одним из возможных решений является использование локальных запросов для построения дерева, через которое многоадресный трафик должен передаваться по сети. Примером такой системы является разреженный режим (Sparse Mode) в Protocol Independent Multicast (PIM). В этом процессе каждое устройство отправляет сообщение соединения для многоадресных потоков, которые его интересуют; эти соединения передаются вверх по потоку в сети до тех пор, пока не будет достигнут отправитель (хост, отправляющий пакеты через многоадресный поток). Для иллюстрации этого процесса используется рисунок 2.
На рисунке 2:
A посылает некоторый трафик в группу многоадресной рассылки (адрес) - назовем его Z.
N хотел бы получить копию Z, поэтому он посылает запрос (соединение) своему вышестоящему маршрутизатору D для копии этого трафика.
D не имеет источника для этого трафика, поэтому он посылает запрос маршрутизаторам, к которым он подключен, на копию этого трафика. В этом случае единственный маршрутизатор D отправляет запрос В.
При каждом переходе маршрутизатор, получающий запрос, помещает интерфейс, на котором он получил запрос, в свой список исходящих интерфейсов (Outbound Interface List - OIL) и начинает пересылку трафика, полученного в данной многоадресной группе, полученной через любой другой интерфейс. Таким образом, может быть построен путь от получателя к отправителю трафика -это называется деревом обратного пути.
Второй вариант определения того, какие хосты заинтересованы в получении трафика для определенной группы многоадресной рассылки, - через своего рода сервер регистрации. Каждый хост, который хотел бы получить копию потока, может зарегистрировать свое желание на сервере. Есть несколько способов, которыми хост может обнаружить присутствие сервера, в том числе:
Обращение с адресом группы многоадресной рассылки как с доменным именем и поиск адреса сервера регистрации путем запроса адреса группы многоадресной рассылки.
Построение и ведение списка или сопоставления групп с серверами, отображаемыми в локальной таблице
Использование некоторой формы хэш-алгоритма для вычисления регистрационного сервера по адресу группы многоадресной рассылки
Регистрации могут отслеживаться либо устройствами на пути к серверу, либо, когда набор приемников и передатчиков известен, сервер может сигнализировать соответствующим устройствам вдоль пути, какие порты следует настроить для репликации и пересылки пакетов.
Система доменных имен (DNS – Domain Name System) обеспечивает сетевую коммуникацию. DNS может показаться какой-то невидимой силой или сущностью до тех пор, пока что-то пойдет не так, потому что если DNS выйдет из строя, то ничего работать не будет.
В данной статье будут рассмотрены передовые методы и наиболее важные меры безопасности для поддержания работоспособности вашей инфраструктуры DNS. Чтобы создать безопасную и надежную DNS, обязательно изучите перечисленные ниже пункты.
Передовые технологии для обеспечения высокой производительности DNS
Обеспечение избыточности и высокой доступности DNS
DNS является основой сетевых приложений, поэтому инфраструктура DNS должна быть высоко доступной. А чтобы обеспечить необходимый уровень избыточности, в вашей организации должно быть, как минимум, два DNS-сервера, первичный и вторичный.
Чтобы обеспечить работу критически важных для бизнеса систем, необходимо иметь, как минимум, два внутренних DNS-сервера. Все системы активного каталога, обмена данными и электронной почты полагаются на корректную работу DNS. Без исправно функционирующих внутренних DNS-серверов внутренние устройства не будут иметь возможности обмениваться данными.
Если на одном DNS-сервере возникнет проблема, то второй сразу же заменяет его. Администраторы настраивают оборудование так, чтобы автоматически использовался вторичный DNS, если первичный не отвечает. IP-адрес внутреннего DNS-сервера может быть любым в диапазоне IP-адресов частной сети.
Обеспечивая избыточность DNS-серверов, вы можете добиться высокой доступности инфраструктуры DNS. Непрерывная репликация с первичных серверов на вторичные обеспечит синхронизацию ваших DNS-записей и защитит систему от сбоев. Вы можете быть уверены в том, что конечный пользователь всегда будет иметь возможность получить доступ к системам.
Сокрытие DNS-серверов и DNS-информации
Не каждый DNS-сервер и не каждая информация должна быть доступна для всех пользователей.
Во-первых, откройте только те серверы и данные, которые необходимы лицам, непосредственно использующим эти серверы. Это особенно важно, если ваши доменные имена являются общедоступными.
Во-вторых, скройте свой основной DNS-сервер. Внешние пользователи не должны видеть первичные серверы. Записи для этих серверов не должны быть видны ни в одной общедоступной базе данных серверов имен. Запросы от пользователей должны обрабатывать только вторичные DNS-серверы.
Если DNS-сервер доступен за пределами вашей сети, то это должен быть авторитативный DNS-сервер. Внешним пользователям не нужно обращаться к вашим рекурсивным DNS-серверам. Системная конфигурация будет высокопроизводительной только тогда, когда сервер будет отвечать только на итеративные запросы для соответствующих зон, за которые он отвечает.
В довершение ко всему, иметь доступ к первичным серверам должны только системные администраторы и IT-персонал вашей организации. Если ваши первичные DNS-серверы будут открыты для всех внутренних пользователей, то это может создать серьезную угрозу для безопасности. Как показывает практика, лучше скрывать DNS-серверы и некоторые данные от пользователей, которым доступ к ним не нужен.
Нужно ли использовать внешний или внутренний DNS-сервер?
Ответ на данный вопрос зависит от внутренней настройки.
Чтобы устройства в одном домене могли общаться друг с другом, вам необходимо указать внутренний DNS-сервер. Внешние DNS-серверы не могут работать с именами хостов внутренних устройств.
Например, когда компьютер DESKTOP1 отправляет DNS-запрос для офисного принтера или сервера hr-1, только внутренняя DNS может предоставить запись ресурса. Если вы настроите устройство на использование внешнего DNS, например, 8.8.8.8 Google, то вы не сможете использовать внутренние ресурсы.
Во внутренних средах необходимо установить, как первичный, так и вторичный DNS на внутренний сервер имен. Даже если основной DNS-сервер даст сбой, проблем с подключением не будет. Дополнительный DNS-сервер содержит все записи и действует как резервная копия. В случае возникновения какой-либо проблемы, этот сервер отвечает на все запросы до тех пор, пока не заработает основной сервер.
Использование локального или ближайшего DNS-сервера
Офисы крупных организаций часто расположены по всему миру. В таком случае следует настроить локальный DNS-сервер в каждом офисе, если позволяет инфраструктура.
А все потому, что локальный сервер сокращает время ответа на DNS-запросы. Если же запрос проходит через глобальную сеть к удаленному серверу имен, то время загрузки увеличивается.
При большом количестве клиентов, естественно, увеличивается количество DNS-запросов. Одна централизованная группа DNS-серверов, конечно, может обрабатывать все эти запросы, но с большой задержкой. Если компьютеры пользователей будут направляться на локальный или ближайший сервер имен, то время отклика может существенно сократиться.
В таком случае задержка не превышает 50 мс. Более того, это значение обычно даже намного ниже. Использование ближайшего DNS-сервера сокращает время загрузки для всех устройств. Таким образом, вы также уменьшаете нагрузку на удаленный сервер в штаб-квартире и повышаете его производительность. Здесь также остается актуальной рекомендация иметь, как минимум, два DNS-сервера.
Передовые методы обеспечения безопасности DNS
DNS-серверы очень часто становятся целью кибератак. Важным шагом в предотвращении вторжений в вашу организацию является защита инфраструктуры DNS. Чтобы избежать серьезного нарушения настроек DNS, обязательно изучите меры безопасности, описанные ниже.
Ведение журнала DNS-сервера
Ведение журнала DNS-сервера – это один из самых эффективных способов отслеживания активности DNS. Журналы сообщают вам, если кто-то пытается вмешаться в ваши DNS-серверы. Помимо активности пользователей, журналы отладки сообщают вам о проблемах с DNS-запросами или обновлениями.
Журналы DNS также показывают следы отравления кэша. При таком виде атаки злоумышленник изменяет хранящиеся в кэше данные и сбивают пользователей с курса. Например, IP-адрес www.youtube.com может быть заменен на IP-адрес вредоносного сайта. Когда пользователь отправляет запрос в DNS для youtube.com, сервер теперь возвращает неверный IP-адрес. В результате чего пользователи попадают на тот веб-сайт, который они не хотели посещать и становятся мишенью для хакеров.
Несмотря на то, что ведение журнала отладки DNS повышает уровень безопасности, некоторые системные администраторы решают этим пренебречь. Основная причина такого решения – повышение производительности. Отслеживание сетевой активности может помочь вам обнаружить некоторые атаки, такие как DDoS, но не отравление кэша. Поэтому мы настоятельно рекомендуем использовать ведение журналов отладки DNS.
Блокировка кэша DNS
Всякий раз, когда появляется запрос от клиента, DNS находит информацию и сохраняет ее в кэше для будущего использования. Этот процесс позволяет серверу быстрее отвечать на одни и те же запросы. Злоумышленники могут воспользоваться этой функцией путем изменения сохраненной информации.
Следующий шаг после использования журналов отладки DNS – это блокировка кэша DNS. Это функция определяет, когда кэшированные данные могут быть изменены. Сервер хранит информацию о поиске в течение времени, определяемого TTL (Time To Life - время жизни). Если блокировка кэша не используется, то информация может быть перезаписана до истечения TTL. Это оставляет место для атак с отравлением кэша.
В некоторых операционных системах блокировка кэша может быть включена по умолчанию. Масштаб блокировки кэша может достигать 100%. Когда установлено значение 70, то перезапись данных невозможна до истечения 70% TTL. При определении блокировки кэша равным 100 изменение кэшированной информации блокируется до истечения всего TTL.
Фильтрация DNS-запросов для блокировки вредоносных доменов
Фильтрация DNS – это эффективный способ ограничить доступ пользователей к веб-сайту или домену. Основная причина для блокировки разрешения имен для домена – наличие информации о вредоносности этого домена. Когда клиент отправляет запрос на заблокированный веб-сайт, DNS-сервер прекращает любую связь между ними.
DNS-фильтрация значительно снижает вероятность проникновения вирусов и вредоносных программ в вашу сеть. Когда пользователь не может получить доступ к вредоносной странице, то и количество угроз, которые могут проникнуть в вашу инфраструктуру, крайне мало. Таким образом, вашему IT-персоналу не требуется круглосуточно работать, чтобы очищать систему от вирусов.
Помимо соображений безопасности, есть еще одна причина, по которой организации могут заблокировать домен – бизнес-политика или по соображениям производительности. В список заблокированных доменов могут входить социальные сети, азартные игры, порнография, страницы потокового видео или любые другие веб-сайты. DNS может фильтровать запросы по пользователю, группе или блокировать доступ для всех пользователей.
Современные системы обеспечения защиты ПО и брандмауэры имеют DNS-фильтрацию в стандартной комплектации. Некоторые из них предоставляют списки плохих доменов, которые регулярно обновляются. Вы можете использовать готовое программное решение и таким образом автоматизировать фильтрацию DNS, а не добавлять новые записи вручную.
Проверка целостности данных DNS с помощью DNSSEC
Модули безопасности службы доменных имен (DNSSEC – Domain Name System Security Extensions) гарантируют, что пользователи получат действительные ответы на свои запросы. Целостность данных достигается за счет цифровой подписи DNSSEC на данных DNS, предоставляемых серверам имен. Когда конечный пользователь отправляет запрос, DNS-сервер предоставляет цифровую подпись с ответом. Стало быть, пользователи знают, что они получили достоверную информацию в качестве ответа на отправленный ими запрос.
Этот дополнительный уровень безопасности помогает бороться с атаками на протокол DNS. Атаки «спуфинга» DNS и отравления кэша успешно предотвращаются, поскольку DNSSEC обеспечивает целостность данных и авторизацию их источника. В дальнейшем пользователи будут уверены, что посещают именно те страницы, которые хотели посетить.
Настройка списков контроля доступа
Списки контроля доступа (ACL – Access Control Lists) – это еще один способ защиты DNS-серверов от несанкционированного доступа и атак «спуфинга». К вашему основному DNS-серверу доступ должны иметь только системные и IT-администраторы. Настройка ACL для разрешения входящих подключений к серверу имен с определенных хостов гарантирует то, что только определенная часть персонала сможет обращаться к вашим серверам.
Кроме того, ACL должны определять, какие серверы могут выполнять передачу зон. Злоумышленники могут попытаться определить настройки вашей зоны, отправив запросы на передачу зоны через вторичные DNS-серверы. Если вы заблокируете все запросы на передачу зоны через вторичные серверы, то злоумышленник не сможет получить информацию о зоне. Эта конфигурация не позволяет третьим лицам получить представление о том, как организована ваша внутренняя сеть.
Заключение
Всегда есть возможности для улучшения системной архитектуры DNS и ее безопасности. Постоянные угрозы скрываются и ждут, когда появится уязвимость в вашей информационной системе, чтобы воспользоваться ей.
Но тем не менее, если вы будете следовать рекомендациям, описанным в данном руководстве, то вы охватите наиболее важные аспекты, которые необходимы для обеспечения безопасности и отказоустойчивости вашей инфраструктуры DNS.