Как описано в заголовке, я использую dovecot / postfix / Rspamd Mailservercombo с MariaDB за ним.
Я заметил, что в последние дни я больше не мог получать / отправлять почту от моих почтовых клиентов. Thunderbird тоже заметил: больше невозможно подключиться к SMTP-серверу.
Единственное, что я изменил за это время:
С тех пор я удалил и очистил fail2ban, уверен, что это была проблема. Это не так. (?)
Прочитав следующий вывод из системного журнала, я проследил его до UFW:
вывод системного журнала (замаскированный)
Сам UFW имеет следующую конфигурацию:
# cat /etc/ufw/user.rules
*filter
:ufw-user-input - [0:0]
:ufw-user-output - [0:0]
:ufw-user-forward - [0:0]
:ufw-before-logging-input - [0:0]
:ufw-before-logging-output - [0:0]
:ufw-before-logging-forward - [0:0]
:ufw-user-logging-input - [0:0]
:ufw-user-logging-output - [0:0]
:ufw-user-logging-forward - [0:0]
:ufw-after-logging-input - [0:0]
:ufw-after-logging-output - [0:0]
:ufw-after-logging-forward - [0:0]
:ufw-logging-deny - [0:0]
:ufw-logging-allow - [0:0]
:ufw-user-limit - [0:0]
:ufw-user-limit-accept - [0:0]
### RULES ###
### tuple ### allow tcp 22 0.0.0.0/0 any 0.0.0.0/0 in
-A ufw-user-input -p tcp --dport 22 -j ACCEPT
### tuple ### allow tcp 2222 0.0.0.0/0 any 0.0.0.0/0 in
-A ufw-user-input -p tcp --dport 2222 -j ACCEPT
### tuple ### allow tcp 25 0.0.0.0/0 any 0.0.0.0/0 in
-A ufw-user-input -p tcp --dport 25 -j ACCEPT
### tuple ### allow tcp 465 0.0.0.0/0 any 0.0.0.0/0 in
-A ufw-user-input -p tcp --dport 465 -j ACCEPT
### tuple ### allow tcp 587 0.0.0.0/0 any 0.0.0.0/0 in
-A ufw-user-input -p tcp --dport 587 -j ACCEPT
### tuple ### allow tcp 143 0.0.0.0/0 any 0.0.0.0/0 in
-A ufw-user-input -p tcp --dport 143 -j ACCEPT
### tuple ### allow tcp 993 0.0.0.0/0 any 0.0.0.0/0 in
-A ufw-user-input -p tcp --dport 993 -j ACCEPT
### tuple ### allow tcp 4190 0.0.0.0/0 any 0.0.0.0/0 in
-A ufw-user-input -p tcp --dport 4190 -j ACCEPT
### tuple ### allow tcp 80 0.0.0.0/0 any 0.0.0.0/0 in
-A ufw-user-input -p tcp --dport 80 -j ACCEPT
### tuple ### allow tcp 443 0.0.0.0/0 any 0.0.0.0/0 in
-A ufw-user-input -p tcp --dport 443 -j ACCEPT
### END RULES ###
### LOGGING ###
-A ufw-after-logging-input -j LOG --log-prefix "[UFW BLOCK] " -m limit --limit 3/min --limit-burst 10
-A ufw-after-logging-forward -j LOG --log-prefix "[UFW BLOCK] " -m limit --limit 3/min --limit-burst 10
-I ufw-logging-deny -m conntrack --ctstate INVALID -j RETURN -m limit --limit 3/min --limit-burst 10
-A ufw-logging-deny -j LOG --log-prefix "[UFW BLOCK] " -m limit --limit 3/min --limit-burst 10
-A ufw-logging-allow -j LOG --log-prefix "[UFW ALLOW] " -m limit --limit 3/min --limit-burst 10
### END LOGGING ###
### RATE LIMITING ###
-A ufw-user-limit -m limit --limit 3/minute -j LOG --log-prefix "[UFW LIMIT BLOCK] "
-A ufw-user-limit -j REJECT
-A ufw-user-limit-accept -j ACCEPT
### END RATE LIMITING ###
COMMIT
Как вы можете видеть на последних нескольких записях, похоже, что это может быть вызвано ufw-after-logging-input, ufw-after-logging-forward или ufw-logging-deny. Однако на этом мои «знания» прямо сейчас заканчиваются. Единственное, что я дополнительно заметил, это то, что следующая строка была отмечена красным в user.rules, но это могло быть просто ничем ...
Я переустановил fail2ban для этого:
# fail2ban-client status
Status
|- Number of jail: 1
`- Jail list: sshd
# fail2ban-client status sshd
Status for the jail: sshd
|- Filter
| |- Currently failed: 1
| |- Total failed: 158
| `- File list: /var/log/auth.log
`- Actions
|- Currently banned: 1
|- Total banned: 1
`- Banned IP list: 112.xxx.xxx.xxx
# fail2ban-client set sshd unbanip 112.xxx.xxx.xxx
112.xxx.xxx.xxx
# fail2ban-client status sshd
[...]
`- Banned IP list:
/var/log/auth.log
перечисляет множество таких записей, все с ОДНОГО IP:
Jun 25 19:56:51 mail sshd[26691]: Connection closed by 112.xxx.xxx.xxx port 60391 [preauth]
Jun 25 19:56:52 mail sshd[26693]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=112.xxx.xxx.xxx user=root
Jun 25 19:56:54 mail sshd[26693]: Failed password for root from 112.xxx.xxx.xxx port 64328 ssh2
Jun 25 19:56:54 mail sshd[26693]: Connection closed by authenticating user root 112.xxx.xxx.xxx port 64328 [preauth]
Jun 25 19:57:03 mail sshd[26697]: Connection closed by 112.xxx.xxx.xxx port 50264 [preauth]
Это не может быть я, поскольку я никогда не вхожу в систему с правами root.
Я просмотрел множество сайтов, но не нашел никаких полезных советов о том, как решить эту проблему. Похоже, это действительно произошло из-за одного из недавних изменений, которые я внес, хотя я не могу придумать ничего, кроме, возможно, не удаленного правила, которое может все еще действовать после очистки и удаления fail2ban.
Некоторые вещи, которые я также пробовал в процессе исправления: - перезапуск и остановка / запуск UFW - перезапуск apache2 - перезапуск dovecot - поиск в Rspamd записей событий в отправленных тестовых письмах (с тех пор, как я внес изменения, ни одного не было получено! ) - с помощью другого почтового клиента - добавление правила приема для порта 25 в UFW (ничего не менял)
P.S .: На этом сервере работает Ubuntu.
Есть ли способ вернуть мою установку в рабочее состояние?
Теперь, кажется, после многих попыток я решил свою проблему. Несколько советов по решению этой проблемы:
Нет, это не имеет ничего общего с этими UFW-блоками. Прежде всего, проверьте, работаете ли вы с правильными названиями сервисов! Я забыл, что из-за ошибки я начал postfix с другим именем службы, чем вы обычно.
Вероятно, вы можете увидеть, неправильное ли у вас имя службы, сравнив, если эта часть systemctl status <servicename>.service
идентичен на вашем сервере:
CGroup: /system.slice/system-postfix.slice/<servicename>.service
├─5832 /usr/lib/postfix/sbin/master -w
├─5833 pickup -l -t unix -u -c
└─5834 qmgr -l -t unix -u
Моя неправильная служба была только на CGroup под своим именем.
После того, как я получил правильное имя службы, я мог быстро найти проблему, как systemctl status <servicename>.service
теперь выводите правильные сообщения об ошибках:
Jun 26 18:32:40 mail postmulti[6814]: /usr/sbin/postconf: warning: /etc/postfix/main.cf: unused parameter: mua_client_restrictions=permit_mynetworks,permit_sasl_authenticated,reject
Jun 26 18:32:40 mail postmulti[6814]: /usr/sbin/postconf: warning: /etc/postfix/main.cf: unused parameter: mua_sender_restrictions=permit_mynetworks,reject_non_fqdn_sender,reject_sender_login_mismatch,permit_sasl_authenticated,reject
Jun 26 18:32:40 mail postmulti[6814]: /usr/sbin/postconf: warning: /etc/postfix/main.cf: unused parameter: mua_relay_restrictions=reject_non_fqdn_recipient,reject_unknown_recipient_domain,permit_mynetworks,permit_sasl_authenticated,reject
Это результат неправильной конфигурации main.cf и master.cf. Обе конфигурации зависят друг от друга, если вы копируете / вставляете, вам понадобятся обе из одного источника!
У меня также были следующие ошибки, которые намекают на отсутствующую (или в моем случае поврежденную) реализацию пакета postfix-mysql. Просто apt-get remove postfix-mysql
и apt-get install postfix-mysql
потом.
Jun 26 18:20:41 mail postfix/submission/smtpd[6252]: error: unsupported dictionary type: mysql
Jun 26 18:20:41 mail postfix/submission/smtpd[6252]: message repeated 3 times: [ error: unsupported dictionary type: mysql]
Jun 26 18:20:41 mail postfix/submission/smtpd[6252]: fatal: in parameter smtpd_relay_restrictions or smtpd_recipient_restrictions, specify at least one working instance of: reject_unauth_destination, defer_unauth_destination, reject, defer, defer_if_permit or check_relay_domains
Jun 26 18:20:42 mail postfix/master[5832]: warning: process /usr/lib/postfix/sbin/smtpd pid 6252 exit status 1
Jun 26 18:20:42 mail postfix/master[5832]: warning: /usr/lib/postfix/sbin/smtpd: bad command startup -- throttling
Еще одна вещь, которая могла бы помочь, - это переделать пользователя mysql. Сначала я добавил пользователя в mysqldb, получив доступ к серверу с root в командной строке и введя grant select on dbname.* to 'username'@'localhost' identified by 'verystrongpassword';
. Я удалил этого пользователя сейчас, заменив его тем, который я добавил с помощью phpmyadmin, и явно добавив его в 'username'@'%'
вместо того 'username'@'localhost'
.
И последнее, что я узнал из этого - если вы добавляете новые пакеты на свой сервер, проверьте, есть ли зависимости, которые могут мешать или заменят уже настроенную службу. (sendmail
также может быть одной из проблем, из-за которых мой постфиксный сервер остановился, к сожалению, я не могу подтвердить это после всех других попыток)
Конфигурация UFW выглядит правильно.
Вам, наверное, удалось забанить собственный IP в fail2ban.
Использовать fail2ban-client status
чтобы увидеть, какие тюрьмы включены, затем fail2ban-client status <jail>
чтобы узнать, указан ли ваш IP-адрес. Если вы найдете свой IP, вы можете его разблокировать.
[root@localhost ~]# fail2ban-client status
Status
|- Number of jail: 1
`- Jail list: sshd
[root@localhost ~]# fail2ban-client status sshd
Status for the jail: sshd
|- Filter
| |- Currently failed: 3
| |- Total failed: 762
| `- Journal matches: _SYSTEMD_UNIT=sshd.service + _COMM=sshd
`- Actions
|- Currently banned: 13
|- Total banned: 86
`- Banned IP list: 121.136.181.58 212.224.124.98 65.94.147.197 176.159.245.52 68.32.77.29 112.17.128.44 220.81.48.50 104.210.60.66 104.211.60.207 104.211.46.110 212.64.98.92 59.144.137.186 90.3.202.234
[root@localhost ~]# fail2ban-client set sshd unbanip 203.0.113.187
203.0.113.187