FreeBSD настройка pf

Искать чтолибо подозрительное здорово помогает tcpdump, а еще в pf есть pflog. Думаю начинать надо с анализа трафика, это даст понимание одкуда лезет mail трафик :)

Про настройку pf писать ... както рука не подымается. Он же такой простой что ппц. Что там неясно может быть? iptables в разы мудренее в настройке :(

FAQ PF - http://www.openbsd.org/faq/pf/index.html

Отличные примеры настройки - https://calomel.org/pf_config.html

Я прочитаю мануалы, освежу память по pf, но насколько я помню, именно мой случай решается не столь легко. В отличии от iptables - где такая задача решается очень, очень легко.

tcpdump - использовал, несколько недель половил - ничего подозрительного. Выключил. А оно вон как... Снова прилетело.

Включи логирование в PF

Потом tcpdump -r будеш файлики с логами анализировать.

Уточни что нужно? Чтобы твой шлюз выпускал SMTP трафик (TCP/25, TCP/587) только на один хост - mail.server.net ? Или что?

Логирование в pf - не хочу включать, ибо не хочу ковырять рабочий шлюз. Там не всё так просто чтобы включить его - надо перезагружаться и т.д.

Смотри: нужно запретить исходящие соединения на порт 25 ВСЕМ в локальной сети (включая сам сервер шлюза), за исключением сервера почты который находится в локальной сети (т.е. за NAT, который работает на шлюзе с FreeBSD).

Сейчас у меня всем запрщено соединение на порт 25, за исключением: сервера почты который находится в локальной сети, и самого шлюза на FreeBSD.

Так вот есть подозрение, что FreeBSD взломан. Надо ему тоже запретить соединение на порт 25, но при этом, чтобы мой «легитимный» сервер мог посылать почту в мир.

Сча попробую смоделировать у себя.

Ок! Буду рад! То есть фактически задача стоит так (в терминах iptables): разрешить транзитный (FORWARD) трафик, запретив при этом локальный трафик (OUTPUT).

Блин, простыми методами не получается, а кардинально менять конфиг PF на рабочем серваке тож неохота.

А уложить apache не вариант? Или чемто его заменить, nginx-ом например. Может и простое обновление/пересборка поможет.

Вот и я про тоже... Что не всё так просто, и простыми методами я не знаю как исправить ситуацию... По этому я пришёл на форум собственно. :)

Да дело в том, что apache и всё прочее там уже нафиг не нужно давно. Сейчас там процессов то отсилы с десяток (httpd нету среди них). Из нужных служб: только маршрутизирует трафик, немного фаерволит, и openvpn там крутится с mpd на пару... Ну и ещё один демон.

В общем у меня такое подозрение, что: в своё время сломали apache, подзакинули мне туда скриптов... И теперь скрипты просыпаются раз в очень редко, и моя машинка становится участником ботнет сети.

Пока запилил вот такое:

# crontab -l
@daily		killall tcpdump ; tcpdump -i sk0 src host gw.xxx.ru and dst port smtp > "/var/log/tcpdump-`date`"

И аналогичную команду запилил на почтовом сервере в лок. сети:

@daily		killall tcpdump ; tcpdump -i eth1 src host mail.xxx.ru and dst port mail > "/var/log/tcpdump-`date`"

Ну теперь надеюсь, что у меня будут посуточные логи... И я когда в очередной раз попаду в CBL (а попаду я похоже в него полюбому...), посмотрю чего там написано в плане времени про мой ip, и таким образом смогу посмотрев логи tcpdump понять, с какой машины у меня идёт спам. Или с почтовика, или действительно шлюз поломан.

Что я ещё могу сделать? Как вариант, конечно я могу поставить новый шлюз... Но не очень хочется этого делать (из-за vpn в частности...). Там openvpn 1.x стоит с кучей сертификатов.

Может быть у Вас есть идеи? Как мне пока прикрыть попу по максимуму? :)

Закрыть на вход с инета все кроме нужного!

Анализ логов, ломонули скорее всего либо то что показывал apache (CMS, самопись или что там было) либо VPN учетку. Анализировать логи OpenVPN, MPD до просветления. Прошерстить всю систему на предмет новых непонятных фаликов. Начать с cron и всяких там rc.local.

Включить нормально логирование PF (или оно выпиляно с ядра????)

