update request {
Acct-Input-Gigawords >= 0
}
rlm_attr_filter
Synopsis
The attr_filter module filters attributes in a packet. It can
delete attributes or permit them to have only certain values. The
format of the file is the same as the users file. See the
files module for a description of the users file
format.
The filters that are applied depend on which operators are used. The
format is the same as the users file, e.g., Attribute-Name Operator
Value. The Attribute-Name can be any RADIUS attribute. The
Operator is given in the table below. The Value is a string that
is valid for Attribute-Name.
Processing Sections
authorize
When listed in the authorize section, the attr_filter module filters the request packet.
accounting
When listed in the accounting section, the attr_filter module filters the reply packet.
post-auth
When listed in the post-auth section, the attr_filter module filters the reply packet.
preacct
When listed in the preacct section, the attr_filter module filters the request packet.
pre-proxy
When listed in the pre-proxy section, the attr_filter module filters the proxy packet.
post-proxy
When listed in the post-proxy section, the attr_filter module filters the proxy_reply packet.
recv-coa
When listed in the recv-coa section, the attr_filter module filters the request packet.
send-coa
When listed in the send-coa section, the attr_filter module filters the reply packet.
- Return Codes
-
The module returns the same set of return codes for all of the processing sections.
-
noopThekeyattribute was not found, or it was found but no filter matched. -
failThekeycould not be dynamically expanded, or there was an error processing a filter. -
updatedThe packet was successfully filtered.
Expansions
None.
|
Meaning |
|
allow this attribute, no matter what the Value |
|
allow attributes with only Value |
|
allow attributes that have value less than Value |
|
allow attributes that have value less than or equal to Value |
|
allow attributes that have value greater than Value |
|
allow attributes that have value greater than or equal to Value |
Any attribute that is not listed in the filter is removed. The
attr_filter module does not create attributes, unlike the unlang
filtering. For example, the following unlang configuration creates
an Acct-Input-Gigawords attribute with value 0, if that attribute
does not already exist:
unlangA similar attr_filter rule is the following:
attr_filter file. DEFAULT
Acct-Input-Gigawords >= 0
This rule requires that existing attributes have value greater than or equal to zero. It does not create an attribute. After running the filter, the attribute still may not exist in the request.
For many situations, the unlang filtering is better. The
attr_filter module is left over from very early versions of the
server, when unlang did not exist.
Examples
The following are a few examples of filter rules.
DEFAULT
Vendor-Specific =* ANY,
Message-Authenticator =* ANY,
Proxy-State =* ANY
The filter allows any Vendor-Specific attribute, including all
VSAs. It allows Message-Authenticator and Proxy-State with any
Value. All other attributes are deleted.
Note that the special value ANY serves as a place-holder, which
allows any value for the attribute.
DEFAULT
Session-Timeout < 86400
This filter allows Session-Timeout to be no more than one day
(86400 seconds).
The filter rules serve two purposes. First, to enforce the RFC requirements on packet contents. And second, to serve as a "double check" on returned values.
The filter rules are editable because some vendors choose to ignore the RFC requirements. If the rules were hard-coded into the server source code, then they could not be changed, and FreeRADIUS would be incompatible with equipment from that vendor.
Allowing the rules to be edited means that the default rules can be applied in normal situations, but they can still be changed for unusual circumstances.
The second purpose of the rules is to act as a "double check" on the
returned values. For example, a site may allow junior
administrators to edit rules in an SQL database. These junior administrators may make
mistakes and give users too much access. The attr_filter rules can
then apply the over-all limits on user access. The filter rules can
be set once by a senior administrator and then rarely edited.
Directives
Default Instances
The server ships with a number of different instantiations of the module. Each instance is intended to filter one specific kind of packet. These instances are listed below.
- Defaults
-
key = %{User-Name}filename = ${modconfdir}/${.:name}/filter/access_challenge - Description
-
Enforces RFC requirements on the contents of
Access-Challengepackets. The RFCs require thatAccess-Challengepackets contain only a limited set of attributes. The default rules in theaccess_challengefile enforce that limitation.
- Defaults
-
key = %{User-Name}filename = ${modconfdir}/${.:name}/filter/access_reject - Description
-
Enforces RFC requirements on the contents of
Access-Rejectpackets. The RFCs require thatAccess-Challengepackets contain only a limited set of attributes. The default rules in theaccess_rejectfile enforce that limitation.
accounting_response
- Defaults
-
key = %{User-Name}filename = ${modconfdir}/${.:name}/filter/accounting_response - Description
-
Enforces RFC requirements on the contents of
Accounting-Responsepackets. This means that theAccounting-Responsepacket should be empty, i.e., it should contain no attributes.
pre-proxy
- Defaults
-
key = %{Realm}filename = ${modconfdir}/${.:name}/filter/pre-proxy - Description
-
Enforces RFC requirements on the contents of
Access-Requestpackets proxied to a home server.
post-proxy
- Defaults
-
key = %{Realm}filename = ${modconfdir}/${.:name}/filter/post-proxy - Description
-
Enforces RFC requirements on the contents of packets received from a home server.
-
The filter is applied to all packets, including
Access-Accept,Access-Challenge, andAccess-Reject.