contain O_UID, O_GID and O_JAIL opcodes, the F_NOT or F_OR logical
operator bits get clobbered. Making it impossible to use the ``NOT'' or
``OR'' operators with uid, gid and jail based constraints.
The ipfw_insn instruction template contains a ``len'' element which
stores two pieces of information, the size of the instruction
(in 32-bit words) in the low 6 bits of "len" with the 2 remaining
bits to implement OR and NOT.
The current code clobbers the OR and NOT bits by initializing the
``len'' element to the size, rather than OR'ing the bits. This change
fixes this by changing the initialization of cmd->len to an OR operation
for the O_UID, O_GID and O_JAIL opcodes.
This may be a MFC candidate for RELENG_5.
Reviewed by: andre
Approved by: luigi
PR: kern/63961 (partially)
keyword but without 'logamount' limit the amount of their log messages
by net.inet.ip.fw.verbose_limit sysctl value.
RELENG_5 candidate.
PR: kern/46080
Submitted by: Dan Pelleg
MFC after: 1 week
Since the only thing truly unique about a prison is it's ID, I figured
this would be the most granular way of handling this.
This commit makes the following changes:
- Adds tokenizing and parsing for the ``jail'' command line option
to the ipfw(8) userspace utility.
- Append the ipfw opcode list with O_JAIL.
- While Iam here, add a comment informing others that if they
want to add additional opcodes, they should append them to the end
of the list to avoid ABI breakage.
- Add ``fw_prid'' to the ipfw ucred cache structure.
- When initializing ucred cache, if the process is jailed,
set fw_prid to the prison ID, otherwise set it to -1.
- Update man page to reflect these changes.
This change was a strong motivator behind the ucred caching
mechanism in ipfw.
A sample usage of this new functionality could be:
ipfw add count ip from any to any jail 2
It should be noted that because ucred based constraints
are only implemented for TCP and UDP packets, the same
applies for jail associations.
Conceptual head nod by: pjd
Reviewed by: rwatson
Approved by: bmilekic (mentor)
For incoming packets, the packet's source address is checked if it
belongs to a directly connected network. If the network is directly
connected, then the interface the packet came on in is compared to
the interface the network is connected to. When incoming interface
and directly connected interface are not the same, the packet does
not match.
Usage example:
ipfw add deny ip from any to any not antispoof in
Manpage education by: ru
o Add sanity checking to the firewall delete operation
which tells the user that a firewall rule
specification is required.
The previous behaviour was to exit without reporting any
errors to the user.
Approved by: bmilekic (mentor)
mac ipfw rules. The exact same sanity check is performed as
the first operation of add_mac(), so there is no sense
in doing it twice.
Approved by: bmilekic (mentor)
PR: bin/55981
source address of a packet exists in the routing table. The
default route is ignored because it would match everything and
render the check pointless.
This option is very useful for routers with a complete view of
the Internet (BGP) in the routing table to reject packets with
spoofed or unrouteable source addresses.
Example:
ipfw add 1000 deny ip from any to any not versrcreach
also known in Cisco-speak as:
ip verify unicast source reachable-via any
Reviewed by: luigi
rule, thus omitting the entire body.
This makes the output a lot more readable for complex rulesets
(provided, of course, you have annotated your ruleset appropriately!)
MFC after: 3 days
if_xname, if_dname, and if_dunit. if_xname is the name of the interface
and if_dname/unit are the driver name and instance.
This change paves the way for interface renaming and enhanced pseudo
device creation and configuration symantics.
Approved By: re (in principle)
Reviewed By: njl, imp
Tested On: i386, amd64, sparc64
Obtained From: NetBSD (if_xname)
of do_cmd() broke things, because this function assumes that a socklen_t
is large enough to hold a pointer.
A real solution to this problem would be a rewrite of do_cmd() to
treat the optlen parameter consistently and not use it to carry
a pointer or integer dependent on the context.
Allow set 31 to be used for rules other than 65535.
Set 31 is still special because rules belonging to it are not deleted
by the "ipfw flush" command, but must be deleted explicitly with
"ipfw delete set 31" or by individual rule numbers.
This implement a flexible form of "persistent rules" which you might
want to have available even after an "ipfw flush".
Note that this change does not violate POLA, because you could not
use set 31 in a ruleset before this change.
Suggested by: Paul Richards
introduced in the latest commits).
Also:
* update the 'ipfw -h' output;
* allow rules of the form "100 add allow ..." i.e. with the index first.
(requested by Paul Richards). This was an undocumented ipfw1 behaviour,
and it is left undocumented.
and minor code cleanups.
* make the code compile with WARNS=5 (at least on i386), mostly
by adding 'const' specifier and replacing "void *" with "char *"
in places where pointer arithmetic was used.
This also spotted a few places where invalid tests (e.g. uint < 0)
were used.
* support ranges in "list" and "show" commands. Now you can say
ipfw show 100-1000 4000-8000
which is very convenient when you have large rulesets.
* implement comments in ipfw commands. These are implemented in the
kernel as O_NOP commands (which always match) whose body contains
the comment string. In userland, a comment is a C++-style comment:
ipfw add allow ip from me to any // i can talk to everybody
The choice of '//' versus '#' is somewhat arbitrary, but because
the preprocessor/readfile part of ipfw used to strip away '#',
I did not want to change this behaviour.
If a rule only contains a comment
ipfw add 1000 // this rule is just a comment
then it is stored as a 'count' rule (this is also to remind
the user that scanning through a rule is expensive).
* improve handling of flags (still to be completed).
ipfw_main() was written thinking of 'one rule per ipfw invocation',
and so flags are set and never cleared. With readfile/preprocessor
support, this changes and certain flags should be reset on each
line. For the time being, only fix handling of '-a' which
differentiates the "list" and "show" commands.
* rework the preprocessor support -- ipfw_main() already had most
of the parsing code, so i have moved in there the only missing
bit (stripping away '#' and comments) and removed the parsing
from ipfw_readfile().
Also, add some more options (such as -c, -N, -S) to the readfile
section.
MFC after: 3 days
* Make the addr-set size optional (defaults to /24)
You can now write 1.2.3.0/24{56-80} or 1.2.3.0{56-80}
Also make the parser more strict.
* Support a new format for the list of addresses:
1.2.3.4,5.6.7.8/30,9.10.11.12/22,12.12.12.13, ...
which exploits the new capabilities of O_IP_SRC_MASK/O_IP_DST_MASK
* Allow spaces after commas to make lists of addresses more readable.
1.2.3.4, 5.6.7.8/30, 9.10.11.12/22, 12.12.12.13, ...
* ipfw will now accept full commands as a single argument and strip
extra leading/trailing whitespace as below:
ipfw "-q add allow ip from 1.2.3.4 to 5.6.7.8, 9.10.11.23 "
This should help in moving the body of ipfw into a library
that user programs can invoke.
* Cleanup some comments and data structures.
* Do not print rule counters for dynamic rules with ipfw -d list
(PR 51182)
* Improve 'ipfw -h' output (PR 46785)
* Add a '-n' flag to test the syntax of commands without actually
calling [gs]etsockopt() (PR 44238)
* Support the '-n' flag also with the preprocessors;
Manpage commit to follow.
MFC after: 3 days
Should work with both regular and fast ipsec (mutually exclusive).
See manpage for more details.
Submitted by: Ari Suutari (ari.suutari@syncrontech.com)
Revised by: sam
MFC after: 1 week
1.2.3.4/24{5,6,7,10-20,60-90}
for set of ip addresses.
Previously you needed to specify every address in the range, which
was unconvenient and lead to very long lines.
Internally the set is still stored in the same way, just the
input and output routines are modified.
Manpage update still missing.
Perhaps a similar preprocessing step would be useful for port ranges.
MFC after: 3 days
"ipid" options. This feature has been requested by several users.
On passing, fix some minor bugs in the parser. This change is fully
backward compatible so if you have an old /sbin/ipfw and a new
kernel you are not in trouble (but you need to update /sbin/ipfw
if you want to use the new features).
Document the changes in the manpage.
Now you can write things like
ipfw add skipto 1000 iplen 0-500
which some people were asking to give preferential treatment to
short packets.
The 'MFC after' is just set as a reminder, because I still need
to merge the Alpha/Sparc64 fixes for ipfw2 (which unfortunately
change the size of certain kernel structures; not that it matters
a lot since ipfw2 is entirely optional and not the default...)
PR: bin/48015
MFC after: 1 week
comes in on is the same interface that we would route out of to get to
the packet's source address. Essentially automates an anti-spoofing
check using the information in the routing table.
Experimental. The usage and rule format for the feature may still be
subject to change.
width of fields for packets and bytes counters.
PR: bin/47196
Reviewed by: -audit
Not objected by: luigi, des
o Use %llu instead of deprecated %qu convert specification for ipfw
packets and bytes counters.
Noted by: des
MFC after: 1 month
default-to-deny firewall. Simply turning off IPFW via a preexisting
sysctl does the job. To make it more apparent (since nobody picked up
on this in a week's worth of flames), the boolean sysctl's have been
integrated into the /sbin/ipfw command set in an obvious and straightforward
manner. For example, you can now do 'ipfw disable firewall' or
'ipfw enable firewall'. This is far easier to remember then the
net.inet.ip.fw.enable sysctl.
Reviewed by: imp
MFC after: 3 days
after -p except for the last (the ruleset file to process) to the
preprocessor for interpretation. This allows command-line options besides
-U and -D to be passed to cpp(1) and m4(1) as well as making it easier to
use other preprocessors.
Sponsored By: NTT Multimedia Communications Labs
MFC after: 1 week
prob 0.5 pipe NN ....
due to the generation of an invalid ipfw instruction sequence.
No ABI change, but you need to upgrade /sbin/ipfw to generate the
correct code.
Approved by: re
Quoting luigi:
In order to make the userland code fully 64-bit clean it may
be necessary to commit other changes that may or may not cause
a minor change in the ABI.
Reviewed by: luigi
has always done.
Technically, this is the wrong format, but it reduces the diffs in
-stable. Someday, when we get rid of ipfw1, I will put the port number
in the proper format both in kernel and userland.
MFC after: 3 days
(with re@ permission)
following Julian's good suggestion: since you can specify any match
pattern as an option, rules now have the following format:
[<proto> from <src> to <dst>] [options]
i.e. the first part is now entirely optional (and left there just
for compatibility with ipfw1 rulesets).
Add a "-c" flag to show/list rules in the compact form
(i.e. without the "ip from any to any" part) when possible.
The default is to include it so that scripts processing ipfw's
canonical output will still work.
Note that as part of this cleanup (and to remove ambiguity), MAC
fields now can only be specified in the options part.
Update the manpage to reflect the syntax.
Clarify the behaviour when a match is attempted on fields which
are not present in the packet, e.g. port numbers on non TCP/UDP
packets, and the "not" operator is specified. E.g.
ipfw add allow not src-port 80
will match also ICMP packets because they do not have port numbers, so
"src-port 80" will fail and "not src-port 80" will succeed. For such
cases it is advised to insert further options to prevent undesired results
(e.g. in the case above, "ipfw add allow proto tcp not src-port 80").
We definitely need to rewrite the parser using lex and yacc!
render the syntax less ambiguous.
Now rules can be in one of these two forms
<action> <protocol> from <src> to <dst> [options]
<action> MAC dst-mac src-mac mac-type [options]
however you can now specify MAC and IP header fields as options e.g.
ipfw add allow all from any to any mac-type arp
ipfw add allow all from any to any { dst-ip me or src-ip me }
which makes complex expressions a lot easier to write and parse.
The "all from any to any" part is there just for backward compatibility.
Manpage updated accordingly.
Implement the M_SKIP_FIREWALL bit in m_flags to avoid loops
for firewall-generated packets (the constant has to go in sys/mbuf.h).
Better comments on keepalive generation, and enforce dyn_rst_lifetime
and dyn_fin_lifetime to be less than dyn_keepalive_period.
Enforce limits (up to 64k) on the number of dynamic buckets, and
retry allocation with smaller sizes.
Raise default number of dynamic rules to 4096.
Improved handling of set of rules -- now you can atomically
enable/disable multiple sets, move rules from one set to another,
and swap sets.
sbin/ipfw/ipfw2.c:
userland support for "noerror" pipe attribute.
userland support for sets of rules.
minor improvements on rule parsing and printing.
sbin/ipfw/ipfw.8:
more documentation on ipfw2 extensions, differences from ipfw1
(so we can use the same manpage for both), stateful rules,
and some additional examples.
Feedback and more examples needed here.