в /etc/rc.conf

pflog_load="YES"
pflog_enable="YES"
pflog_logfile="/var/log/pflog"

и потом подгрузить модуль

kldload pflog

Ну и натыкать log по всем правилам :)

Надо ковыряться :) Может сервачок был звломан через нашумевшую уязвимость OpenSSL раз вы говорите что там VPN с сертами???

Во взлом SSH слабо верится, хотя могли и туда пароль подобрать.

Создать новую учетку для админа (например myadmin) и подкорректировать /etc/ssh/sshd_config такими опциями

PermitRootLogin no
AllowUsers myadmin

После чего передернуть ssh

# service sshd restart

А вот и решение вашего вопроса :) Кстати мне тоже интересно было узнать :) Оказалось надо чуток пошаманить с таблицей маршрутизации чтобы сам шлюз заставить проходить фильтрацию PF

http://forum.lissyara.su/viewtopic.php?f=4&t=34886

Я предполагаю, что сломали через web морду для мейла (очень старая была там софтина NOCC или как-то так...), очень уже давно. Как только я стал так предполагать - я нафиг всё убрал. ssh - уже много лет назад я закрыл. openvpn - кхм... У меня openssl 0.9.8. Оно не подвержено уязвимости вроде.

По ссылке посмотрю что там за решение. :) СПАСИБО!

pflog_load="YES"
pflog_enable="YES"
pflog_logfile="/var/log/pflog"

После подгрузки модуля, это сразу подхватится? Перезагружаться не нужно будет? :)

Кхм... Решил сделать вот так покамест:

tcpdump -i eth1 'tcp[tcpflags] & (tcp-syn|tcp-fin) != 0 and src host mail.xxx.ru and dst port mail' > "/var/log/tcpdump-`date`" &

Почему-то оно скидывает в файл только когда убиваю процесс. Что я мог сделать не так? :)

Ну плохо серваку от этого точно не станет, пробуйте! Должно!

Ок. Пока попробую всё же с tcpdump поиграться. Ибо у меня на шлюзе FreeBSD, на почтовом сервере: linux.

В том плане, что мне нужно смотреть трафик на двух хостах (чтобы понять кто виновен из этих хостов). А это удобнее через tcpdump наверно. А не скидывает он у меня в файл, видимо по тому, что его внутренние буферы не заполнены ещё. У меня пока чёт народ не очень хочет почту отправлять.

Попробовал у себя только что :)

Да! Все создается и работает как надо!

Почему-то оно скидывает в файл только когда убиваю процесс. Что я мог сделать не так?

-l Make stdout line buffered. Useful if you want to see the data while capturing it

Ок! Спасибо! Ну пока я половить решил всё же tcpdumpом. Я думаю в целом разница не принципиальна. Понятное дело, что настроив корректно pf на шлюзе я смогу тогда ловить трафик и записывать его в лог (сразу как трафик с почтового сервера с внтуренним ip, так и трафик уже сгенерированный на внешнем ip). Пока ограничусь tcpdump.

Вот чего у меня примерно вышло:

Вот такое добавил в крон на раз в сутки:

@daily killall tcpdump ; tcpdump -i eth1 'tcp[tcpflags] & (tcp-syn|tcp-fin) != 0 and src host mail.xxx.ru and dst port mail' > «/var/log/tcpdump-`date`»

Ну а потом можно вот так:

root@mail:~# less /var/log/tcpdump-Пн.\ июня\ 16\ 15\:49\:20\ MSK\ 2014 |grep -w "[S]"
15:51:04.206663 IP mail.xxx.ru.56074 > mx.yandex.ru.smtp: Flags [S], seq 1237946009, win 14600, options [mss 1460,sackOK,TS val 1643555758 ecr 0,nop,wscale 7], length 0
15:51:10.393721 IP mail.xxx.ru.49968 > mxs.mail.ru.smtp: Flags [S], seq 1791546069, win 14600, options [mss 1460,sackOK,TS val 1643557305 ecr 0,nop,wscale 7], length 0
...

И плюс можно подсчитать кол-во строк!

Например так:

# less /var/log/tcpdump-Пн.\ июня\ 16\ 15\:49\:20\ MSK\ 2014 |grep -w "[S]" -c
35

