See inline
thanks for answering
Ont thing you need to understand is that I tend to run ipfw with a
front-end.
for example which is more efficient:
cat <<-DONE |ipfw -q -f /dev/stdin
add 1 (some rule}
[100 other operations including table and pipe operations and
more rules]
DONE
vs
ipfw -f -q add 1 (some rule)
ipfw -f -q {operation}
[...] 100 more ops, same as above..
obviously the first is orders of magnitude more efficient.
I have wondered if you could feed a script into ipfw's preprocessor
feature so that it actually generated data instead of just filtering it,
but I haven't tried it yet..
In the version I wrote for Cisco, it is a python program that is
continually manipulating hte firewall by adding and removing table
entries and rules as the world changes around it.
So having to not for/exec a new copy of ipfw for every operations i
important to me.
Maybe we want to add a special mode (-I - ) to allow stdin to be used.
using /dev/stdin is a hack.
and there is no way to get any output back.
I actually have a way to make it work as a shell script using netcat...
The server part that stays resident does:
action ()
{
local LINE="$*"
logger -p user.info -t firewall "command $LINE"
set $LINE
local COMMAND=$1
shift
case ${COMMAND} in
setup-firewall)
# called from rc.d/postpixel8 and from rc.conf via
ip_filter_rules.sh
setup_firewall $*
;;
[... lots of other commands ]
if [ $MODE = "server" ]
then
FIREWALL_DISABLED=
nc -U -k -l "$CONTROL_SOCKET" | while read LINE
do
action $LINE
done
logger -p user.info -t firewall "Server loop ended"
exit 0 # server never goes below this point
fi
and the client just does:
if [ "$MODE" = "client" ]
then
echo $COMMAND $* | nc -N -U $CONTROL_SOCKET
fi
sending high level commands to the server,
and the server, keeps state, and feeds commands out via stdout to a
copy of ipfw that is started at the time the server starts, and keeps
running until it quits, doing ALL the low level 'ipfw' commands..
this mode of operation if very efficient and can lead to very
sophisticated active firewalls as the server has local state about hte
firewall and can manipulate it with great speed and accuracy.
anyhow.. to do this I need that the ipfw program not quit every time
it gets something it doesn't like.
Especially things like "clear a rule without havng to first test
whether it is there".
or swap with a new table.. (just create an empty table of the same kind).
Or pretty much anything else that would error out.. e.g. I want most
delete commands to be "optionally" idempotent.
calling it should be ok regardless of whether the
rule/table/pipe/whatever already exists or has already been deleted.
Like rm -f .
Maybe a special mode for running as a client may be good.. or maybe
ipfw is in control and fires off a given program and controls both
stdin and stdout.
that way the script/progra can actually get feedback. Something I've
had a hard time doing..
also some ways to get events from the firewall would be amazing.
Maybe what I want is a libipfw.so, but I want to be able to use it
with shell scripts.
On 4/5/18 6:23 am, Alexander V. Chernikov wrote:
02.05.2018, 06:32, "Julian Elischer" <jul...@freebsd.org>:
On 2/5/18 1:05 am, Julian Elischer wrote:
On 1/5/18 11:03 pm, Rodney W. Grimes wrote:
Many years ago I added code to ipfw so that if -q was set it would
not
complain about
things that were unimportant, nor would it return an error code.
Such things include removing table entries that are already gone and
similar sorts of 'safe' operations.
The idea is that you can write 'naive' scripts that don't need to do
complicated checks to see if XXX is already present or gone..
In hte ame way that rm -f doesn't complain if the file doesn't
exist..? You were going to delete it anyhow.
I'd like that to continue to some of the new additions.
for example the terribly annoying
??? ipfw: DEPRECATED: inserting data into non-existent table 18.
(auto-created) (who cares?)
and
?? ljcc-78# ipfw table 19 create
???? ipfw: Table creation failed: File exists
As the script needs to run multiple times, I don't care if the table
already exists.
but I do care about other errors.
I don't want to have to write special wrapper code for table create
that is different
from the wrappers elsewhere because it has to look for return code 71
and disregard it.
Can we just have -q continue to ignore such errors please?
I think there is a bigger question here, why was auto table creation
with first insert "Deprecated" at all? This to me just seems like
change cause someone could change it that has no usefull purpose or
is there some great purpose this serves?
In the "old" world we had single type of tables, each of them name by numbers
from 1.. ip.fw.tables_max range. If the table number was less than ip.fw.tables_max - it
automatically existed. If not, one had to increase ip.fw.tables_max.
In the new world, number of different table types / configuration is pretty
large. Additionally, one can use string names as table identifiers.
In most cases, user wants to have "old" kind of table with default values, but
it might not always be the case. Let's suppose one wants to have special kind of table,
but forgots to create it. Then, silently creating default table upon insertion will
simply hide an error leading to undesired hard-to-dianose behaviour on later stages.
Same with creation of an already existing file, why did that need
to become a noisy warning/error?
Well ther eis an argument (that I disagree with in this case) that
any unexected even is an error..
Also the new tables can have many different key type and indexing
algorithms, which need to be declared up front.
but I don't see that raising a fatal error for trying to delete
something that doesn't exist or make something that already exists
really helps much other than to make scripts more complicated.
That's why I made it optional before.. Removing table entries that
are not present could be an error you want to know about, but
probably it isn't.
The question here is what is the desired level of "smartness" ipfw(8) should
implement. Traditionally it was a pretty low-level tool, used by other scripts/tools to
manipulate the ruleset. In that case then generic idea is that we should propagate the
error, so one can handle it properly in the upper layer.
Unless the upper layer has asked that certain classes (the idempotent
class, e.g. delete or I suggest 'create') of commads do not generate
that sort of error.
my biggest issue is that it bombs out when you are using it as a filter.
e.g. (manual simulation)
I understand your frustration. The original changeset for the named tables was
pretty big and I was mostly focused on fixing the kernel and providing backward
compatibility, so some of the ipfw(8) stuff were not though thoughtfully. Let's
discuss/agree on the desired behaviour and fix it.
well imagine my aim ... to pipe stuff to ipfw.
anything that helps tha goal is my friend and anything that makes my
scripts have to cope with things like ipfw suddenly dying is my enemy :-)
whether we use stdin, stdout, file descriptor 10 through 12, unix
domain sockets, or fifos is all up for discussion.
32Ssd# ipfw -q -f /dev/tty <---- -q "don't complain and quit on
unimportant things -f "trust me I know what I'm doing"
I always thought of "-q" meaning as mostly "Be quiet when executing ..." as ipfw(8)
manual states, which is different from the generic "ignore errors".
I totally agree that having some way of saying "ignore the error and continue" is a thing
we should have. Probably, adding another option for that would be an overkill, so we indeed can
rebrand "-q".
it was never "ignore errors" It's "ignore a certain class of error".
table 3 add 1.1.1.1
table 3 add 1.1.1.1 <- no error.. this is what I want..
table 20 add 2.2.2.2
table 3 swap 20
table all list
--- table(3), set(0) ---
2.2.2.2/32 0
--- table(20), set(0) ---
1.1.1.1/32 0
table 3 swap 21 <-- doesn't quit, but doesn't generate a new
just give me an empty table of the same type.
or make table create not die if we call it twice.
empty 21 either :-(
What is the "proper" behaviour from your pov here? (with and without -q)?
without -q probably an error with -q swap in an empty table
table all list
--- table(3), set(0) ---
2.2.2.2/32 0
--- table(20), set(0) ---
1.1.1.1/32 0
table 21 create
table 21 create <------ this shouldn't quit.. actually I
This shouldn't quit IFF "-q" is supplied and the already-created table is
absolutely the same in terms of types, algorithms and values?
certainly that would qualify as idempotent
wouldprefer that I didnt NEED to make the damned things. Any reference
should make it.. (e.g. swap)
Line 6: Table creation failed: File exists
32Ssd#
"congratulations the parent process now has to restart it.."
The Cisco/Ironport "Web Security Appliance" ran like this, with a
python process feeding commands into a single instance of ipfw.
I don't know if it still does (Doug Ambrisko may know). I use this
method of running ipfw regularly, as forking and exec-ing a new copy
of ipfw for every firewall operation is a huge waste of resources when
you have a dynamic firewall that is constantly adding and removing
table entries and rules, as well as doing load control with dummynet.
Last thing I need is for ipfw to start quitting on operations that
should be idempotent.
interestingly the man page no longer shows how to run with input from
a file in hte synopsis (though it refers to it)
LIST OF RULES AND PREPROCESSING
To ease configuration, rules can be put into a file which is
processed
using ipfw as shown in the last synopsis line. An absolute
pathname must
be used. The file will be read line by line and applied as
arguments to
the ipfw utility.
errr, no such example.
I think I will look into adding a -F option to allow for input from
a file or stdin..
and make it shut the heck up in that mode (implies -q and -f)
as mentioned above...
and whether it's
fire off a script that runs a copy of ipfw,
or run ipfw and have it run the script is a legitimate question..
ipfw --run-master /usr/local/bin/firewallmaster
(yes I know we don't have long args)
Julian
_______________________________________________
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
_______________________________________________
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
_______________________________________________
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
