По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Каждый день на сайт заходят тысячи поисковых роботов/ботов, и очень немногие из них помогают. Некоторые из них вообще являются продуктами злоумышленных целей ботами или спамом.
Откуда можно узнать, сколько разных ботов посещают ваши веб-сайты?
На самом деле, однозначного ответа нет. Для этого необходимо просмотреть файл access.log веб-сервера и найти столбец User-Agent. Допустим, вы хотите перечислить все боты, кроме Googlebot, тогда вы можете выполнить следующую команду на вашем веб-сервере, где существует файл access.log.
grep bot access.log |grep -v Googlebot
Вас тоже удивил результат? Вот, что выдал тот же запрос на моем сервере:
root@gf-prod:nginx# grep bot access.log |grep -v Googlebot | wc -l
616834
root@gf-prod:nginx#
Прежде чем блокировать что-либо, необходимо просмотреть их и убедиться, что вы не блокируете то, что используется вашим приложением. Вообще, есть много способов блокировки ботов, но я всегда предпочитаю блокировать их на границе.
Причина проста - бесполезные запросы вообще не должны попадать и обрабатываться веб-сервером.
А теперь, давайте узнаем, как блокировать ботов, которые вам не нужны, с помощью брандмауэра Cloudflare.
Заходим на панель управления Cloudflare;
Переходим на вкладку Firewall, затем - правила firewall и нажимаем на кнопку создать правило firewall.
Вводим название правила;
В качестве фильтра выбираем User Agent, оператор - contains, а в качестве значения - название бота, которое нужно заблокировать;
Чтобы добавить несколько критериев в одно правило используйте оператор OR.
Примечание: боты, указаны в целях демонстрации, они не обязательно вредоносные.
Затем в качестве действия выбираем Block и нажимаем Deploy;
Если умеете работать с выражениями, то тоже самое можете сделать кликнув на ссылку Edit expression. Сразу после применения, можно будет увидеть созданное правило. Чтобы данное правило применялось к трафику, переключатель состояния должен быть ON.
Легко, не так ли?
Что еще можно сделать, экспериментируя с правилами межсетевого экрана?
Для повышения безопасности можно применять указанные ниже критерии блокировки:
Блокировать если запрос идет с конкретного ASN или IP адреса;
По соответствию ключевым словам cookie, referrer, X-Forwarder-for;
Блокировка запросов из конкретной страны;
Отключение нежелательных HTTP-методов в роде PUT, DELETE, OPTIONS, PURGE и т.д.
И другие подобные опции. Все это можно выполнить как с помощью графического интерфейса, так и редактированием выражений. Изменения применяются почти сразу.
Заключение
Правила брандмауэра Cloudflare - отличный способ без простоев повысить защиту веб-приложений на границе сети. Если еще не применяете данное решение, вы также можете рассмотреть возможность использования Cloud WAF для повышения безопасности приложений и защиты от DDoS и других сетевых уязвимостей.
Прокси сервер - это элемент сетевой инфраструктуры, который выполняет роль посредника между клиентским компьютером (терминал, браузер, приложение), находящимся во внутренней сети и другим сервером, который живёт во внешней сети или наоборот.
Прокси сервер может применяться для решения следующих задач:
усиление безопасности
защита приватности
балансировка нагрузки на посещаемый ресурс
Как можно использовать прокси сервер
Прокси сервер принимает и передает запросы от клиентов (которые могут находиться как во внутренней так и во внешней сети) к различным сетевым службам и обеспечивает их передачу целевым серверам. При этом, клиент может даже не знать о том, что взаимодействие осуществляется через прокси сервер. Принимая запросы от клиента прокси сервер может либо: сразу передать их на запрашиваемый ресурс, либо сразу вернуть клиенту запрашиваемый ресурс из своего кэша, либо отказать в доступе к запрашиваемому ресурсу. Всё это делает прокси сервер очень важным элементом сетевой архитектуры.
Основные возможности, которыми обладает прокси сервер перечислены ниже:
Получение доступа к определенным ресурсам (в том числе заблокированным по каким-либо причинам) - во многих компаниях доступ в Интернет для сотрудников происходит только через прокси сервер. Это делается для того, чтобы пользователь не посещал ресурсы, не разрешенные политикой компании. Однако, прокси также может использоваться и для обхода блокировок. Прямой доступ к ресурсу может быть заблокирован, а к прокси – нет. Таким образом, если обращаться к заблокированному ресурсу через прокси, то можно получить к нему доступ. Правда, в зависимости от того где территориально расположен прокси, скорость доступа может пострадать.
Анонимизация IP адреса клиентского компьютера - обращаясь к какому-либо ресурсу через прокси, можно скрыть свой реальный IP адрес, так что “вычислить по IP” вас будет гораздо сложнее.
Блокировка вредоносного трафика и определенных ресурсов в сети - мы можем использовать прокси не только для обхода, но и для проведения блокировок. Об одном из таких способов с использованием роутера MikroTik, мы рассказывали статье.
Ведение журнала сетевых подключений - прокси позволяет нам отслеживать все сетевые подключения, которые через него проходят. Мы можем включить логирование событий прокси и отправлять их на какое-нибудь LM-решение для последующего анализа.
Прокси сервера бывают двух видов:
Прямой (Forward) - прямой прокси - это такой промежуточный сервер, которых находится между клиентом и сервером назначения, которому обращается клиент. Чтобы получить контент с сервера назначения, клиент отправляет запрос прокси-серверу с указанием сервера назначения в качестве цели, а прокси запрашивает контент и возвращает его клиенту. Клиент должен быть специально настроен (например, можно указать прокси в браузере) для использования такого прокси для доступа к другим сайтам.
Обратный (Reverse) - обратный прокси, напротив, выглядит для клиента, как обычный веб-сервер. Никаких специальных настроек на клиенте не требуется. Клиент делает обычные запросы на получение контента, которые отправляются в пространство имен обратного прокси. Затем прокси решает, куда отправить эти запросы, и возвращает контент так, как если бы он и был сервером назначения.
Типичным примером использования обратного прокси-сервера является предоставление пользователям в Интернете доступа к серверу, который находится за межсетевым экраном. Обратные прокси-серверы также можно использовать для балансировки нагрузки между несколькими внутренними серверами или для обеспечения кэширования для более медленного внутреннего сервера. Кроме того, обратные прокси-серверы можно использовать просто для переноса нескольких серверов в одно и то же пространство URL.
Использование прокси для усиления безопасности корпоративной инфраструктуры
Многие компании имеют ресурсы, которые выставлены в публичную сеть и доступны каждому внешнему пользователю. Это может быть просто сайт компании или сервис, за счёт которого она зарабатывает деньги (например - интернет магазин). Самой большой угрозой для таких ресурсов является угроза взлома.
Прокси сервер добавляет дополнительный, “буферный” уровень безопасности между защищаемым ресурсом и внешним трафиком. Таким образом, злоумышленники могут получить доступ к вашему прокси серверу, но не смогут подключиться к серверу, на котором действительно работает защищаемый ресурс, где хранятся ваши данные. Это может значительно уменьшить вероятность взлома ресурса.
Контроль пользователей при использовании Интернета
Ни одна компания не хочет, чтобы сотрудники получали доступ к незащищенным или неуместным веб-сайтам через корпоративную сеть. Поэтому при построении сетевой архитектуры, администраторы часто принимают решение воспользоваться возможностями прокси сервера.
Когда доступ пользователей к Интернету осуществляется через прокси-сервер, сетевые администраторы легко могут контролировать, какие устройства будут иметь доступ и какие сайты эти устройства смогут посещать. С помощью прокси-сервера можно заблокировать нежелательный контент, а также любые сайты, нежелательные для посещения сотрудниками компании в рабочее время.
Включив логирование на прокси, сетевые администраторы могут даже отслеживать, к какому контенту и когда обращаются сотрудники для внутренних целей. Многие сотрудники службы безопасности используют это для отслеживания потенциальных незаконных действий или нарушений политик безопасности.
Балансировка нагрузки на корпоративные ресурсы
Ничто так не раздражает клиента, чем веб-сайт компании, который тормозит и падает, в самый неподходящий момент. Если ресурс популярный, то нагрузка на него может быть колоссальной и сервер, обеспечивающий работу ресурса, может просто не справиться с потоком запросов от клиентов. Прокси серверы, облачные сервисы и технологии пиринга помогают исключить подобные ситуации.
Особенно актуально это для ресурсов, данные и контент которых хранятся на множестве серверов, распределенных по всему миру. У пользователей из разных стран может быть разная скорость доступа к ресурсу. В таком случае, прокси сервер может использоваться для создания единого веб-ресурса, который будет служить единой точкой доступа. Прокси будет осуществлять балансировку запросы к каждому целевому серверу, чтобы ни один из них не перегружался. Все это работает в фоновом режиме, чтобы обеспечить бесперебойное обслуживание клиентов ресурсов.
Прокси-серверы можно также легко использовать для увеличения скорости и экономии полосы пропускания в сети за счет сжатия трафика, кэширования файлов и веб-страниц, к которым обращаются несколько пользователей, и даже - удаления рекламы с веб-сайтов. Это освобождает полосу пропускания в загруженных сетях.
В этой серии статей мы рассмотрим поиск и устранение неисправностей NAT (трансляции сетевых адресов) / PAT (трансляции адресов портов), DHCP и FHRP (протоколы избыточности при первом переходе).
NAT/PAT может быть проблемным, и не потому, что настройка несколько сложна (хотя и в этом тоже могут быть проблемы). Но в основном потому, что мы можем столкнуться с проблемами маршрутизации, так как мы периодически меняем IP-адреса. Во второй части этой серии мы рассмотрим наиболее распространенные проблемы DHCP и, наконец, закончим серию статей некоторыми проблемами FHRP.
Урок 1
В этом сценарии у нас есть 3 устройства. Маршрутизатор с левой стороны называется "Хост", и он представляет компьютер из нашей локальной сети. Предполагается, что устройство с правой стороны - это какой-то веб-сервер - это то, что мы пытаемся найти в Интернете. В середине мы видим наш маршрутизатор, который настроен для NAT и/или PAT.
Пользователи из нашей локальной сети жалуются на то, что они ничего не могут найти в Интернете. Они подтвердили, что их IP-адрес и шлюз по умолчанию в порядке. Давайте изучим маршрутизатор NAT:
Хорошая идея, чтобы проверить, может ли маршрутизатор NAT достичь веб-сервера, попробовав простой пинг. Если это не работает, вы, по крайней мере, знаете, что у вас есть проблемы с маршрутизацией или, что веб-сервер не работает (или, возможно, просто блокирует ICMP-трафик).
Поскольку это веб-сервер, лучше попробовать подключиться к TCP-порту 80. Вы видите, что это работает, так что маршрутизация между маршрутизатором NAT и веб-сервером + подключение к TCP-порту не является проблемой.
Мы можем использовать команду show ip nat translations, чтобы увидеть, происходит ли что-нибудь. Мы видим, что NAT-маршрутизатор что-то транслирует, но если вы посмотрите внимательно, то увидите, что это выглядит не совсем правильно. Внешние локальные и глобальные IP-адреса ссылаются ко внутреннему IP-адресу. Давайте посмотрим на конфигурацию ...
show ip nat statistics - хорошая команда для проверки вашей конфигурации. Вы можете видеть, что внутренние и внешние интерфейсы поменялись местами. FastEthernet 0/0 должен быть inside, а FastEthernet 1/0 должен быть outside.
NAT(config)#interface fastEthernet 0/0
NAT(config-if)#ip nat inside
NAT(config)#interface fastEthernet 1/0
NAT(config-if)#ip nat outside
Введем команды, которые позволяют исправить настройки, чтобы у нас были правильные внутренние и внешние интерфейсы.
Трафик с хоста на веб-сервер теперь работает!
Вот как должна выглядеть таблица трансляции NAT. Внутренний локальный IP-адрес - наш внутренний хост. Внутренний глобальный IP-адрес - это то, что мы настроили на внешней стороне нашего маршрутизатора NAT (FastEthernet 1/0). Внешний локальный и глобальный IP-адрес - наш веб-сервер ... проблема решена!
Итог урока: убедитесь, что у вас имеются правильные внутренние и внешние интерфейсы.
Урок 2
Та же топология, другая проблема! Опять пользователи нашей локальной сети жалуются, что они не могут связаться с веб-сервером. Давайте проверим наш маршрутизатор NAT:
NAT#show ip nat translations
Сначала мы проверим, транслирует ли маршрутизатор что-либо. Как видите, тихо ничего не происходит!
Мы убедились, что внутренний и внешний интерфейсы были настроены правильно. Однако никаких трансляций не происходит. Внутренний источник был определен с помощью списка доступа 1. Давайте поближе рассмотрим этот ACL:
Ааа, смотрите ... кажется, кто-то испортил ACL! Устраним эту неполадку:
NAT(config)#no access-list 1
NAT(config)#access-list 1 permit 192.168.12.0 0.0.0.255
Мы создадим ACL так, чтобы он соответствовал 192.168.12.0/24.
Теперь мы можем связаться с веб-сервером с нашего хоста.
Мы видим Hits, если просмотреть NAT statistics.
И я вижу трансляцию ... проблема решена!
Итог урока: убедитесь, что вы используете правильный список доступа, соответствующий вашим внутренним хостам.
Теперь почитатей продожение статьи про устранение неисправностей с DHCP.