Взяв логи за сутки и сделав такой подсчёт, можно будет увидеть разницу между SYN соединениями со шлюза на FreeBSD, и с сервера почты в лок. сети. - Если будет разница - значит шлюз явно заражён. Если не будет разницы, а будут просто очень большие цифры - стало быть почтовик таки рассылает спам, и возможно в логах postfix это не отражается... Быть может там левая какая-то программа появилась, и мой linux почтовик взломан. Или какая-то машина заражённая в локалке пользуется тем, что у меня локалка пропеисанная в доверенные хосты, и использует меня как relay... - Блин, надо бы убрать тоже локалку из доверенных, старое наследие приходится сопровождать.

Как считаете, не налажал нигде я? По 587 порту по идее не должна же почта ходить? Оно же только для авторизованного submission...

Победа!

На тестовом стенде так вот настроил и заработало как надо!

Есть клиент в LAN с Linux Debian - IP 10.1.20.30

Есть тестовый шлюз с FreeBSD 9.1 и PF в качестве firewall/nat

Клиент имеет default gw -> FreeBSD LAN

INET_IF = "em0"
INET_LOCAL = "em1"

set skip on lo0

nat on $INET_IF proto tcp from self to any port 25 tag IM3 -> lo0
nat on $INET_IF from {10.1.20.30} to any -> $INET_IF

block in  log all
block out log all

pass out log quick on $INET_IF route-to (lo0 127.0.0.1) tagged IM3 no state
pass out log on $INET_IF inet proto tcp from $INET_IF to any port 25 keep state
### <= SMTP =>
pass in log on $INET_LOCAL inet proto tcp from 10.1.20.30 to any port 25 keep state

И в таком виде на Linux машинке:

root@deb3:~# telnet 88.81.237.70  25
Trying 88.81.237.70...
Connected to 88.81.237.70.
Escape character is '^]'.
220 MAIL.META.UA (Corporate mail server META.UA) ESMTP Mon, 16 Jun 2014 15:34:51 +0300
quit
221 mail.meta.ua closing connection
Connection closed by foreign host.
root@deb3:~#

В то время как на самом шлюзе:

[root@ns ~]# telnet 88.81.237.70 25
Trying 88.81.237.70...
telnet: connect to address 88.81.237.70: No route to host
telnet: Unable to connect to remote host
[root@ns ~]#

Надеюсь поможет!

Спасибо! Я искал в man tcpdump по слову buffer, но так-как ман большой, дальше ключа B, я не ушёл. :) Работает. Ну мне опять же в целом это не принципиально на самом деле. :)

Вооо..! Толково! Вот этого я и хотел. :)

Попробую поковырять этот момент. Не очень уверен, что это будет правда всё работать на:

FreeBSD 7.2-STABLE.

Будет повод обновиться (:

разрешить NAT на 25 порт, но, при этом запретить локально сгенерированный трафик на 25 порт?

возможно тегирование поможет. а может и нет.

block all
match out on $ext_if inet proto tcp from <lan> to any nat-to em1
pass in on $int_if inet proto tcp from <mail> to any port 25 tag MAILTAG
pass out on $ext_if inet proto tcp from $ext_if to any port 25 tagged MAILTAG

block out log quick on egress from !(self) to any port smtp

UPD: как же я люблю pf за его лаконичность!

И так! В первом приближении всё получилось (правда потребовался reboot, ну и добавил в конфиг опции quick, чтобы логи велись). Ну и за одно почистил сервер, отключил всякие не нужные службы, и отключил пользователя: www и прочих. Через команду: pw. Насколько это корректный путь интересно? :)

Теперь имею:

gw#telnet smtp.yandex.ru smtp
Trying 93.158.134.38...

