timeoutэто утилита командной строки, которая запускает указанную команду и завершает ее, если она все еще выполняется по истечении заданного периода времени. Другими словами, timeoutпозволяет запустить команду с ограничением по времени. Эта timeoutкоманда является частью пакета основных утилит GNU, который установлен практически в любом дистрибутиве Linux.
Это удобно, когда вы хотите запустить команду, которая не имеет встроенной опции тайм-аута.
В этой статье мы объясним, как использовать команду Linux timeout.
Как использовать timeoutкоманду
Синтаксис timeoutкоманды следующий:
timeout [OPTIONS] DURATION COMMAND [ARG]…
Копировать
Может DURATIONбыть положительным целым числом или числом с плавающей запятой, за которым следует необязательный суффикс единицы измерения:
s— секунды (по умолчанию)
m— минут
h— часы
d— дней
Когда единицы измерения не используются, по умолчанию используются секунды. Если для длительности установлено нулевое значение, соответствующий тайм-аут отключен.
Параметры команды должны быть указаны перед аргументами.
Вот несколько основных примеров, демонстрирующих использование timeoutкоманды:
Завершить команду через пять секунд:timeout 5 ping 8.8.8.8Копировать
Завершить команду через пять минут:timeout 5m ping 8.8.8.8Копировать
Завершить команду через одну минуту и шесть секунд:timeout 1.1m ping 8.8.8.8Копировать
Если вы хотите запустить команду, требующую повышенных привилегий, например tcpdump , добавьте sudo перед timeout:
sudo timeout 300 tcpdump -n -w data.pcap
Отправка определенного сигнала
Если сигнал не подан, timeoutотправляет SIGTERMсигнал управляемой команде, когда достигается лимит времени. Вы можете указать, какой сигнал отправлять, используя опцию -s( ).--signal
Например, чтобы отправить SIGKILLкоманду ping через одну минуту, вы должны использовать:
sudo timeout -s SIGKILL ping 8.8.8.8
Вы можете указать сигнал по имени, например SIGKILL, или по его номеру, например 9. Следующая команда идентична предыдущей:
sudo timeout -s 9 ping 8.8.8.8
Чтобы получить список всех доступных сигналов, используйте kill -l команду:
kill -l
Уничтожение зависших процессов
SIGTERM, сигнал по умолчанию, отправляемый при превышении лимита времени, может быть перехвачен или проигнорирован некоторыми процессами. В таких ситуациях процесс продолжает выполняться после отправки сигнала завершения.
Чтобы убедиться, что отслеживаемая команда уничтожена, используйте параметр -k( --kill-after), за которым следует период времени. Когда эта опция используется после достижения заданного срока, timeoutкоманда отправляет SIGKILLуправляемой программе сигнал, который нельзя перехватить или проигнорировать.
В следующем примере timeoutкоманда выполняется в течение одной минуты, и если она не будет завершена, она будет уничтожена через десять секунд:
sudo timeout -k 10 1m ping 8.8.8.8
тайм-аут -k «./test.sh»
убит после достижения заданного срока
Сохранение статуса выхода
timeoutвозвращается 124, когда лимит времени достигнут. В противном случае он возвращает статус выхода управляемой команды.
Чтобы вернуть статус выхода команды даже при достижении лимита времени, используйте --preserve-statusопцию:
timeout --preserve-status 5 ping 8.8.8.8
Бег на переднем плане
По умолчанию timeoutзапускает управляемую команду в фоновом режиме. Если вы хотите запустить команду на переднем плане, используйте --foregroundопцию:
timeout --foreground 5m ./script.sh
Этот параметр полезен, когда вы хотите запустить интерактивную команду, требующую ввода данных пользователем.
Вывод
Команда timeoutиспользуется для запуска данной команды с ограничением по времени.
timeoutэто простая команда, которая не имеет большого количества опций. Обычно вы будете вызывать timeoutтолько с двумя аргументами: продолжительностью и управляемой командой.
Если у вас есть какие-либо вопросы или отзывы, не стесняйтесь оставлять комментарии.
В данной инструкции рассмотрены варианты и примеры создания резервных копий и восстановления баз СУБД PostgreSQL.
Все команды, которые приводятся ниже, должны выполняться из командной строки. В Linux — это окно терминала, в Windows — командная строка (cmd.exe) с переходом в папку установки PostgreSQL.
Создание резервных копий
Базовая команда
Синтаксис:
pg_dump <параметры> <имя базы> > <файл, куда сохранить дамп>
Пример:
pg_dump users > /tmp/users.dump
Пользователь и пароль
Если резервная копия выполняется не от учетной записи postgres, необходимо добавить опцию -U с указанием пользователя:
pg_dump -U dmosk -W users > /tmp/users.dump
* где dmosk — имя учетной записи; опция W потребует ввода пароля.
Сжатие данных
Для экономии дискового пространства или более быстрой передачи по сети можно сжать наш архив:
pg_dump users | gzip > users.dump.gz
Скрипт для автоматического резервного копирования
Рассмотрим 2 варианта написания скрипта для резервирования баз PostgreSQL. Первый вариант — запуск скрипта от пользователя root для резервирования одной базы. Второй — запуск от пользователя postgres для резервирования всех баз, созданных в СУБД.
Для начала, создадим каталог, в котором разместим скрипт, например:
mkdir /scripts
И сам скрипт:
vi /scripts/postgresql_dump.sh
Вариант 1. Запуск от пользователя root; одна база.
* где password — пароль для подключения к postgresql; /backup — каталог, в котором будут храниться резервные копии; dbuser — имя учетной записи для подключения к БУБД; pathB — путь до каталога, где будут храниться резервные копии. * данный скрипт сначала удалит все резервные копии, старше 61 дня, но оставит от 15-о числа как длительный архив. После при помощи утилиты pg_dump будет выполнено подключение и резервирование базы db. Пароль экспортируется в системную переменную на момент выполнения задачи.
Для запуска резервного копирования по расписанию, сохраняем скрипт в файл, например, /scripts/postgresql_dump.sh и создаем задание в планировщике:
crontab -e
3 0 * * * /scripts/postgresql_dump.sh
* наш скрипт будет запускаться каждый день в 03:00.
Вариант 2. Запуск от пользователя postgres; все базы.
#!/bin/bash
PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
pathB=/backup/postgres
find $pathB ( -name "*-1[^5].*" -o -name "*-[023]?.*" ) -ctime +61 -delete
for dbname in `echo "SELECT datname FROM pg_database;" | psql | tail -n +3 | head -n -2 | egrep -v 'template0|template1|postgres'`; do
pg_dump $dbname | gzip > $pathB/$dbname-$(date "+%Y-%m-%d").sql.gz
done;
* где /backup — каталог, в котором будут храниться резервные копии; pathB — путь до каталога, где будут храниться резервные копии. * данный скрипт сначала удалит все резервные копии, старше 61 дня, но оставит от 15-о числа как длительный архив. После найдет все созданные в СУБД базы, кроме служебных и при помощи утилиты pg_dump будет выполнено резервирование каждой найденной базы. Пароль нам не нужен, так как по умолчанию, пользователь postgres имеет возможность подключаться к базе без пароля.
Необходимо убедиться, что у пользователя postgre будет разрешение на запись в каталог назначения, в нашем примере, /backup/postgres.
Зададим в качестве владельца файла, пользователя postgres:
* где public — схема; students — таблица; users — база данных.
Размещение каждой таблицы в отдельный файл
Также называется резервированием в каталог. Данный способ удобен при больших размерах базы или необходимости восстанавливать отдельные таблицы. Выполняется с ипользованием ключа -d:
pg_dump -d customers > /tmp/folder
* где /tmp/folder — путь до каталога, в котором разместяться файлы дампа для каждой таблицы.
Для определенной схемы
В нашей базе может быть несколько схем. Если мы хотим сделать дамп только для определенной схемы, то используем опцию -n, например:
pg_dump -n public peoples > /tmp/peoples.public.sql
* в данном примере мы заархивируем схему public базы данных peoples.
Только схемы (структуры)
Для резервного копирования без данных (только таблицы и их структуры):
При необходимости авторизоваться при подключении к базе вводим:
psql -U dmosk -W users < /tmp/users.dump
* где dmosk — имя учетной записи; опция W потребует ввода пароля.
Из файла gz
Сначала распаковываем файл, затем запускаем восстановление:
gunzip users.dump.gz
psql users < users.dump
Или одной командой:
zcat users.dump.gz | psql users
Определенную базу
Если резервная копия делалась для определенной базы, запускаем восстановление:
psql users < /tmp/database.dump
Если делался полный дамп (всех баз), восстановить определенную можно при помощи утилиты pg_restore с параметром -d:
pg_restore -d users cluster.bak
Определенную таблицу
Если резервная копия делалась для определенной таблицы, можно просто запустить восстановление:
psql users < /tmp/students.dump
Если делался полный дамп, восстановить определенную таблицу можно при помощи утилиты pg_restore с параметром -t:
pg_restore -a -t students users.dump
С помощью pgAdmin
Запускаем pgAdmin — подключаемся к серверу — кликаем правой кнопкой мыши по базе, для которой хотим восстановить данные — выбираем Восстановить:
Выбираем наш файл с дампом:
И кликаем по Восстановить:
Использование pg_restore
Данная утилита предназначена для восстановления данных не текстового формата (в одном из примеров создания копий мы тоже делали резервную копию не текстового формата).
Из бинарника:
pg_restore -Fc users.bak
Из тарбола:
pg_restore -Ft users.tar
С созданием новой базы:
pg_restore -Ft -C users.tar
Мы можем использовать опцию d для указания подключения к конкретному серверу и базе, например:
* в данном примере мы подключимся к локальной базе (localhost) с названием dmosk_base от пользователя dmosk_user с паролем dmosk_pass.
Работа с CSV
Мы можем переносить данные с использованием файлов csv. Это нельзя назвать напрямую резервным копированием, но в рамках данной инструкции материал будет интересен.
Создание файла CSV (экспорт)
Пример запроса (выполняется в командной оболочке SQL):
> COPY (SELECT * FROM public.users WHERE name LIKE 'А%') TO '/tmp/users.csv' WITH CSV DELIMITER ';' HEADER;
* в данном примере мы выгрузим все данные для таблицы users в схеме public, где значение поля name начинается с буквы А. Результат будет сохранен в файл /tmp/users.csv. Также мы указываем, что в качестве разделителя данных нужно использовать точку с запятой и первой строкой сделать заголовок.
Также мы можем сделать выгрузку, но сделать вывод в оболочку и перенаправить его в файл:
psql -d "postgresql://pg_user:pg_pass@localhost:5432/pg_databasename" -c "COPY (SELECT * FROM public.users WHERE name LIKE 'А%') TO STDIN WITH CSV DELIMITER ';' HEADER;" > /tmp/users.csv
Импорт данных из файла CSV
Также можно выполнить запрос в оболочке SQL:
> COPY public.users FROM '/tmp/test.csv' DELIMITER ';' CSV HEADER;
* в нашем примере мы выполним импорт данных из ранее созданного файла /tmp/users.csv в таблицу users.
Возможные ошибки
Рассмотрим некоторые проблемы, с которыми можно столкнуться при работе с дампами PostgreSQL.
Input file appears to be a text format dump. please use psql.
Причина: дамп сделан в текстовом формате, поэтому нельзя использовать утилиту pg_restore.
Решение: восстановить данные можно командой psql <имя базы> < <файл с дампом> или выполнив SQL, открыв файл, скопировав его содержимое и вставив в SQL-редактор.
No matching tables were found
Причина: Таблица, для которой создается дамп не существует. Утилита pg_dump чувствительна к лишним пробелам, порядку ключей и регистру.
Решение: проверьте, что правильно написано название таблицы и нет лишних пробелов.
Too many command-line arguments
Причина: Утилита pg_dump чувствительна к лишним пробелам.
Решение: проверьте, что нет лишних пробелов.
Aborting because of server version mismatch
Причина: несовместимая версия сервера и утилиты pg_dump. Может возникнуть после обновления или при выполнении резервного копирования с удаленной консоли.
Решение: нужная версия утилиты хранится в каталоге /usr/lib/postgresql/<version>/bin/. Необходимо найти нужный каталог, если их несколько и запускать нужную версию. При отсутствии последней, установить.
No password supplied
Причина: нет системной переменной PGPASSWORD или она пустая.
Решение: либо настройте сервер для предоставление доступа без пароля в файле pg_hba.conf либо экспортируйте переменную PGPASSWORD (export PGPASSWORD или set PGPASSWORD).
Неверная команда
Причина: при выполнении восстановления возникла ошибка, которую СУБД не показывает при стандартных параметрах восстановления.
Решение: запускаем восстановление с опцией -v ON_ERROR_STOP=1, например:
psql -v ON_ERROR_STOP=1 users < /tmp/users.dump
Теперь, когда возникнет ошибка, система прекратит выполнять операцию и выведет сообщение на экран.
Репутация IP основана на черных списках и списках спама в сочетании с публичными данными о владении.
Эти данные, как правило, должны быть чистыми, если ваша компания не занимается спамом и может быстро обнаружить и остановить заражение вредоносным ПО.
Поэтому для большинства компаний их рейтинг в значительной степени определяется тем, какие заголовки безопасности установлены на веб-сайтах, предназначенных для общего пользования.
Установка правильных заголовков может быть выполнена быстро (обычно без значительного тестирования), может повысить безопасность веб-сайта и теперь может помочь вам заключать сделки с клиентами, заботящимися о безопасности.
Важные заголовки безопасности
Content-Security-Policy
CSP используется для предотвращения межсайтового скриптинга, определяя, какие ресурсы разрешено загружать.
Из всех пунктов этого списка этот, пожалуй, самый трудоемкий для создания и правильной поддержки и самый подверженный рискам.
При разработке CSP тщательно протестируйте его – блокировка источника контента, который ваш сайт использует допустимым образом, приведет к нарушению функциональности сайта.
Отличным инструментом для создания первого наброска является расширение браузера Mozilla Laboratory CSP.
Установите его в свой браузер, тщательно просмотрите сайт, для которого вы хотите создать CSP, а затем используйте созданный CSP на своем сайте.
В идеале, также поработайте над рефакторингом JavaScript, чтобы не оставалось встроенных скриптов, и тогда вы сможете удалить директиву ‘unsafe inline’.
CSP могут быть сложными и запутанными, поэтому, если вы хотите более глубокого погружения, обратитесь к официальному сайту.
Хорошей начальной CSP может быть следующая (скорее всего, она потребует много изменений на реальном сайте).
Добавьте домены в каждый раздел, который содержит ваш сайт.
# Default to only allow content from the current site
# Allow images from current site and imgur.com
# Don't allow objects such as Flash and Java
# Only allow scripts from the current site
# Only allow styles from the current site
# Only allow frames from the current site
# Restrict URL's in the <base> tag to current site
# Allow forms to submit only to the current site
Content-Security-Policy: default-src 'self'; img-src 'self' https://i.imgur.com; object-src 'none'; script-src 'self'; style-src 'self'; frame-ancestors 'self'; base-uri 'self'; form-action 'self';
Strict-Transport-Security
Этот заголовок сообщает браузеру, что доступ к сайту должен осуществляться только через HTTPS – всегда включайте его, если на вашем сайте включен HTTPS.
Если вы используете поддомены, я также рекомендую использовать этот заголовок для всех используемых поддоменов.
Этот заголовок гарантирует, что типы MIME, установленные приложением, будут соблюдаться браузерами.
Это может помочь предотвратить некоторые типы обхода межсайтового скриптинга.
Он также уменьшает неожиданное поведение приложения, когда браузер может неправильно “угадать” содержимое, например, когда разработчик обозначает страницу как “HTML”, но браузер считает, что она выглядит как JavaScript, и пытается отобразить ее как JavaScript.
Этот заголовок гарантирует, что браузер всегда будет принимать тип MIME, установленный сервером.
X-Content-Type-Options: nosniff
Cache-Control3
Этот параметр немного сложнее других, поскольку вы, скорее всего, хотите использовать разные политики кэширования для разных типов контента.
Любая страница с конфиденциальными данными, например, страница пользователя или страница оформления заказа, должна быть установлена на no-cache.
Одна из причин этого – предотвращение того, чтобы кто-то на общем компьютере мог нажать кнопку “назад” или просмотреть историю и получить возможность просмотреть личную информацию.
Однако страницы, которые меняются редко, такие как статические активы (изображения, CSS-файлы и JS-файлы), полезно кэшировать.
Это может быть сделано на основе каждой страницы или с помощью regex в конфигурации сервера.
# Не кэшировать по умолчанию
Header set Cache-Control no-cache
# Кэширование статических активов на 1 день
<filesMatch ".(css|jpg|jpeg|png|gif|js|ico)$">
Header set Cache-Control "max-age=86400, public"
</filesMatch>
Expires
Устанавливает время, в течение которого кэш должен завершить текущий запрос.
Он игнорируется, если установлен заголовок Cache-Control max-age, поэтому мы задаем его только на случай, если сканер будет проверять его без учета cache-control.
В целях безопасности мы будем считать, что браузер не должен ничего кэшировать, поэтому мы установим дату, которая всегда оценивается как прошедшая.
Expires: 0
X-Frame-Options
Этот заголовок указывает, следует ли разрешить отображение сайта в iFrame.
Если вредоносный сайт помещает ваш сайт в iFrame, он может выполнить атаку click jacking, запустив JavaScript, который будет перехватывать нажатия мыши на iFrame и затем взаимодействовать с сайтом от имени пользователя (не обязательно нажимая там, где он думает, что нажал!).
Этот параметр всегда должен быть установлен на deny, если только вы не используете фреймы специально, в этом случае он должен быть установлен на same-origin.
Если вы используете фреймы с другим сайтом, вы можете указать здесь белый список другого домена.
Следует также отметить, что этот заголовок заменен директивой CSP frame-ancestors.
Я все еще рекомендую установить ее, чтобы успокоить инструменты, но в будущем она, вероятно, будет постепенно отменена.
X-Frame-Options: deny
Access-Control-Allow-Origin
Указывает браузеру, какой код JavaScript других сайтов может делать запросы к данной странице.
Если вам не нужно настраивать этот параметр, обычно правильным является значение по умолчанию.
Например, если сайт А предоставляет некоторый JavaScript, который хочет сделать запрос к сайту Б, то сайт Б должен предоставить ответ с заголовком, указывающим, что сайту А разрешено делать этот запрос.
Это может быть немного запутанным, поэтому взгляните схему, иллюстрирующую работу этого заголовка:
Этот заголовок указывает браузерам приостановить выполнение обнаруженных атак межсайтового скриптинга.
Обычно его установка не представляет особого риска, но все же его следует протестировать перед внедрением в производство.
X-XSS-Protection: 1; mode=block
Примеры конфигураций веб-сервера
Как правило, лучше всего добавлять заголовки по всему сайту в конфигурации вашего сервера.
Исключением здесь являются файлы cookie, поскольку они часто определяются в самом приложении.
Перед добавлением любых заголовков на ваш сайт я рекомендую сначала проверить обсерваторию или вручную просмотреть заголовки, чтобы увидеть, какие из них уже установлены. Некоторые фреймворки и серверы автоматически устанавливают некоторые из них за вас, поэтому применяйте только те, которые вам нужны или которые вы хотите изменить.
Конфигурация Apache
Пример настройки Apache в .htaccess:
<IfModule mod_headers.c>
Header set Content-Security-Policy: default-src 'self'; img-src 'self' https://i.imgur.com; object-src 'none'; script-src 'self'; style-src 'self'; frame-ancestors 'self'; base-uri 'self'; form-action 'self';
Header set X-XSS-Protection: 1; mode=block
Header set Access-Control-Allow-Origin: http://www.one.site.com
Header set X-Frame-Options: deny
Header set X-Content-Type-Options: nosniff
Header set Strict-Transport-Security: max-age=3600; includeSubDomains
Header set Cache-Control no-cache
Header set Expires: 0
<filesMatch ".(ico|css|js|gif|jpeg|jpg|png|svg|woff|ttf|eot)$">
Header set Cache-Control "max-age=86400, public"
</filesMatch>
</IfModule>
Если у вас нет доступа к веб-серверу или у вас сложные требования к настройке заголовков, вы можете захотеть установить их в самом приложении.
Обычно это можно сделать с помощью промежуточного программного обеспечения фреймворка для всего сайта, а также на основе каждого ответа для установки единичных заголовков.
Для краткости в примерах я включил только один заголовок. Добавьте все необходимые с помощью этого метода таким же образом.
В последние дни многие организации стали жертвами киберпреступности. Были разработаны более сложные ботнеты и другие методы атак, которые увеличивают скорость этих атак.
Наиболее распространенными атаками являются DDoS (распределенный отказ в обслуживании), захват учетных записей (ATO) и перехват контента с веб-сайтов.
Эти атаки имеют тяжелые последствия для целевых организаций и должны быть предотвращены любой ценой.
Обычно Bad Bots можно определить как программные приложения, которые выполняют автоматизированные задачи со злыми намерениями через Интернет.
Они маскируются в системе путем маскировки агентов пользователя.
Такими плохими ботами могут быть;
Боты или серверы, связанные с вирусами или вредоносным ПО
Боты для правительственного наблюдения
Атакующие сети ботнетов (Mirai)
Сайты азартных игр и порносайты
Сканеры уязвимостей
Спам-рефереры
Браузерное рекламное и вредоносное ПО (Yontoo и т.д.)
Инструменты для исследования ссылок и тестирования обратных ссылок
SEO компании, которые используют ваши конкуренты для улучшения своего SEO
Сайты хотлинк на изображения и воры изображений
Боты для ранжирования ссылок
Сборщики электронной почты
Сайты, связанные с выгодными вредоносными программами, рекламным ПО и Ransomware Кампании Clickjacking
Остановка “Ghost спама” Google Analytics
Это руководство демонстрирует, как вы можете блокировать Bad Bots, спам, User-Agents и Ransomware на Nginx.
Шаг 1 – Скачать Nginx Bad Bot Blocker
Nginx Bad Bot Blocker был разработан Митчеллом Крогом для использования в веб-сервере Nginx.
Его можно загрузить в систему Linux с помощью команды:
### С wget
wget https://raw.githubusercontent.com/mitchellkrogza/nginx-ultimate-bad-bot-blocker/master/install-ngxblocker
### С curl
sudo curl -sL https://raw.githubusercontent.com/mitchellkrogza/nginx-ultimate-bad-bot-blocker/master/install-ngxblocker -o install-ngxblocker
Чтобы установить Nginx Bad Bot Blocker, мы запустим скрипт установки.
Этот скрипт можно запустить в DRY-MODE, чтобы показать изменения, которые он внесет, и файлы, которые он загрузит, как показано ниже.
sudo /usr/local/sbin/setup-ngxblocker
Вывод:
/etc/nginx/sites-available/ssl.no-default.conf
/etc/nginx/sites-available/no-default.conf
/etc/nginx/sites-available/wordpress.example.com.conf
Configure every file above as a vhost ? [Y/N] : Y
Checking url: https://raw.githubusercontent.com/mitchellkrogza/nginx-ultimate-bad-bot-blocker/master/include_filelist.txt
** Dry Run ** | not updating files | run as 'setup-ngxblocker -x' to setup files.
inserting: include /etc/nginx/conf.d/globalblacklist.conf; => /etc/nginx/nginx.conf
inserting: include /etc/nginx/conf.d/botblocker-nginx-settings.conf; => /etc/nginx/nginx.conf
inserting: include /etc/nginx/bots.d/blockbots.conf; => /etc/nginx/sites-available/wordpress.example.com.conf
inserting: include /etc/nginx/bots.d/ddos.conf; => /etc/nginx/sites-available/wordpress.example.com.conf
Whitelisting ip: 88.99.92.81 => /etc/nginx/bots.d/whitelist-ips.conf
Web directory not found ('/var/www'): not automatically whitelisting domains.
Checking for missing includes:
Checking url: https://raw.githubusercontent.com/mitchellkrogza/nginx-ultimate-bad-bot-blocker/master/include_filelist.txt
Nothing to update for directory: /etc/nginx/conf.d
Nothing to update for directory: /etc/nginx/bots.d
Nothing to update for directory: /usr/local/sbin
Setting mode: 700 => /usr/local/sbin/install-ngxblocker
Setting mode: 700 => /usr/local/sbin/setup-ngxblocker
Setting mode: 700 => /usr/local/sbin/update-ngxblocker
Чтобы внести изменения в nginx.conf, необходимо запустить скрипт с параметром -x.
sudo ./setup-ngxblocker -x
Ввыод:
/etc/nginx/sites-available/ssl.no-default.conf
/etc/nginx/sites-available/no-default.conf
/etc/nginx/sites-available/wordpress.example.com.conf
Configure every file above as a vhost ? [Y/N] : y
Checking url: https://raw.githubusercontent.com/mitchellkrogza/nginx-ultimate-bad-bot-blocker/master/include_filelist.txt
inserting: include /etc/nginx/conf.d/globalblacklist.conf; => /etc/nginx/nginx.conf
inserting: include /etc/nginx/conf.d/botblocker-nginx-settings.conf; => /etc/nginx/nginx.conf
inserting: include /etc/nginx/bots.d/blockbots.conf; => /etc/nginx/sites-available/wordpress.example.com.conf
inserting: include /etc/nginx/bots.d/ddos.conf; => /etc/nginx/sites-available/wordpress.example.com.conf
Whitelisting ip: 88.99.92.81 => /etc/nginx/bots.d/whitelist-ips.conf
Web directory not found ('/var/www'): not automatically whitelisting domains.
Checking for missing includes:
Checking url: https://raw.githubusercontent.com/mitchellkrogza/nginx-ultimate-bad-bot-blocker/master/include_filelist.txt
Nothing to update for directory: /etc/nginx/conf.d
Nothing to update for directory: /etc/nginx/bots.d
Nothing to update for directory: /usr/local/sbin
Setting mode: 700 => /usr/local/sbin/install-ngxblocker
Setting mode: 700 => /usr/local/sbin/setup-ngxblocker
Setting mode: 700 => /usr/local/sbin/update-ngxblocker
Приведенная выше команда включает все файлы виртуальных хостов Nginx на сервере и вносит ваш Ip-адрес в белый список в файле whitelist-ips.conf.
Вы можете внести желаемые изменения, отредактировав файл /etc/nginx/bots.d/whitelist-ips.conf.
По сути, скрипт добавляет приведенные ниже утверждения “include” в ваши файлы виртуальных хостов Nginx:
Кроме того, вы можете установить блокировщик в нестандартную папку Nginx, указав их:
Например, если вы хотите заблокировать доступ GoogleBot к вашему сайту, отредактируйте файл /etc/nginx/bots.d/blacklist-user-agents.conf, который отменяет белый список по умолчанию для GoogleBot.
Это можно сделать и для любого другого бота, внесенного в белый список.
Шаг 6 – Тестирование Nginx Bad Bot Blocker
Вы можете протестировать ваш Nginx Bad Bot Blocker из терминала на другой системе, используя ваше доменное имя, как показано ниже:
curl -A "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.96 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" -I http://yourdomain.com
Вы также можете использовать:
curl -A "Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)" -I http://yourdomain.com
В последние дни многие организации стали жертвами киберпреступности. Были разработаны более сложные ботнеты и другие методы атак, которые увеличивают скорость этих атак.
Наиболее распространенными атаками являются DDoS (распределенный отказ в обслуживании), захват учетных записей (ATO) и перехват контента с веб-сайтов.
Эти атаки имеют тяжелые последствия для целевых организаций и должны быть предотвращены любой ценой.
Обычно Bad Bots можно определить как программные приложения, которые выполняют автоматизированные задачи со злыми намерениями через Интернет.
Они маскируются в системе путем маскировки агентов пользователя.
Такими плохими ботами могут быть;
Боты или серверы, связанные с вирусами или вредоносным ПО
Боты для правительственного наблюдения
Атакующие сети ботнетов (Mirai)
Сайты азартных игр и порносайты
Сканеры уязвимостей
Спам-рефереры
Браузерное рекламное и вредоносное ПО (Yontoo и т.д.)
Инструменты для исследования ссылок и тестирования обратных ссылок
SEO компании, которые используют ваши конкуренты для улучшения своего SEO
Сайты хотлинк на изображения и воры изображений
Боты для ранжирования ссылок
Сборщики электронной почты
Сайты, связанные с выгодными вредоносными программами, рекламным ПО и Ransomware Кампании Clickjacking
Остановка “Ghost спама” Google Analytics
Это руководство демонстрирует, как вы можете блокировать Bad Bots, спам, User-Agents и Ransomware на Nginx.
Шаг 1 – Скачать Nginx Bad Bot Blocker
Nginx Bad Bot Blocker был разработан Митчеллом Крогом для использования в веб-сервере Nginx.
Его можно загрузить в систему Linux с помощью команды:
### С wget
wget https://raw.githubusercontent.com/mitchellkrogza/nginx-ultimate-bad-bot-blocker/master/install-ngxblocker
### С curl
sudo curl -sL https://raw.githubusercontent.com/mitchellkrogza/nginx-ultimate-bad-bot-blocker/master/install-ngxblocker -o install-ngxblocker
Чтобы установить Nginx Bad Bot Blocker, мы запустим скрипт установки.
Этот скрипт можно запустить в DRY-MODE, чтобы показать изменения, которые он внесет, и файлы, которые он загрузит, как показано ниже.
sudo /usr/local/sbin/setup-ngxblocker
Вывод:
/etc/nginx/sites-available/ssl.no-default.conf
/etc/nginx/sites-available/no-default.conf
/etc/nginx/sites-available/wordpress.example.com.conf
Configure every file above as a vhost ? [Y/N] : Y
Checking url: https://raw.githubusercontent.com/mitchellkrogza/nginx-ultimate-bad-bot-blocker/master/include_filelist.txt
** Dry Run ** | not updating files | run as 'setup-ngxblocker -x' to setup files.
inserting: include /etc/nginx/conf.d/globalblacklist.conf; => /etc/nginx/nginx.conf
inserting: include /etc/nginx/conf.d/botblocker-nginx-settings.conf; => /etc/nginx/nginx.conf
inserting: include /etc/nginx/bots.d/blockbots.conf; => /etc/nginx/sites-available/wordpress.example.com.conf
inserting: include /etc/nginx/bots.d/ddos.conf; => /etc/nginx/sites-available/wordpress.example.com.conf
Whitelisting ip: 88.99.92.81 => /etc/nginx/bots.d/whitelist-ips.conf
Web directory not found ('/var/www'): not automatically whitelisting domains.
Checking for missing includes:
Checking url: https://raw.githubusercontent.com/mitchellkrogza/nginx-ultimate-bad-bot-blocker/master/include_filelist.txt
Nothing to update for directory: /etc/nginx/conf.d
Nothing to update for directory: /etc/nginx/bots.d
Nothing to update for directory: /usr/local/sbin
Setting mode: 700 => /usr/local/sbin/install-ngxblocker
Setting mode: 700 => /usr/local/sbin/setup-ngxblocker
Setting mode: 700 => /usr/local/sbin/update-ngxblocker
Чтобы внести изменения в nginx.conf, необходимо запустить скрипт с параметром -x.
sudo ./setup-ngxblocker -x
Ввыод:
/etc/nginx/sites-available/ssl.no-default.conf
/etc/nginx/sites-available/no-default.conf
/etc/nginx/sites-available/wordpress.example.com.conf
Configure every file above as a vhost ? [Y/N] : y
Checking url: https://raw.githubusercontent.com/mitchellkrogza/nginx-ultimate-bad-bot-blocker/master/include_filelist.txt
inserting: include /etc/nginx/conf.d/globalblacklist.conf; => /etc/nginx/nginx.conf
inserting: include /etc/nginx/conf.d/botblocker-nginx-settings.conf; => /etc/nginx/nginx.conf
inserting: include /etc/nginx/bots.d/blockbots.conf; => /etc/nginx/sites-available/wordpress.example.com.conf
inserting: include /etc/nginx/bots.d/ddos.conf; => /etc/nginx/sites-available/wordpress.example.com.conf
Whitelisting ip: 88.99.92.81 => /etc/nginx/bots.d/whitelist-ips.conf
Web directory not found ('/var/www'): not automatically whitelisting domains.
Checking for missing includes:
Checking url: https://raw.githubusercontent.com/mitchellkrogza/nginx-ultimate-bad-bot-blocker/master/include_filelist.txt
Nothing to update for directory: /etc/nginx/conf.d
Nothing to update for directory: /etc/nginx/bots.d
Nothing to update for directory: /usr/local/sbin
Setting mode: 700 => /usr/local/sbin/install-ngxblocker
Setting mode: 700 => /usr/local/sbin/setup-ngxblocker
Setting mode: 700 => /usr/local/sbin/update-ngxblocker
Приведенная выше команда включает все файлы виртуальных хостов Nginx на сервере и вносит ваш Ip-адрес в белый список в файле whitelist-ips.conf.
Вы можете внести желаемые изменения, отредактировав файл /etc/nginx/bots.d/whitelist-ips.conf.
По сути, скрипт добавляет приведенные ниже утверждения “include” в ваши файлы виртуальных хостов Nginx:
Кроме того, вы можете установить блокировщик в нестандартную папку Nginx, указав их:
Например, если вы хотите заблокировать доступ GoogleBot к вашему сайту, отредактируйте файл /etc/nginx/bots.d/blacklist-user-agents.conf, который отменяет белый список по умолчанию для GoogleBot.
Это можно сделать и для любого другого бота, внесенного в белый список.
Шаг 6 – Тестирование Nginx Bad Bot Blocker
Вы можете протестировать ваш Nginx Bad Bot Blocker из терминала на другой системе, используя ваше доменное имя, как показано ниже:
curl -A "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.96 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" -I http://yourdomain.com
Вы также можете использовать:
curl -A "Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)" -I http://yourdomain.com
Роль Graylog Ansible позволяет установить и настроить Graylog.
Ее можно установить с помощью команды:
$ ansible-galaxy install graylog2.graylog
Starting galaxy role install process
- downloading role 'graylog', owned by graylog2
- downloading role from https://github.com/Graylog2/graylog-ansible-role/archive/3.3.7.tar.gz
- extracting graylog2.graylog to /Users/jkmutai/.ansible/roles/graylog2.graylog
- graylog2.graylog (3.3.7) was installed successfully
- adding dependency: lean_delivery.java (7.1.0)
- adding dependency: elastic.elasticsearch (main)
- downloading role 'java', owned by lean_delivery
- downloading role from https://github.com/lean-delivery/ansible-role-java/archive/7.1.0.tar.gz
- extracting lean_delivery.java to /Users/jkmutai/.ansible/roles/lean_delivery.java
- lean_delivery.java (7.1.0) was installed successfully
- extracting elastic.elasticsearch to /Users/jkmutai/.ansible/roles/elastic.elasticsearch
- elastic.elasticsearch (main) was installed successfully
Из приведенного выше результата вы заметите, что следующие зависимости были установлены.
Java
Elasticsearch
Проверьте, были ли установлены зависимости роли , используя команду:
