Некоторые вопросы о журнале httpd

Первый вопрос: почему существует два файла журнала ошибок? Один из них - /var/www/mywebsite/error.log, который указан в с инструкцией ErrorLog. Другой - / var / log / httpd / error_log. Я не могу найти, где это определено. Есть строка за пределами в /etc/httpd/conf/httpd.conf:

ErrorLog "logs/error_log"

Но я думаю, что это не соответствует / var / log / httpd / error_log.

Второй вопрос: почему владельцем обоих файлов журнала ошибок является root: root, а не apache: apache, как указано в /etc/httpd/conf/httpd.conf:

User apache
Group apache
0
задан 17 March 2021 в 10:44
1 ответ

Итак, aspf = s означает, что он должен быть строгим для сопоставления SPF, что означает, что вам нужно -all, а не ~ all

adkim = s означает, что он должен быть строгим для сопоставления DKIM, что означает, что он обеспечил выход ключа подписи DKIM, а открытый компонент этой клавиатуры DKIM соответствовал публичной DNS-записи, для которой он предназначался

Указанные выше два параметра настройки являются частью записи DMARC.

Текущие настройки aspf и adkim - r (расслабленные).

Глядя на заголовки кажется, что отправитель доставил электронное письмо mx.google.com, которое, я полагаю, находится в пределах _spf.google.com покрытия, поэтому я думаю, что в конечном итоге вам нужно будет установить строгий расклад dkim, так как идея заключается в том, что в конечном итоге этот пользователь должен будет отправлять электронные письма с ключом подписи для вашего домена, а не просто отправлять из IP-диапазонов Google.

Не стесняйтесь регистрироваться у поставщика услуг электронной почты, который предлагает аутентифицированный SMTP для удаленной отправки электронных писем через Gmail по SMTP/SMTPS, чтобы проверить это, может использовать его для отправки по электронной почте тестового сообщения от www.mail-tester.com и анализа результатов.

Некоторые ссылки для вас:

https://mxtoolbox.com/dmarc/details/dmarc-tags/aspf

https://mxtoolbox.com/dmarc/details/dmarc-tags/adkim

https://www.dmarcanalyzer.com/dmarc/dmarc-record-setup-guides/google-g-suite-dmarc-setup-guide/

https://support.google.com/a/answer/2466563?hl=en

https://mha.azurewebsites.net/

-121--478521-

У меня установлен fail2ban

Недостаточно установить fail2ban, необходимо настроить его для удовлетворения ваших потребностей. Fail2ban является всего лишь инструментом и требует надлежащего использования, как и многие другие инструменты.

Чтобы остановить «потоп», как это у вас есть в основном 3 основные возможности:

  1. если вы уверены, что ваша веб-страница не имеет в основном некоторые нарушенные ссылки, достаточно отреагировать на 404 (или некоторые другие 40x) ответ:
[bad-http]
logpath = /path/to/your/log
filter =
# fail on every 40x (excepting 401 for authentication attempt, which should be handled separately):
failregex = ^<ADDR> \S+ \S+ \[\] "[^"]+" 40(?!1)\d\s+
maxretry = 10
# findtime = some-time-after-maxretry-attempts-should-cause-a-ban
enabled = true

и вы должны проверить (и, вероятно, исправить) правило, вызывающее 302-перенаправление (вероятно, некоторые белый список для URI это перенаправление повлияет только).

  1. Если вы не можете быть уверены или нуждаетесь в более точной обработке, вам нужно сделать какой-нибудь URI из списка блоков, часто используемый этими ботами (или чековый референт, или какой-нибудь cookie или что-либо еще), например:
[bad-http]
logpath = /path/to/your/log
filter =
# fail on certain 40x (uris starting with this block-list):
_blocklist = vendor|solr|api|\?a=fetch|wp-content|console|\?XDEBUG_SESSION_START=|Autodiscover
failregex = ^<ADDR> \S+ \S+ \[\] "[A-Z]+ /(?:%(_blocklist)s)\b[^"]*" 40\d\s+
maxretry = 10
# findtime = some-time-after-maxretry-attempts-should-cause-a-ban
enabled = true

Просто обратите внимание, что в этом случае вы должны проверить, что префиксы URI в списке блоков не конфликтуют с вашими законными URI, а также постоянно поддерживать этот список. Также обратите внимание, что «злоумышленникам» очень просто избежать вашего запрета, просто изменив URI (например, добавив какой-то другой параметр перед вашим префиксом)

  1. так же, как и 2. но с помощью белого списка допустимых URI:
[bad-http]
logpath = /path/to/your/log
filter =
# fail on certain 40x (excepting given white-list):
_whitelist = my-app|other-app
failregex = ^<ADDR> \S+ \S+ \[\] "[A-Z]+ /(?!%(_whitelist)s)\b[^"]*" 40\d\s+
maxretry = 10
# findtime = some-time-after-maxretry-attempts-should-cause-a-ban
enabled = true

Здесь можно указать все допустимые префиксы RE в _ белом списке , чтобы избежать возможных ложных срабатываний для законных URI.

Независимо от того, что вы используете, вы можете начать с большой maxretry (и короткой findtime ) и небольшого значения bantime (таким образом, избегая слишком длинного запрета для возможного ложноположительного), и если версия fail2ban > = 0,10 с включенным bantime.increment ,так что рецидивирующие злодеи попадают под запрет дольше и быстрее позже.

Также рассмотрите https://github.com/fail2ban/fail2ban/wiki/Best-practice , чтобы получить рекомендации по более эффективной настройке fail2ban-камер и фильтров.

-121--478810-

Два файла журнала ошибок, поскольку один из них относится к серверу в целом (в отношении ошибок запуска и проблем, влияющих на все виртуальные хосты), а журнал ошибок в виртуальном хосте ограничен сообщениями об ошибках, характерными для событий, относящихся к виртуальному хосту. (например, ошибка 404)

Второй:

когда Apache запускается как root (чтобы иметь возможность связываться с привилегированными портами 80 и 443), он может удалить привилегии и впоследствии будет работать как пользователь, определенный в пользовательской директиве: Apache. Файлы журнала открываются при запуске (до удаления привилегий) и поэтому принадлежат пользователю, запускающему Apache т.е. root.

0
ответ дан 24 April 2021 в 02:09

Теги

Похожие вопросы