root@mail:~# telnet smtp.yandex.ru smtp
Trying 213.180.193.38...
Connected to smtp.yandex.ru.
Escape character is '^]'.
220 smtp4h.mail.yandex.net ESMTP (Want to use Yandex.Mail for your domain? Visit http://pdd.yandex.ru)

Выражаю крайне большую БЛАГОДАРНОСТЬ! Сам бы я долго петрил как надо настроить мне pf...

Несколько хуже дело обстоит с pflog. Там вот какая история: оно же не пишет day в time stamp... А мне бы оно пригодилось.

И пишет только S пакеты. Мне большего то и не нужно. Однако timestamp не очень удобный.

18:34:50.905360 IP localdomain.61501 > smtp.yandex.ru.smtp: S 830882917:830882917(0) win 65535 <mss 1460,nop,wscale 3,sackOK,timestamp[|tcp]>

В ротации лога стоит нечто:

/var/log/pflog                          600  3     100  *     JB    /var/run/pflogd.pid

То есть ротация по размеру, а не по дням... Осталось только подумать как мне сделать ротацию по дням через newsyslog. Так что пока оставлю то, чего я там наколбасил в cron. Хуже не будет. Ну и поколдую с ротацией по дням.

СПАСИБО ещё раз за потраченное время!

Я пока тред не буду закрывать, так-как есть ещё парочка мелких моментов, малоли чего...

Будет чего мне завтра почитать ... :) Про newsyslog

 when    The when field can consist of an interval, a specific time, or
             both.  If the when field is an asterisk (`*') log rotation will
             depend only on the contents of the size field.  Otherwise, the
             when field consists of an optional interval in hours, optionally
             followed by an `@'-sign and a time in a restricted ISO 8601 for-
             mat or by an `$'-sign and a time specification for logfile rota-
             tion at a fixed time once per day, per week or per month.

             If a time is specified, the log file will only be trimmed if
             newsyslog is run within one hour of the specified time.  If an
             interval is specified, the log file will be trimmed if that many
             hours have passed since the last rotation.  When both a time and
             an interval are specified, the log will be trimmed if either con-
             dition is met.

             There is no provision for specification of a timezone.  There is
             little point in specifying an explicit minutes or seconds compo-
             nent in the current implementation, since the only comparison is
             `within the hour'.

Через pw рулить юзерами более чем корректно!

Про дату/время pflog не очень понял. У tcpdump есть хитрые опции для отображения дат. -t -tt -ttt -tttt, ну это то что в голове, в man возможно больше про это написано :) Оно?

quick это для того чтобы не идти дальше по цепочке а сразу пропустить пакет если он удовлетворил данное правило. Это к логам никакого отношения не имеет :) Вам нужен ключик log в правилах

http://www.openbsd.org/faq/pf/filter.html

newsyslog - это же элементарно! Скопируйте готовую строчку с того же конфига для другого сервиса. Думаю что это подойдет:

/var/log/pflog  600  14   * @T00 JB /var/run/pflogd.pid

Ключик log есть. Похоже я просто нетерпелив, и не дождался пока оно свалится в лог просто... Оно валится с заметной задержкой. Про quick я знаю, просто я подумал, что раз его нету, то и пакет уходит дальше. - У меня там просто есть другие критерии дальше, которые тоже удовлетворят пакет. По сему решил - что лог не будет задействован и дописал quick.

newsyslog - согласен конечно, что не сложно. Пока сделал так:

 /var/log/pflog                          600  30    10240 $D0   JB    /var/run/pflogd.pid

Так и не понял почему пишется только S пакет в лог. Это нормально? Вроде где-то видел, что так и должно быть.

Про pw что-то знаете? Насколько интересный инструмент в моей ситуации?

И ещё: по не совсем понятной мне причине у меня поднимаются множество процессов sendmail после reboot (с какими ключами я не смотрел правда, ибо испугался... Не хочу я больше быть спамером. ). Хотя в rc.conf я убрал всякое упоминание о нём. - Собственно, первоначально меня насторожило, что у меня 100500 процессов sendmail... -От того и предположил, что я взломан. Но эти 100500 процессов появились после того (предположительно), как я перенёс почтовый сервер с этого древнего шлюза на новый linux сервер (до этого я никогда не был в спам листах (более 7ми лет)). После того (предположительно), как я отключил exim живший на FreeBSD, у меня стало появляться туча процессов sendmail... - При том эти процессы sendmail никуда вроде не спамили, а просто висели (не помню от кого правда они были запущены...). Блин, надо родителя этих процессов было посмотреть... - Ну ладно, теперь всё позакрыто так что Бог с ним.

Уф... Извиняюсь, если я всё мешаю в кучу. Уже у меня поток сознания наступает похоже... :) Спасибо за помощь!

Про pw написал выше - нормально! Про логи в pflog - фиг знает :) Я логирую только block правила, а там syn-ы дропнутые да UDP бесхозные ... и все :)

