iptables на удаленном сервере

https://serverfault.com/questions/273324/how-to-make-iptables-rules-expir
/thread

по крону можно запускать скрипт, который очищает правила. Или пишешь скрипт, в котором sleep четатам, далее iptables -I INPUT -j ACCEPT. Стартуешь этот скрипт, потом правишь правила...

https://serverfault.com/questions/273324/how-to-make-iptables-rules-expir

тоже интересно

iptables -I INTPUT -s xxx.xxx.xxx.xxx -m time --utc --datestart 2013-09-09T15:00 --datestop 2013-09-09T15:30 -j DROP

Короче методов куча...

всем спасибо

datestart 2013-09-09T15:00 --datestop 2013-09-09T15:30

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

А еще есть iptables-apply

а kvm нет?

Крон всё таки — запуск задач по расписанию. А для однократного запуска задачи через/в определенное время придуман другой специальный набор команд — at, atq, atrm. Там по крайней мере удобно задавать «запускать через» и удобно гасить ненужную уже задачу.

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

Не знаю, правильно это или нет, но до того момента пока у меня не было kvm я делал так:

создал bash-скрипт который удаляет все правила, а затем добавляет самые необходимые для доступа к серваку, обзовем его iptreset.sh, а потом уже игрался с правила в другом файле, ipttest.sh. Применял командой ./ipttest.sh; sleep 60; ./iptreset.sh, если доступ убился, то через минуту он восстанавливался. Если все в порядке - ctrl+c.

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

Это называется поиграться, а не подправить файрвол.

Крон надежнее.

Бгг. Вы понимаете, что такой аргумент равносилен высказыванию, что в системе работает некая магия, которая не всесильна и потому ненадёжна? Надёжность тут совсем не при чём. Речь о использовании инструментов по назначению. Крон может помочь, но он не для того, он предназначен чтобы постоянно, в течении долгого времени в определенное время запускать задачи. А «at» именно тот самый инструмент, специализированный. Можете взглянуть как делается тоже самое в cisco, так один в один: «reload at ...» :)

Надёжность тут совсем не при чём.

Вполне себе причем. Это защита от «самого себя», в случае повторной необходимости at можно забыть прописать еще раз, а так пока не закончили «шаманить» можно быть уверенным, что в случае факапа вернемся к исходному состоянию. И фв это только один из частных случаев затрагивающих сетевую подсистему.
Если вы считаете что вам достаточно at, я очень за вас рад, но лично я не люблю «дальние поездки», от ошибок никто не застрахован, а при «ковырянии сетевых настроек» перестраховка не может быть лишней.

Если вы считаете что вам достаточно at

Либо вы забываете at/cron, либо не забываете. Ибо в cron в точности также надо включить строку и её удалить, чтобы защититься от ошибки конфигурирования и от сброса правил при окончательном варианте файрвола. Следовательно вопрос в удобстве и использовании средств по назначению.

Еще раз, at разовая задача, cron цикличная, так понятнее?

Еще раз, at разовая задача

Именно. Запустили, поправили, проверили, выключили. Всё. Следующий цикл через неопределённое время. Или вы так cron и оставляете? Чтобы оно туда сюда включало-выключало дырявый-недырявый файрвол? Чтоб жизнь мёдом не казалась?

Через строчку читаем? Я не только про фв написал, да хотя бы и про него. Лишним цикл не будет, обращаю внимание на слово «цикл», да это перестраховка, но лучше так чем случайно ошибиться а потом забыть пнуть at еще раз.

Или вы так cron и оставляете?

Перед началом работы включаем, по окончании выключаем, так понятнее?

Лишним цикл не будет

Будет. По определению задачи. Нету цикла как такового, это выполнить административную задачу по необходимости. Это необходимости может никогда не возникнуть. Вы случайно в cron какой-нибудь «ls» не засовываете? А то, знаете ли часто приходится запускать. :)

Перед началом работы включаем, по окончании выключаем, так понятнее?

А я о чём уже четвёртый раз? Раз делать ровно тоже самое, то надо выбирать то что удобнее. Так вот, cron не удобен, там вообще нет ни «сделать через N времени от текущего» ни «один раз».

Похоже выражение «Дальняя поездка» вам не знакомо на личной практике.
ЗЫ Я конечно тоже лентяй, и для близких объектов (в пределах города) могу и полениться, но вот с удалением в сотни-тысячи километров лучше перестраховываться.

Похоже выражение «Дальняя поездка» вам не знакомо на личной практике

Похоже вам понятие «согласиться с возражением» не знакомо. Только ради этого дурацкого принципа вы изображаете тупизну, ибо до последнего идиота уже бы дошло, что с «дальней поездкой» при замене cron на at ничего не изменится, забыть набрать «at» можно ровно также как и забыть включить сброс по cron.