Форум Сайтостроение Администрирование серверов

IP в блеклисте, но тем не менее отразился в логах. Как?

M2
На сайте с 11.01.2011
Offline
342
mark2011
960

Всем привет!

Появилась у меня в mail.log вот такая строчка:


Mar 30 16:42:59 vmd30300 postfix/smtpd[28384]: lost connection after RCPT from 31-46-236-14.pool.kapulan.hu[31.46.236.14]

Ок, нет проблем, даю команду:


whois 31.46.236.14

На выходе получаю информацию об IP, из которой меня интересует следующее:


route: 31.46.0.0/16

Даю следующую команду:


ipset add spammers 31.46.0.0/16

а в ответ:


ipset add spammers 31.46.0.0/16
ipset v6.30: Element cannot be added to the set: it's already added

Хмммммм........... как тогда этот IP в логи просочился? Пакета с этого адреса просто не должно было быть...

Вот мой iptables с самого начала - фрагмент до "spammers":


Chain INPUT (policy DROP)
target prot opt source destination
DROP all -- anywhere anywhere match-set AS54290 src
DROP all -- anywhere anywhere match-set south_africa src
DROP all -- anywhere anywhere match-set saudiarabia src
DROP all -- anywhere anywhere match-set sprint src
DROP all -- anywhere anywhere match-set microsoft src
DROP all -- anywhere anywhere match-set afghanistan src
DROP all -- anywhere anywhere match-set seychelles src
DROP all -- anywhere anywhere match-set ukraine src
DROP all -- anywhere anywhere match-set israel src
DROP all -- anywhere anywhere match-set indonesia src
DROP all -- anywhere anywhere match-set locaweb src
DROP all -- anywhere anywhere match-set africa src
DROP all -- anywhere anywhere match-set countryblock-angola src
DROP all -- anywhere anywhere match-set countryblock-hk src
DROP all -- anywhere anywhere match-set countryblock-jp src
DROP all -- anywhere anywhere match-set countryblock-cn src
DROP all -- anywhere anywhere match-set spammers src

Единственное, что реально мне на ум приходит - подменный адрес... т.е. реальный пакет был отправлен не с адреса 31.46.236.14, а с какого-то другого, но в логах отобразился именно 31.46.236.14... если так - тогда какой смысл в этих ipset, если это всё можно подделать?...

Если такого быть не может - тогда что это означает? Пакет с адреса, заблокированного в ipset, виден в логах. Как?

PS Просто прикола ради сейчас выдал команду:


ipset -L spammers | grep "31.46.0.0/16"
31.46.0.0/16

Да, действительно, система не обманула :) такой IP действительно есть в бане... тогда я вообще ничего не понимаю....

------------------- Крутые VPS и дедики. Качество по разумной цене ( http://cp.inferno.name/view.php?product=1212&gid=1 ) VPS25OFF - скидка 25% на первый платеж по ссылке выше
Оптимизайка
На сайте с 11.03.2012
Offline
396
Оптимизайка
#1

Полностью iptables -L -n -v покажите и iptables -L -n -v -t nat.

Такое может быть, например, если соединение с этого ip уже было открыто, а вы добавили его позже, либо есть в nat таблице prerouting правила, срабатывающие до фильтрации в цепочке input.

⭐ BotGuard (https://botguard.net) ⭐ — защита вашего сайта от вредоносных ботов, воровства контента, клонирования, спама и хакерских атак!
Не работает DNS resolver, Контроль пользователей в локальной exim4 - исходящие письма
M2
На сайте с 11.01.2011
Offline
342
mark2011
#2

Оптимизайка,

iptables -L -n -v


iptables -L -n -v
Chain INPUT (policy DROP 6434 packets, 1005K bytes)
pkts bytes target prot opt in out source destination
20 1200 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 match-set AS54290 src
256 12854 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 match-set south_africa src
187 9524 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 match-set saudiarabia src
204 11012 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 match-set sprint src
5611 264K DROP all -- * * 0.0.0.0/0 0.0.0.0/0 match-set microsoft src
11 528 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 match-set afghanistan src
168 6820 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 match-set seychelles src
14602 818K DROP all -- * * 0.0.0.0/0 0.0.0.0/0 match-set ukraine src
1383 74766 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 match-set israel src
3514 181K DROP all -- * * 0.0.0.0/0 0.0.0.0/0 match-set indonesia src
333 18128 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 match-set locaweb src
471 23573 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 match-set africa src
42 2312 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 match-set countryblock-angola src
880 44061 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 match-set countryblock-hk src
1142 65621 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 match-set countryblock-jp src
15205 820K DROP all -- * * 0.0.0.0/0 0.0.0.0/0 match-set countryblock-cn src
67384 3878K DROP all -- * * 0.0.0.0/0 0.0.0.0/0 match-set spammers src
11M 996M ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 1147,8080,444,443,80,25,110
2510K 386M ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:3306
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:110
319K 216M ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 8891,10025
11M 60G ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
4733 283K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:11211
25 1284 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:4178
2772 111K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpts:12000:15000
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpts:12000:15000
2676 160K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:10023
375 21632 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:10023
59209 4392K ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53
165K 9876K ACCEPT tcp -- * * 127.0.0.1 0.0.0.0/0
108 4828 ACCEPT udp -- * * 127.0.0.1 0.0.0.0/0
13 520 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:10026
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:10026
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:3306
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:145
408 23984 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:143
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:10025
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:8891
3836 230K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:4949
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:4949

Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
127K 9296K ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53
10 463 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53
10M 61G ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport sports 25,110,143,80,8080,443,444,53,10023,10025,8891
11M 29G ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
374K 22M ACCEPT tcp -- * * 0.0.0.0/0 127.0.0.1
77 3557 ACCEPT udp -- * * 0.0.0.0/0 127.0.0.1
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:3306
1107 66220 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:25
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:110
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:4949
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:4949
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport sports 10026,8891,10025,53,12000:15000
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:8080
958 57400 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
29771 1786K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443
3783 227K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:4949
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:4949

iptables -L -n -v -t nat


iptables -L -n -v -t nat
Chain PREROUTING (policy ACCEPT 805K packets, 70M bytes)
pkts bytes target prot opt in out source destination

Chain INPUT (policy ACCEPT 237K packets, 14M bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 542K packets, 34M bytes)
pkts bytes target prot opt in out source destination

Chain POSTROUTING (policy ACCEPT 535K packets, 33M bytes)
pkts bytes target prot opt in out source destination
Оптимизайка:
Такое может быть, например, если соединение с этого ip уже было открыто, а вы добавили его позже,

Я, конечно, не Копенгаген, но....

1) появилась запись в логах

2) я добавил IP в чёрный список