Если сейчас sendmail или любая другая прога порождает кучу процессов - нужно разбираться, это ненормально. Ковыряйтесь! Главное что сервак какать в инет перестал, а в остальном потихоньку розгребетесь!

Ой. Сорри, про pw не заметил.

Да, спасибо огромное, что всячески мне помогли. Буду разбираться чего там у меня приключилось. Конечно когда попадаешь в такую ситуацию впервые - страшновато... Особенно когда понимаешь, что ты слишком поздно заметил что у тебя что-то пошло не так и резервные копии не помогут.

Я просто подумал, что sendmail может быть вызван из других демонов, может кто-то мне хотел какие-то логи отправить и не смог. Там предыдущий сис. администратор настраивал что-то подобное, но на середине пути бросил.

Всякое может быть, локальную почту тоже както надо доставлять. Копайтесь :)

Сегодня утром:

IP Address xxx.xxx.xxx.xxx is listed in the CBL. It appears to be infected with a spam sending trojan, proxy or some other form of botnet.


It was last detected at 2014-06-17 01:00 GMT (+/- 30 minutes), approximately 4 hours, 30 minutes ago.

Так то вот... Кажется в целом я нашёл подозрительную машинку, которая ходит у нас через wifi. Ну теперь таки у меня дошли руки повесить исходящий NAT на другой ip адрес (отличный от PTR записи). - Выпороть меня нужно. Согласен. Да. Так уже было сделано много лет назад. У меня руки не доходили. Теперь дошли. Ну на всякий случай я также закрою и на шлюзе порт 80 исходящий. Теперь то я уже умею это делать. :)

Логи у меня теперь ведутся исправно (ещё раз спасибо за помощь в борьбе с pf). Ротируется всё как надо. - Ничего подозрительного я там не нашёл.

Кстати если есть несколько внешних ip один можно выдать только для mail сервака с помощью pf и binat. В инете есть примеры выдачи реального ip клиентам с помощью FreeBSD+PF на форумах сетевиков.

В целом фряху нужно обновить хотябы до 9.2 или заменить Linux-ом :) Я уже замахался своих чертенков обновлять, мигрирую потихоньку на Debian.

Кажется в целом я нашёл подозрительную машинку, которая ходит у нас через wifi

Завирусованный хост-спамер за натом? Сейчас таких вирусов все меньше, но еще достаточно много

Вот такие правила для pf блокируют хосты которые создают слишком много соединений на 25-й порт. Обычные пользователи работают нормально

pass  in log on $int_if proto tcp from any to any port 25 keep state (max-src-conn 100, max-src-conn-rate 10/60, overload <int_spam_hosts> flush)
block in log on $int_if proto tcp from <int_spam_hosts> to any port 25
pass in on $int_if proto tcp from <mail_servers> to any port 25 keep state

ip-адреса жертв-спамеров можно потом просматривать командой «pfctl -t int_spam_hosts -T show»

Пока у меня всё ещё становится веселее...

CBL отписало мне, что похоже я в ботнете, и мне нужно провериться - не ходит ли у меня кто-нибудь на некий зловредный ip адрес, а именно: 216.66.15.109

Ну что-ж... Сказано - сделано! Запускаем tcpdump и видим... А видим мы нечто..! На этот адрес ходит машинка:

WinXP SP3 , пользователь с ограниченными правами, с установленными апдейтами (правда не всеми конечно), с полноценно работающим антивирусным ПО.

А теперь БИНГО! На этой машине нет Интернет, на этой машине не прописан прокси сервер. Этот ip адрес не значится ни в каких таблицах NAT. С этой машины не ходят пинги на внешние источники, не открываются никакие внешние сайты. Не делается tracerout и всё подобное на внешние адреса.

И tcpdump показывает, как на протоколе tcp/ip эта машинка устанавливает соединение с указанным выше адресом.

ЧТО ПРОИСХОДИТ?!

Стоп, я вру!

13:47:23.081532 IP xxx.local.3885 > sinkhole-iad1-1.cwg.fsi.io.http: S 1909379065:1909379065(0) win 16384 <mss 1460,nop,nop,sackOK>
13:47:26.058518 IP xxx.local.3885 > sinkhole-iad1-1.cwg.fsi.io.http: S 1909379065:1909379065(0) win 16384 <mss 1460,nop,nop,sackOK>

