ssh pfctl -f

[Гость]

по ssh захожу на сервер после чего правлю конфиг pf.conf делаю pfctl -f /etc/pf.conf и всё сразу обрыв и пинг до сервера пропадает .... причём невсегда такое бывает тоесть может и нормально правила подгрузить... в чём может быть проблема ?

[Хостинг HostFood.ru]

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

[Base]

в правилах, которые блокируют траф до машины.
проверяйте корректность правил.
уже сколько раз использовал

Код: Выделить всё

pfctl -f

ниразу не слетал

[Гость]

set skip on rl0 прописано какие ещё правила нужны это моя локалка я по ней и подрубаюсь

[Base]

Лучше было бы весь конфиг увидеть

[Гость]

в логе вот такое нашёл после pfct -f /etc/pf.conf

Код: Выделить всё

May 28 18:41:37 xren sshd[4437]: fatal: Write failed: Operation not permitted

[Shuba]

по ssh захожу на сервер после чего правлю конфиг pf.conf делаю pfctl -f /etc/pf.conf и всё сразу обрыв и пинг до сервера пропадает .... причём невсегда такое бывает тоесть может и нормально правила подгрузить... в чём может быть проблема ?

Значит правила кривые и блокируют трафик. Вообще при правке конфига фаера удалённой машины следует поставить в крон через минут 10-15 отключение фаерволла (pfctl -d). Соответственно при кривых правилах через 10 минут их можно будет подправить.

[Гость]

правила некривые если сделать reboot после изменения и посмотреть вывод dmesg -a то там всё путём фаер грузится и работает....что неужели никто несталкивался может я ssh настроил как то неправильно ? и даже если ошибка в конфиге он просто недолжен загрузить правило как я понимаю....

[Shuba]

правила некривые если сделать reboot после изменения и посмотреть вывод dmesg -a то там всё путём фаер грузится и работает....что неужели никто несталкивался может я ssh настроил как то неправильно ? и даже если ошибка в конфиге он просто недолжен загрузить правило как я понимаю....

если пропали пинги - то значит дело в правилах.

[Shuba]

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

[Гость]

ладно объясню подругому..... судя повсему совсем за идиота держат...... захожу на сервер на нём уже включен фаервол всё прекрасно работает....ради интереса ничего в правилах не меняю!!!!! просто набираю команду sudo pfctl -f /etc/pf.conf ВСЁ П....ДА !!!!!! что на это скажеш ?

[Shuba]

На это скажу, вылаживай сюда pf.conf и rc.conf

[Shuba]

И в догонку почитай здесь

[Гость]

вроде как решил проблему подругому сначала отключаю фаер pfctl -d потом перезагружаю праивила и включаю изврат но работает....

[Saddy]

Точно такая же проблема, при старте все правила грузятся нормально, а при pfctl -f /etc/pf.conf все виснет, пинг до машины пропадает.

/var/log/messages

Mar 26 22:12:37 isrv sshd[6083]: fatal: Write failed: Operation not permitted

pf.conf

Код: Выделить всё

bee_if="ue0"
bee_vpn="ng0"
bee_gw="10.22.8.1"
spark_if="ue1"
spark_gw="10.67.229.233"
cts_gw="192.168.0.1"
lan_if="re0"
lan_net="192.168.0.0/24"
icmp_types="{ echoreq, unreach }"
NoRouteIPs = "{ 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, \
   10.0.0.0/8 }"

set block-policy return

set skip on lo0
set skip on $lan_if

scrub in

nat on $bee_if from $lan_net to !(self) -> ($bee_if)
nat on $bee_vpn from $lan_net to !(self) -> ($bee_vpn)
nat on $spark_if from $lan_net to !(self) -> ($spark_if)

antispoof quick for $bee_if
antispoof quick for $bee_vpn
antispoof quick for $spark_if

block all #deny for default

pass out on $bee_if keep state
pass out on $bee_vpn keep state
pass out on $spark_if keep state

rc.conf

Код: Выделить всё

dhcp_program="/usr/local/sbin/dhclient"

gateway_enable="YES"
hostname="isrv.local"
ifconfig_re0="inet 192.168.0.254 netmask 255.255.255.0"
ifconfig_ue0="SYNCDHCP"
ifconfig_ue1="SYNCDHCP"
defaultrouter="192.168.0.1" #spark

pf_enable="YES"                 # Включить PF (Подгрузить модуль, если требуется)
pf_rules="/etc/pf.conf"         # Откуда подгружать правила для pf
pf_flags=""                     # дополнительные флаги для управляющей программы pfctl(8)
pflog_enable="YES"              # запуск pflogd(8) (система журналирования)
pflog_logfile="/var/log/pflog"  # где pflogd должен хранить журнал
pflog_flags=""                  # дополнительные флаги для pflogd

firewall_enable="YES"
firewall_type="open"

mpd_enable="YES"

