Автор Гілка: Блокування реціпієнтів postfix по діапазону IP  (Прочитано 183 раз)

Відсутній ps

  • Дописувач
  • **
  • дописів: 55
  • Карма: +0/-0
Помітив що postqueue -p виводить заблоковані фаєрволом черги типу connect to smtp.site.com[xxx.xxx.xxx.xxx]:25: Connection timed out
звісно, тут треба фіксанути програму, яка це робить але чи можу я заблокувати потенційні спроби відправки на стороні postfix?
чи це так не працює і спочатку потрібен додатковий резольв домену?

конкретно у цьому випадку я хочу дозволити відправку тільки на 0200::/7 (включно з MX що на ці хости посилається)



Це поліз в
smtpd_recipient_restrictions =
    check_recipient_access cidr:/etc/postfix/outbound_allowlist

згенерив
postmap /etc/postfix/outbound_allowlist
0200::/7               PERMIT
0.0.0.0/0              REJECT
::/0                   REJECT

перезавантажився
Цитата
systemctl reload postfix

але щось до лампи - все одно йдуть черги на відправку, може криві правила?
« Змінено: 2025-12-01 08:57:44 від ps »

Відсутній yvs115

  • Кореспондент
  • ***
  • дописів: 239
  • Карма: +7/-0