Дальше S оно не уходит. Что явно свидетельствует, о том, что оно заблочено.

Внимание, вопрос: какого чёрта у меня на внешнем интерфейсе tcpdump видит ещё не про NATченый адрес вида xxx.local?

Я удивлён. Могу конечно выложить правила pf, но у меня там всё стандартно в целом.

какого чёрта у меня на внешнем интерфейсе tcpdump видит ещё не про NATченый адрес вида xxx.local?

Я конечно тот еще сетевик, но ИМХО - такого быть не должно! А зачем вообще машинкам в LAN ходить по 25-му порту через NAT если у вас в локалке есть mail сервер? Или я чтото не доганяю? Заблочить всем 25-й порт в мир, после чего разрешить только mail серверу.

Это я уже давно сделал. Когда-то у меня была возможность ходить и по 25му порту.

Там был чисто административный вопрос. - У кучи начальников был настроен почтовый клиент в своё время, на 25 порт всяких там мейл.ру и прочего шлака. Это было давно. Но с той поры так и осталось. Сейчас всё пофиксил.

Червь то ломится на порт 80. А не через, 25. :(

В общем и целом разобрался. Значит так: на внешнем интерфейсе появляется непроначенный адрес, если ему запрещён NAT. - Я уже сообразил как это происходит... Надо подумать как прикрыть это дело. У меня разрешён весь исходящий трафик со шлюза. А так-как шлюз является маршрутизатором, то приходящий пакет из лок. сети, попадает на firewall, firewall то его не NATит, но и не откидывает. Следовательно пакет улетает на маршрут по-умолчанию, а это шлюз провайдера моего Интернет. Вестимо с источником - внутреннего адреса! - Это ФЕЙЛ! Так уже было до меня, я просто особо не вникал...

Как такое фиксят во FreeBSD? Что-то там было такое, что запрещало такое безобразие в одно правило...

Другой вопрос, что CBL банит всех участников крупных ботнетов. То есть быть реальным спамером вовсе не обязательно!

P.S. я уже отыскал часть машин - участниц ботнета. Которые имеют выход в Интернет. - Это древнючие компьютеры за заводских линиях...

А так разве не сработает? В /etc/pf.conf пишем

table <ddos> persist

Ну и первым правилом firewall сделать

block in quick on $LAN_IF from <ddos> to any

# pfctl -t ddos -T add 10.10.10.111

Или так не работает?

Сработает конечно. :) У меня также сейчас белый список и работает. Другое дело, что этот шлюз за одно является ещё и маршрутизатором, и таким образом у меня люди не смогут ходить в другие подсети. Там мне кажется было что-то специально более умнее.

Я на своих серваках задолбался уже бороться со всякими крякерами и досерами/ддосерами ... CBL както помогает с ними бороться? Не в курсе случаем???

А в каком плане задолбался бороться? От почтового спама - эта штука точно очень эффективна.

Бороться с досерами..? Она только для почты же. Если посмотреть в CBL, там наверно почти весь Интернет домашний сидит + всякие модемщики там же... Ты хочешь бороться от чего? Если ты прикрутишь CBL к apache - то у тебя на сайт никто из хомячков не зайдёт. А куда его ещё прикручивать? Защищать ssh, и другие сервисы - я думаю стоит явно другими методами. Порткнокингами, vpn и прочими решениями.

В плане почты - тоже не всегда всё гладко, то есть надо мудрить с белыми списками в крайнем случае. Но на сегодняшний день, если рассматривать бюджетную (а это считай бесплатная защита) защиту от спам - то альтернатив пожалуй нету. Ну или хоститься на почте для домена у всяких Яндекс или мейлов. - Но как-то пока не очень здорово переливать к ним 300гигов нашей почты.

Ну мало ли ... я думал они комплексно на Инет както влияют. А blacklisting для почты - это я знаю.

Тема у вас интересная, сам много чего узнал, за это спасибо!