ntpdate_enable="YES"
ntpdate_flags="ru.pool.ntp.org"
scrnmap="koi8-r2cp866"
sshd_enable="YES"
# -- sysinstall generated deltas -- # Sun Mar 20 07:11:14 2011
font8x8="cp866-8x8"
font8x14="cp866-8x14"
font8x16="cp866b-8x16"

P.S. Спасибо за вариант с отключением перед загрузкой правил, будет полегче...

[receptor]

Только на исходящих правилах ни одно входящее работать не будет.
Странно что всё отваливается, правда?

[Saddy]

Только на исходящих правилах ни одно входящее работать не будет.
Странно что всё отваливается, правда?

прочитайте внимательнее правила (set skip on $lan_if в частности) и сообщения выше, в которых указано что правила рабочие. Проблема в зависании при перезагрузке правил, а не при их применении.

В постах выше дана ссылка (http://www.mail-archive.com/freebsd-sec ... 00376.html) на попытку объяснить это дело, потерей динамической таблицы keep-state текущего подключения ssh, но там же сомневаются в этом. Так что итогового разъяснения проблемы нет.

[BlitzKrieg]

Не знаю как работает pf, никогда с ним дел не имел.
Рискну предположить следующее.
Когда вы даете команду на реконфигурирование pfctl сначала делает flush, что вызывает обрыв подключения и завершение сеанса командного интерпритатора в котором выполняется этам команда и, соответственно, она прекращает выполняться. Именно по этой причине вы получаете в логе сообщение от sshd про Operation not permited.
Тут кстати возможны варианты, я с подобным сталкивался на Ipfw, там могли правила примениться, а могли и нет. Все зависело от того, на сколько быстро завершится процесс после обрыва.
Решение - использовать nohup.

[Saddy]

Проблема в том что параметр -f специально предназначен для перезагрузки параметров "на лету". Пока проблема решается выключением/включением pf (pfctl -d; pfctl -e)
-f file
Replace the current ruleset with the rules contained in file.
This file may contain macros, tables, options, and normalization,
queueing, translation, and filtering rules. With the exception
of macros and tables, the statements must appear in that order.

[BlitzKrieg]

Про полет это вы сами придумали. Параметр -f всего лишь указывает загрузить правила из файла. И делает он это как я описал выше. Вы хоть попробовали бы nohup Для приличия. Я вам описал, что происходит при выполнении pfctl -f что из написанного мною не понятно?

[BlitzKrieg]

Сами попробуйте после применения pftcl -f зайдите локально и посмотрите список правил, с вероятность 99% он будет пуст.

[Saddy]

Есть "неписаное" правило общения на форуме - если вы не в курсе того о чем спрашивают, не знаете или не имеете опыта - не стоит влазить.
flush выполняется отдельно, другой командой.

[BlitzKrieg]

Давайте по существу моих рекомендаций, общение на форуме тема отдельаня меня она не интересует.
а вы nohup проверили?
Я еще раз говорю я с pf Дела не имел, не знаю как там чего делается. flush Это я примерно написал. слово flush я использовал как англоязычный вариант сброса, который привычно используется в таких случаях во многих программах. Я по нему доки не читал. Но уверен, что перед тем как загрузить новый список правил старые нужно сбросить. Не так ли?

[Saddy]

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

[BlitzKrieg]

Не путайте, я ответил на сегодняшний пост. Так как судя по нему вы с проблемой не разобрались.
Подобные сообщения sshd вы легко сможете получить и с ipfw если сбросите правила при ssh подключении это из моего опыта и знаний. Если интересно, могу рассказать почему, этого по вашей ссылке нет.
Вобщем не хочу вас уговаривать использовать nohup в таких случаях, судя по вашим ответам вы и сами очень грамотны. До того, что читаете маны между строк и находите некий режим смены правил НАЛЕТУ.
Как проверите nohup напишите.

[Saddy]

Да, это не ты оказывается ответил, но скажу тебе прямо - опция -f загружает правила на лету - это проверено и работает у большинства людей (см. например второй пост этой темы) и если в манах есть команда отдельно сброса таблиц и отдельно загрузки правил - то любой может догадаться как это работает. Но в некоторых, редких случаях, происходит такой сбой, настолько редкий что информации о нем в инете не находится, поэтому был задан вопрос тут. Даже достаточно опытные люди в рассылке freebsd-security@freebsd.org не смогли определиться с причиной.
Кроме того, я достаточно давно не пользовался ipfw, но достаточный опыт использования имеется, но тем не менее - не встречал подобной проблемы.

И еще раз повторяю, если нет знаний или опыта по теме топика - не флуди зря бесполезными постами.

Для тех кто заглянет в эту тему с таким же вопросом - подытожу:
Временный, 100% рабочий вариант - делайте pftcl -d потом pfctl -e -f
Если хотите докопаться до истины - можете попробовать убрать правила с keep-state/estabilished или попробовать сбрасывать таблицы (pfctl -F xxxx) перед загрузкой правил