Не зовсім ясно чи заблокувати-дозволити вихідну пошту (зазвичай тоді дозволи на домени не ip адреси), чи надсилання пошти через якийсь зовнішній сервер (нп сервер прова з такимто ip). У другому випадку це зазвичай називається щось на зразок smarthost relay proxy etc. (з sendmail термінологією - smarthost, для інших не пам'ятаю).
Хоча з postfix мало працював - але по назві check_recipient_access - схоже на вхідні правила для кого приймати пошту у власному домені.
Сonnect to smtp.site.com[xxx.xxx.xxx.xxx]:25: Connection timed outЦе говорить найбільш ймовірно що десь 25-й порт скоріш усього зафайрволено з drop а не з reject, і зазвичай так прови закривають щоб юзера (чи вірусняк на юзер компах) не спамили, тобто буде висіти поки не затаймаутиться по tcp (спроби конектів при reject зразу би відбилися).
« Змінено: 2025-12-01 10:08:22 від yvs115 »

Відсутній ps

  • Дописувач
  • **
  • дописів: 55
  • Карма: +0/-0
Так, вище написав, що вісить фаєрвол на відлов подібної активності.

Сервер SMTP локальний, хочу сікти спроби на рівні postfix, а не останнім рубіжем. Але дякую, мабуть так, треба резольвити і складати в базу айпішників. Тоді буду на рівні клієнтської проги фільтрувати бо сабж йде звідти.
« Змінено: 2025-12-01 11:30:46 від ps »

Відсутній ps

  • Дописувач
  • **
  • дописів: 55
  • Карма: +0/-0
Сьогодні вирішив розібратись що за *й вісить на фаєрволі. Те що я замаскував вище було:
(connect to mr.kolo.net[65.19.147.89]:25: Connection timed out)
Поліз в /var/spool/postfix/deferred і знайшов у черзі таку шнягу:
彃††††††㌵‵††††††㐲‶†††††††‱†††††††‰††††††㌵‵†††††††吰ㄑ㘷㘴㤶〶‱〶㌹㈸ᙁ牣慥整瑟浩㵥㜱㐶㘶㘹㄰ᕁ敲牷瑩彥潣瑮硥㵴潬慣䙬䌊潲䑮敡潭卮爇潯䁴慵ു湥潣楤杮㠽楢䅴搜湳潟楲彧捲瑰爽捦㈸㬲潲瑯畀佡爄潯剴爇潯䁴慵M⡎敒散癩摥›祢甠⁡倨獯晴硩‬牦浯甠敳楲⁤⤰㕎椉⁤㍁䉆㈵㔰㔹※畔ⱥ†′敄⁣〲㔲ㄠ㨲〰〺‱〫〲‰䔨呅丩䘛潲㩭爠潯䁴慵⠠牃湯䐠敡潭⥮୎潔›潲瑯畀乡匾扵敪瑣›牃湯㰠潲瑯潀慲杮灥灩灣畬㹳⼠獵⽲扳湩瀯獯獴灵牥ⴠ⁤䱁乌䴑䵉ⵅ敖獲潩㩮ㄠ〮❎潃瑮湥⵴祔数›整瑸瀯慬湩※档牡敳㵴呕ⵆ丸䌟湯整瑮吭慲獮敦⵲湅潣楤杮›戸瑩᭎ⵘ牃湯䔭癮›匼䕈䱌⼽楢⽮桳举堘䌭潲⵮湅㩶㰠佈䕍⼽潲瑯举堠䌭潲⵮湅㩶㰠䅐䡔⼽獵⽲楢㩮戯湩举堚䌭潲⵮湅㩶㰠佌乇䵁㵅潲瑯举䴪獥慳敧䤭㩤㰠〲㔲㈱㈰〱〰㄰䄮䘳㕂〲㤵䀵慵举䐫瑡㩥吠敵‬㈠䐠捥㈠㈰‵㈱〺㨰㄰⬠㈰〰⠠䕅⥔Nᵎ潰瑳畳数㩲䐠汥瑥摥›‱敭獳条塥䄀攍据摯湩㵧戸瑩E

От вам і не закривай вихідні конекти, і не знав би. Зараз почну з clamav, але чешу репу що я такого міг поставити. Це мабуть з npm чи pip поналазило. Ну або такий бінарь в репозиторії мого дистрибутиву. Я цю гидоду вже десь бачив, лишилось вияснити звідки вона.

UPD. знайшов причину.
« Змінено: 2025-12-02 15:16:19 від ps »

Відсутній yvs115

  • Кореспондент
  • ***
  • дописів: 239
  • Карма: +7/-0
Цитата
От вам і не закривай вихідні конекти, і не знав би.
Зазвичай це вхідні правила у прова - від своїх кастомерів/юзерів на свій сервер дозволити 25й порт, на решту адрес поза своїм smtp-сервером дропнути.

Тобто якшо не налаштований нп вихідний сервер на relaying - то і будуть висіти там конекти. То справедливо і для нормального трафіка і для ненормального.
У випадку роботи з налаштованим вихідним сервером (тобто коли не напряму пуляєте пошту на mx) - те саме відносно _всього_ поштового трафіка на вихід. З різницею що вся пошта (і нормальна і спам) проходило би через релей прова - поки пров чи побачив би чи отримав би скаргу і оперативно закрив би від такого кастомера.

Цитата
Це мабуть з npm чи pip поналазило.
І це до речі як приклад пакетного хаоса який приходить разом з інтегрованими пакадж-менеджерами з мовами програмування (perl, python, node, dart, rust, etc.), коли доволі важко зорієнтуватися що там натягало і наставило автоматом з тоннами пакетних залежностей.
« Змінено: 2025-12-02 18:59:35 від yvs115 »

Відсутній ps

  • Дописувач
  • **
  • дописів: 55
  • Карма: +0/-0
Сьогодні довольний чекнув postqueue -p а воно знов там вісить! Правда не кожної години а опівночі. Опівночі в мене тільки бекап через rsync.

Навіть тепер не знаю, може зараза в самих пакетах - потягнув з репозиторіїв... Може хто пікаже які само логи копнути щоб знайти процес що відправив цей лист?

Воно ймовірно таки лізе від кронтаб, точніше з його завдань серед яких я бачу в syslog тільки системні (окрім rsync)

2025-12-03T00:00:01.729912+02:00 CRON[11091]: (root) CMD (/usr/lib/armbian/armbian-truncate-logs)
2025-12-03T00:00:01.793468+02:00 CRON[11093]: (root) CMD (/usr/lib/armbian/armbian-apt-updates)
2025-12-03T00:00:01.804319+02:00 CRON[11095]: (root) CMD (/usr/bin/rsync -av --delete /var/www/.. ..)
2025-12-03T00:00:02.099000+02:00 postfix/pickup[10916]: 163E420FC5: uid=0 from=<root>
2025-12-03T00:00:02.144055+02:00 postfix/cleanup[11132]: 163E420FC5: message-id=<20251202220002.163E420FC5@ua>
2025-12-03T00:00:02.164204+02:00 postfix/qmgr[1821]: 163E420FC5: from=<root@ua>, size=684, nrcpt=1 (queue active)

де 163E420FC5 в mail.log:

2025-12-03T03:06:05.785563+02:00 postfix/smtp[27592]: 163E420FC5: to=<root@ua>, orig_to=<root>, relay=none, delay=11164, delays=11103/0.19/60/0, dsn=4.4.1, status=deferred (connect to mr.kolo.net[74.123.227.137]:25: Connection timed out)
« Змінено: 2025-12-03 06:35:47 від ps »

Відсутній BeSiDa

  • Кореспондент
  • ***
  • дописів: 155
  • Карма: +1/-0
Коли не лінь можете тимчасово замінити сендмейл (чи через що там відправляється?) своєю прогою (шелом) і записати все що в пам'яті висить на той час.

Відсутній ps

  • Дописувач
  • **
  • дописів: 55
  • Карма: +0/-0
Слушна думка своїм скриптом дампнути! Зараз вимкну ще одну підозрілу тулзу на пайтоні, може в ній бекдор, якщо не вона - спробую..

Я це ще думаю, може клієнт (DeltaChat зі своїм Node.JS) шле таку активність... хоча опівночі поштовий клієнт не підключався до SMTP.
« Змінено: 2025-12-03 06:15:18 від ps »