А вот кстати, это надо прочитать на сайте у этих ребят. Там очень много чего написано, написаны в том числе и различные криетрии, я пока правда так и не понял, как они определили, что я участник ботнета, и указали мне конкретный ip, куда я ходил в качестве его участника... Надо разобраться по-хорошему! У них кстати есть специальный email на который можно отписать, и в ответном письме придёт полный лог smtp сессии - таким образом можно очень много чего узнать и поотлаживать (ну это правда для совсем не опытных я думаю больше). Хотя тотже DKIM и SPF можно вполне проверить! Так что есть смысл вникнуть!

Пока читал Ваше сообщение, стало у меня в памяти проясняться нечто связанное с такой штукой в pf как antispoof! - Вот благодаря этой фишке не должны появляться пакеты с src адресом локальной сети на внешнем интерфейсе. И мне кажется, что у меня это когда то было это правило. У вас есть что-то для этого? Кинете может? Хотя это уже конечно в мануалах хорошо расписано, надо освежить память. Но на самом деле, то, что у меня появлюятся на внешнем интерфейсе пакеты с src моей локальной сети - это ничего страшного, так-как любой более или менее вменяемый провайдер такие пакеты дальше своего маршрутизатора не пустит. Там ребята грамотные, и знают что такое spoof. Однако, за такой фейл, они могут когда-нибудь покрутить пальцем у виска для сис.админа... - Ведь никто не запрещает им логировать от меня такую активность, но скорее всего опасаться нечего, и эти пакеты просто «умирают», вопрос конечно как они умирают, могут по RST, но похоже они просто DROPаются.

Да я и сам очень много интересного узнал. А главное нашёл проблему!

Меня очень поразило, что человек с форума не просто кинул ссылки на мануалы, и ушёл. А действительно понял суть вопроса, смоделировал ситуацию, и всячески и с душой принял участие, что в Интернет ну крайняя редкость..! Так что спасибо и Вам! Ещё страниц десять пообщаемся, звёзд нахватаем. :)

В общем про antispoof тоже можно немного уже поразвивать тему. Посмотрите на своём шлюзе, нет ли у Вас там такого фейла как у меня часом. :) А то может в Job не только мне одному пора..? :)

Ну просто мне в свое время очень нравилась OpenBSD вцелом и PF в частности. Всегда считал его достойным и простым фаерволом, а тут такое дело - простая вещь, а сделать не знаю как :) Вобщем задело.

Что касается antispoof - насколько знаю, не во всех версиях PF оно есть, пробуйте. Седьмой фри у меня под руками точно нигде нету :)

DROP не DROP пакетов, это фигня, круче blackhole, во FreeBSD делается примерно так:

/sbin/route add 192.168.0.1 127.0.0.1 -blackhole

Что касается помочь и все такое - да тема интересная, PF нравится, хоть ответа и не знал, зацепило ... ну и решил разобраться. Всегда пожалуйста ... на то он и Open Source чтоб друг другу помогать кто чем может :) Альтруизм в IT чистейшей воды!

Значит так: на внешнем интерфейсе появляется непроначенный адрес, если ему запрещён NAT. - Я уже сообразил как это происходит... Надо подумать как прикрыть это дело. У меня разрешён весь исходящий трафик со шлюза. А так-как шлюз является маршрутизатором, то приходящий пакет из лок. сети, попадает на firewall, firewall то его не NATит, но и не откидывает. Следовательно пакет улетает на маршрут по-умолчанию, а это шлюз провайдера моего Интернет. Вестимо с источником - внутреннего адреса! - Это ФЕЙЛ! Так уже было до меня, я просто особо не вникал...

Ну по логике нужно было изначально сделать так (ну или теперь можно переделать):

Создать в PF таблицу в которой будут хосты/сети VPN-ов или местных нужных роутов:

table <vpn> {10.10.10.100 10.15.15.100 192.168.100.0/24 172.15.100.0/24}

Создать таблицу для тех кому запрещаем Интернет, но разрешаем VPN и локальные роуты (допустим сеть LAN у нас это сеть 192.168.1.0/24):

table <no_inet> {192.168.1.13 192.168.1.72}

Ну и дальше просто запрещаем на LAN интерфейсе все что идет НЕ на таблицу vpn, тоесть по сути должно пойти в инет:

block in quick from <no_inet> to !<vpn>

Думаю так должно дать внутренние коммуникации, но запретить все что не внутрянка.

P.S. Повторюсь что сетевик я неособо сильный, поэтому с удовольствием выслушаю мнение знатоков :)