на данный момент открытого соединения просто не может быть...

вопрос: как оно может быть сейчас? если адрес уже в черном списке?

Контроль пользователей в локальной Teredo server как? exim4 - исходящие письма
kxk
На сайте с 30.01.2005
Offline
970
kxk
#3

mark2011, IPSET пора уже забыть, я делаю так ip route add blackhole 31.46.0.0/16

15 к подсетей в бане и ничего неторомозит и банится в 100% случаев

Ваш DEVOPS
M2
На сайте с 11.01.2011
Offline
342
mark2011
#4

Ну что ж, ещё один такой IP...


Received: from 197-99-159-21.ip.broadband.is (197-99-159-21.ip.broadband.is [197.99.159.21])

Соответствующая IP подсеть: 197.96.0.0/13

ОК, блокаем.....


blacklist -i 197.96.0.0/13 -a list
This IP has been already blocked. No need to block again. Try to unblock instead

Уупсс..... может Скрипт не работает? Проверяем:


ip route | grep 197.96.0.0/13
blackhole 197.96.0.0/13

Да нет, всё так, IP в бане.... тогда какого...? Зачем вообще эта blackhole нужна, если спамеры сквозь нее только так...

Скрипт на bash для Скрипт проверки проиндексированности ссылки Запрет в htaccess на
M
На сайте с 17.09.2016
Offline
130
Mobiaaa
#5

IP мог забаниться, а соединение уже установлено

IP забанен, соединение отпало по таймауту, в лог упала строка

M2
На сайте с 11.01.2011
Offline
342
mark2011
#6
Mobiaaa:
IP мог забаниться, а соединение уже установлено

Т.е. всё так фантастические произошло, что я банил этот IP в тот момент, когда приходило это письмо. Только в этом случае описанное вами могло иметь место. Т.е. соединение пошло, я через секунду забанил IP, соединение отпало и в лог упала строка...

Ок, предположим. Хотя фантастика, достойная современных писателей...

1) Вот сейчас не поленился, посмотрел - письмо пришло 28.03.2019 в 14:46. Ну да, вот именно в 14:46 я сидел и банил именно этот IP-адрес...

Теоретически возможно. Но вариантов - 0,0000001%....

Но тогда такой вопрос...

Если я правильно понимаю, весь учёт ведётся по серверному времени. Т.е. по тому времени, которое установлено на сервере, где инсталлирован постфикс.

Ок, тогда если так, в логе должно что-то быть по этому поводу...

Вот выдержка из лога (старого):


Mar 28 14:45:05 vmd30300 dovecot: lda(crontab@kreine.com): msgid=<20190328134505.3D5BED0B3B3@mail.mir-otelej.ru>: saved mail to INBOX
Mar 28 14:45:05 vmd30300 postfix/pipe[20538]: 61D02D0A35C: to=<crontab@kreine.com>, relay=dovecot, delay=0.2, delays=0.14/0.02/0/0.04, dsn=2.0.0, status=sent (delivered via dovecot service)
Mar 28 14:45:05 vmd30300 postfix/qmgr[4181]: 61D02D0A35C: removed
Mar 28 14:51:52 vmd30300 postfix/smtpd[21222]: connect from mail03.info.pentontech.com[142.0.174.41]
Mar 28 14:51:52 vmd30300 postfix/smtpd[21223]: connect from mail01.info.pentontech.com[142.0.174.39]

Именно в это время была молчанка.... как такое может быть?

Единственное что - это письмо было обработано Spamassassin, а IP я добыл из исходников необработанного письма. Но спамассассин - это спам-фильтр, при чём здесь лог?!

Или... я что-то не понимаю? Может зря я баню 10к сетей?

---------- Добавлено 08.04.2019 в 20:10 ----------

Mobiaaa, и ещё. Хорошо, я допускаю, что "упала строка". Но даже если и так.... должно было тупо отпасть соединение.

Но письмо-то как могло упасть?! Строки, кстати, как раз нет.... а вот письмо - есть. Удивительно, вы не находите?

Особенности национальной интернет-статистики. Часть 50+ вещей, которые следует eTarget 2011: доклады пятнадцатой

Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий