now it should support all the instructions of the old ipfw.
Fix some bugs in the user interface, /sbin/ipfw.
Please check this code against your rulesets, so i can fix the
remaining bugs (if any, i think they will be mostly in /sbin/ipfw).
Once we have done a bit of testing, this code is ready to be MFC'ed,
together with a bunch of other changes (glue to ipfw, and also the
removal of some global variables) which have been in -current for
a couple of weeks now.
MFC after: 7 days
This code makes use of variable-size kernel representation of rules
(exactly the same concept of BPF instructions, as used in the BSDI's
firewall), which makes firewall operation a lot faster, and the
code more readable and easier to extend and debug.
The interface with the rest of the system is unchanged, as witnessed
by this commit. The only extra kernel files that I am touching
are if_fw.h and ip_dummynet.c, which is quite tied to ipfw. In
userland I only had to touch those programs which manipulate the
internal representation of firewall rules).
The code is almost entirely new (and I believe I have written the
vast majority of those sections which were taken from the former
ip_fw.c), so rather than modifying the old ip_fw.c I decided to
create a new file, sys/netinet/ip_fw2.c . Same for the user
interface, which is in sbin/ipfw/ipfw2.c (it still compiles to
/sbin/ipfw). The old files are still there, and will be removed
in due time.
I have not renamed the header file because it would have required
touching a one-line change to a number of kernel files.
In terms of user interface, the new "ipfw" is supposed to accepts
the old syntax for ipfw rules (and produce the same output with
"ipfw show". Only a couple of the old options (out of some 30 of
them) has not been implemented, but they will be soon.
On the other hand, the new code has some very powerful extensions.
First, you can put "or" connectives between match fields (and soon
also between options), and write things like
ipfw add allow ip from { 1.2.3.4/27 or 5.6.7.8/30 } 10-23,25,1024-3000 to any
This should make rulesets slightly more compact (and lines longer!),
by condensing 2 or more of the old rules into single ones.
Also, as an example of how easy the rules can be extended, I have
implemented an 'address set' match pattern, where you can specify
an IP address in a format like this:
10.20.30.0/26{18,44,33,22,9}
which will match the set of hosts listed in braces belonging to the
subnet 10.20.30.0/26 . The match is done using a bitmap, so it is
essentially a constant time operation requiring a handful of CPU
instructions (and a very small amount of memmory -- for a full /24
subnet, the instruction only consumes 40 bytes).
Again, in this commit I have focused on functionality and tried
to minimize changes to the other parts of the system. Some performance
improvement can be achieved with minor changes to the interface of
ip_fw_chk_t. This will be done later when this code is settled.
The code is meant to compile unmodified on RELENG_4 (once the
PACKET_TAG_* changes have been merged), for this reason
you will see #ifdef __FreeBSD_version in a couple of places.
This should minimize errors when (hopefully soon) it will be time
to do the MFC.
fields as discussed in the commit to ip_fw.c:1.186
On top of this, a ton of non functional changes to clean up the code,
write functions to replace sections of code that were replicated
multiple times (e.g. the printing or matching of flags and options),
splitting long sections of inlined code into separate functions,
and the like.
I have tested the code quite a bit, but some typos (using one variable
in place of another) might have escaped.
The "embedded manpage" is a bit inconsistent, but i am leaving fixing
it for later. The current format makes no sense, it is over 40 lines
long and practically unreadable. We can either split it into sections
( ipfw -h options , ipfw -h pipe , ipfw -h queue ...)
or remove it altogether and refer to the manpage.
+ setting a bandwidth too large for a pipe (above 2Gbit/s) could
cause the internal representation (which is int) to wrap to a
negative number, causing an infinite loop in the kernel;
+ (see PR bin/35628): when configuring RED parameters for a queue,
the values are not passed to the kernel resulting in panics at
runtime (part of the problem here is also that the kernel does
not check for valid parameters being passed, but this will be
fixed in a separate commit).
These are both critical fixes which need to be merged into 4.6-RELEASE.
MFC after: 1 day
more on how ipfw(8) deals with tiny fragments. While we're at it, add
a quick log message to even let people know we dropped a packet. (Note
that the second FINE POINT is somewhat redundant given the first, but
since the code is there, leave the docs for it.)
MFC after: 1 day
time_to_xxx() and xxx_to_time() functions. e.g. _time_to_xxx()
instead of time_to_xxx(), to make it more obvious that these are
stopgap functions & placemarkers and not meant to create a defacto
standard. They will eventually be replaced when a real standard
comes out of committee.
reinserted by a userland process, will lose a number of packet
attributes, including their source interface. This may affect
the behavior of later rules, and while not strictly a BUG, may
cause unexpected behavior if not clearly documented. A similar
note for natd(8) might be desirable.
ipfirewall(4) to the IMPLEMENTATION NOTES section because it
considers kernel internals and may confuse newbies if placed
at the very beginning of the manpage (where it used to be previously.)
Not objected by: luigi
Fair Queueing) and RED (Random Early Detection) to both give the reader
a hint what they are and to make it easier to find out more information
about them.
addresses (and the macros that ipfw(4) use to lookup data for the 'me'
keyword have been converted) remove a comment about using 'me' being a
"computationally expensive" operation.
while I'm here, change two instances of "IP number" to "IP address"
+ implement "limit" rules, which permit to limit the number of sessions
between certain host pairs (according to masks). These are a special
type of stateful rules, which might be of interest in some cases.
See the ipfw manpage for details.
+ merge the list pointers and ipfw rule descriptors in the kernel, so
the code is smaller, faster and more readable. This patch basically
consists in replacing "foo->rule->bar" with "rule->bar" all over
the place.
I have been willing to do this for ages!
MFC after: 1 week
and speed. No new functionality added (yet) apart from a bugfix.
MFC will occur in due time and probably in stages.
BUGFIX: fix a problem in old code which prevented reallocation of
the hash table for dynamic rules (there is a PR on this).
OTHER CHANGES: minor changes to the internal struct for static and dynamic rules.
Requires rebuild of ipfw binary.
Add comments to show how data structures are linked together.
(It probably makes no sense to keep the chain pointers separate
from actual rule descriptors. They will be hopefully merged soon.
keep a (sysctl-readable) counter for the number of static rules,
to speed up IP_FW_GET operations
initial support for a "grace time" for expired connections, so we
can set timeouts for closing connections to much shorter times.
merge zero_entry() and resetlog_entry(), they use basically the
same code.
clean up and reduce replication of code for removing rules,
both for readability and code size.
introduce a separate lifetime for dynamic UDP rules.
fix a problem in old code which prevented reallocation of
the hash table for dynamic rules (PR ...)
restructure dynamic rule descriptors
introduce some local variables to avoid multiple dereferencing of
pointer chains (reduces code size and hopefully increases speed).
Avoid using parenthesis enclosure macros (.Pq and .Po/.Pc) with plain text.
Not only this slows down the mdoc(7) processing significantly, but it also
has an undesired (in this case) effect of disabling hyphenation within the
entire enclosed block.
information for any command line error, the actual error message
almost always (and sometimes irretrievably) lost scrolling off the top
of the screen. Now just print the error. Give ipfw(8) no arguments for
the old usage summary.
Thanks to Lyndon Nerenberg <lyndon@orthanc.ab.ca> for the patch and
PR, but I had already done this when ru pointed out the PR.
PR: bin/28729
Approved by: ru
MFC after: 1 week
but list them if -d was specified).
Avoid listing expired dynamic rules unless the (new) -e option was specified.
If specific rule numbers were listed on the command line, and the -d flag was
specified, only list dynamic rules that match the specified rule numbers.
Try to partly clean up the bleeding mess this file has become. If there is
any justice in this world, the responsible parties (you know who you are!)
should expect to wake up one morning with a horse's head in their bed. The
code still looks like spaghetti, but at least now it's *properly intented*
spaghetti (hmm? did somebody say "tagliatelle"?).
rules. Also, don't show dynamic rules if you only asked to see a
certain rule number.
PR: 18550
Submitted by: Lyndon Nerenberg <lyndon@orthanc.ab.ca>
Approved by: luigi
MFC after: 2 weeks
address is configured on a interface. This is useful for routers with
dynamic interfaces. It is now possible to say:
0100 allow tcp from any to any established
0200 skipto 1000 tcp from any to any
0300 allow ip from any to any
1000 allow tcp from 1.2.3.4 to me 22
1010 deny tcp from any to me 22
1020 allow tcp from any to any
and not have to worry about the behaviour if dynamic interfaces configure
new IP numbers later on.
The check is semi expensive (traverses the interface address list)
so it should be protected as in the above example if high performance
is a requirement.
reserved and now allocated TCP flags in incoming packets. This patch
stops overloading those bits in the IP firewall rules, and moves
colliding flags to a seperate field, ipflg. The IPFW userland
management tool, ipfw(8), is updated to reflect this change. New TCP
flags related to ECN are now included in tcp.h for reference, although
we don't currently implement TCP+ECN.
o To use this fix without completely rebuilding, it is sufficient to copy
ip_fw.h and tcp.h into your appropriate include directory, then rebuild
the ipfw kernel module, and ipfw tool, and install both. Note that a
mismatch between module and userland tool will result in incorrect
installation of firewall rules that may have unexpected effects. This
is an MFC candidate, following shakedown. This bug does not appear
to affect ipfilter.
Reviewed by: security-officer, billf
Reported by: Aragon Gouveia <aragon@phat.za.net>
It also squashes 99% of packet kiddie synflood orgies. For example, to
rate syn packets without MSS,
ipfw pipe 10 config 56Kbit/s queue 10Packets
ipfw add pipe 10 tcp from any to any in setup tcpoptions !mss
Submitted by: Richard A. Steenbergen <ras@e-gerbil.net>
Packets that match a tee rule should not be immediately accepted,
but should continue going through the rule list. This may be fixed
in a later version.
I hope to fix this soon in a separate commit.
using syslog(3) (log(9)) for its various purposes! This long-awaited
change also includes such nice things as:
* macros expanding into _two_ comma-delimited arguments!
* snprintf!
* more snprintf!
* linting and criticism by more people than you can shake a stick at!
* a slightly more uniform message style than before!
and last but not least
* no less than 5 rewrites!
Reviewed by: committers
_or_ you may specify "log logamount number" to set logging specifically
the rule.
In addition, "ipfw resetlog" has been added, which will reset the
logging counters on any/all rule(s). ipfw resetlog does not affect
the packet/byte counters (as ipfw reset does), and is the only "set"
command that can be run at securelevel >= 3.
This should address complaints about not being able to set logging
amounts, not being able to restart logging at a high securelevel,
and not being able to just reset logging without resetting all of the
counters in a rule.
can't have a dash character (it is treated as a ``range'' operator).
One could now use such a name by escaping the ``-'' characters.
For example:
# ipfw add 1 count tcp from any to any "ms\-sql\-s"
# ipfw add 2 count tcp from any ftp\\-data-ftp to any
PR: 7101
+ add a missing call to dn_rule_delete() when flushing firewall
rules, thus preventing possible panics due to dangling pointers
(this was already done for single rule deletes).
+ improve "usage" output in ipfw(8)
+ add a few checks to ipfw pipe parameters and make it a bit more
tolerant of common mistakes (such as specifying kbit instead of Kbit)
PR: kern/10889
Submitted by: Ruslan Ermilov
This allows for more flexible ipfw configuration files using
`variables' to describe frequently used items in the file, like the
local IP address(es), interface names etc. Both m4 and cpp are useful
and supported; with m4 being a little more unusual to the common C
programmer, things like automatic rule numbering can be achieved
fairly easy.
While i was at it, i've also untangled some of the ugly style inside
main(), and fixed a bug or two (like not being able to use blank lines
when running with -q).
A typical call with preprocessor invocation looks like
ipfw -p m4 -Dhostname=$(hostname) /etc/fwrules
Someone should probably add support for this feature to /etc/rc.firewall.
Any packet that can be matched by a ipfw rule can be redirected
transparently to another port or machine. Redirection to another port
mostly makes sense with tcp, where a session can be set up
between a proxy and an unsuspecting client. Redirection to another machine
requires that the other machine also be expecting to receive the forwarded
packets, as their headers will not have been modified.
/sbin/ipfw must be recompiled!!!
Reviewed by: Peter Wemm <peter@freebsd.org>
Submitted by: Chrisy Luke <chrisy@flix.net>
not reinitialized to 1 after calling getopt. This results in parsing
errors on all but the first rule. An added patch also allows '#'
comments at the end of a line.
PR: 6379
Reviewed by: phk
Submitted by: Neal Fachan <kneel@ishiboo.com>
offset is non-zero:
- Do not match fragmented packets if the rule specifies a port or
TCP flags
- Match fragmented packets if the rule does not specify a port and
TCP flags
Since ipfw cannot examine port numbers or TCP flags for such packets,
it is now illegal to specify the 'frag' option with either ports or
tcpflags. Both kernel and ipfw userland utility will reject rules
containing a combination of these options.
BEWARE: packets that were previously passed may now be rejected, and
vice versa.
Reviewed by: Archie Cobbs <archie@whistle.com>
consequence, ipfw's list command now adjusts its output at runtime
based on the largest packet/byte counter values.
NOTE:
o The ipfw struct has changed requiring a recompile of both kernel
and userland ipfw utility.
o This probably should not be brought into 2.2.
PR: 3738
accommodate the expanded name, the ICMP types bitmap has been
reduced from 256 bits to 32.
A recompile of kernel and user level ipfw is required.
To be merged into 2.2 after a brief period in -current.
PR: bin/4209
Reviewed by: Archie Cobbs <archie@whistle.com>
these are quite extensive additions to the ipfw code.
they include a change to the API because the old method was
broken, but the user view is kept the same.
The new code allows a particular match to skip forward to a particular
line number, so that blocks of rules can be
used without checking all the intervening rules.
There are also many more ways of rejecting
connections especially TCP related, and
many many more ...
see the man page for a complete description.
This will make a number of things easier in the future, as well as (finally!)
avoiding the Id-smashing problem which has plagued developers for so long.
Boy, I'm glad we're not using sup anymore. This update would have been
insane otherwise.
do it themselves. (Some of these programs actually depended on this
beyond compiling the definition of struct ifinfo!) Also fix up some
other #include messes while we're at it.
firewalls are remote, and this command will kill the network connection
to them), prompt the user for confirmation of this command.
Also, add the '-f' flag which ignores the need for confirmation the
command, and if there is no controlling tty (isatty(STDIN_FILENO) !=0)
assume '-f'.
If anyone is using ipfw flush in scripts it shouldn't affect them, but you
may want to change the script to use a 'ipfw -f flush'.
Reviewed by: alex
now completely consistent across all IP protocols and should be quite a
bit faster.
Use getprotoname() extensively, performed minor cleanups of admin utility.
The admin utility could use a good kick in the pants.
Basicly, these were the minimal changes I could make to the code
to get it up to tollerable shape. There will be some future commits
to clean up the basic architecture of the firewall code, and if
I'm feeling ambitious, I may pull in changes like NAT from Linux
and make the firewall hooks comletely generic so that a user can
either load the ipfw module or the ipfilter module (cf Darren Reed).
Discussed with: fenner & alex
This stuff should not be too destructive if the IPDIVERT is not compiled in..
be aware that this changes the size of the ip_fw struct
so ipfw needs to be recompiled to use it.. more changes coming to clean this up.
Prevent ALL protocol from being used with port specifications.
Allow 'via' keyword at any point in the options list. Disallow
multiple 'via' specifications.
of /0 to have the desired effect. Normalize IP addresses that
won't match a given mask (i.e. 1.2.3.4/24 becomes 1.2.3.0/24).
Submitted by R. Bezuidenhout <rbezuide@mikom.csir.co.za>
Code formatting and "frag" display fixes.
- Filter based on ICMP types.
- Accept interface wildcards (e.g. ppp*).
- Resolve service names with the -N option.
- Accept host names in 'from' and 'to' specifications
- Display chain entry time stamps with the -t option.
- Added URG to tcpflags.
- Print usage if an unknown tcpflag is used.
- Ability to zero individual accounting entries.
- Clarify usage of port ranges.
- Misc code cleanup.
Closes PRs: 1193, 1220, and 1266.
is a pain in ...wel.. trying to fix this
* from/to/via position indepenndant syntax
* "any" for 0/0 host address
* addf/addb default keyword in case you skip it..
* pass = accept new action, seems to be somewhat better
in particular cases
* on = via (as on ed0 instead of via ed0,loook at
reject tcp on ed0 from hacker )
ports for the destination IP addr/port.
Nobody reported this btw , while a lot of other things reported-
probably ppl does not use destination ports at all????
We have only one firewall chain and one accounting chain now.
No blocking/forwarding so commands changed.
Man pages are somewhat out of date and will be updated ASAP.
that the english in Ugen's two replacement pages is not too impenetrable! :-)
[Note: Poul - please pull these into the BETA branch along with the
other firewall changes]
Submitted by: ugen
