mirror of https://github.com/sipwise/kamailio.git
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
836 lines
24 KiB
836 lines
24 KiB
1. Permissions Module
|
|
|
|
Miklos Tirpak
|
|
|
|
Juha Heinanen
|
|
|
|
Copyright © 2003, 2006 Miklos Tirpak, Juha Heinanen, iptelorg GmbH
|
|
__________________________________________________________________
|
|
|
|
1.1. Overview
|
|
|
|
1.1.1. Call Routing
|
|
1.1.2. Registration Permissions
|
|
1.1.3. Refer-To Permissions
|
|
1.1.4. Messages catching
|
|
|
|
1.2. Parameters
|
|
|
|
1.2.1. default_allow_file (string)
|
|
1.2.2. default_deny_file (string)
|
|
1.2.3. check_all_branches (integer)
|
|
1.2.4. allow_suffix (string)
|
|
1.2.5. deny_suffix (string)
|
|
1.2.6. max_rule_files (int)
|
|
1.2.7. safe_file_load (int)
|
|
1.2.8. db_url (string)
|
|
1.2.9. db_mode (int)
|
|
1.2.10. ipmatch_table (string)
|
|
1.2.11. declare_ipset (string)
|
|
|
|
1.3. Functions
|
|
|
|
1.3.1. allow_routing()
|
|
1.3.2. allow_routing(basename)
|
|
1.3.3. allow_routing(allow_file, deny_file)
|
|
1.3.4. allow_register(basename)
|
|
1.3.5. allow_register(allow_file, deny_file)
|
|
1.3.6. allow_refer_to(basename)
|
|
1.3.7. allow_refer_to(allow_file, deny_file)
|
|
1.3.8. ipmatch (string/AVP/select, [avp])
|
|
1.3.9. ipmatch_onsend (string)
|
|
1.3.10. ipmatch_filter (unsigned int)
|
|
1.3.11. ip_is_trusted(ip_set, ip)
|
|
|
|
1.4. XMLRPC Interface
|
|
|
|
1.1. Overview
|
|
|
|
1.1.1. Call Routing
|
|
|
|
The module can be used to determine if a call has appropriate
|
|
permission to be established. Permission rules are stored in plaintext
|
|
configuration files similar to hosts.allow and hosts.deny files used by
|
|
tcpd.
|
|
|
|
When allow_routing function is called it tries to find a rule that
|
|
matches selected fields of the message.
|
|
|
|
SER is a forking proxy and therefore a single message can be sent to
|
|
different destinations simultaneously. When checking permissions all
|
|
the destinations must be checked and if one of them fails, the
|
|
forwarding will fail.
|
|
|
|
The matching algorithm is as follows, first match wins:
|
|
* Create a set of pairs of form (From, R-URI of branch 1), (From,
|
|
R-URI of branch 2), etc.
|
|
* Routing will be allowed when all pairs match an entry in the allow
|
|
file.
|
|
* Otherwise routing will be denied when one of pairs matches an entry
|
|
in the deny file.
|
|
* Otherwise, routing will be allowed.
|
|
|
|
A non-existing permission control file is treated as if it were an
|
|
empty file. Thus, permission control can be turned off by providing no
|
|
permission control files.
|
|
|
|
From header field and Request-URIs are always compared with regular
|
|
expressions! For the syntax see the sample file:
|
|
config/permissions.allow.
|
|
|
|
1.1.2. Registration Permissions
|
|
|
|
In addition to call routing it is also possible to check REGISTER
|
|
messages and decide--based on the configuration files--whether the
|
|
message should be allowed and the registration accepted or not.
|
|
|
|
Main purpose of the function is to prevent registration of "prohibited"
|
|
IP addresses. One example, when a malicious user registers a contact
|
|
containing IP address of a PSTN gateway, he might be able to bypass
|
|
authorization checks performed by the SIP proxy. That is undesirable
|
|
and therefore attempts to register IP address of a PSTN gateway should
|
|
be rejected. Files config/register.allow and config/register.deny
|
|
contain an example configuration.
|
|
|
|
Function for registration checking is called allow_register and the
|
|
algorithm is very similar to the algorithm described in Section 1.1.1,
|
|
“Call Routing”. The only difference is in the way how pairs are
|
|
created.
|
|
|
|
Instead of From header field the function uses To header field because
|
|
To header field in REGISTER messages contains the URI of the person
|
|
being registered. Instead of the Request-URI of branches the function
|
|
uses Contact header field.
|
|
|
|
Thus, pairs used in matching will look like this: (To, Contact 1), (To,
|
|
Contact 2), (To, Contact 3), and so on..
|
|
|
|
The algorithm of matching is same as described in Section 1.1.1, “Call
|
|
Routing”.
|
|
|
|
1.1.3. Refer-To Permissions
|
|
|
|
In addition to call routing and REGISTER it is also possible to check
|
|
REFER messages and decide--based on the configuration files-- whether
|
|
or not the message should be accepted for forwarding.
|
|
|
|
Main purpose of the function is to prevent referring a SIP UA to
|
|
"prohibited" IP addresses. One example is user sending a REFER request
|
|
to PSTN gateway trying to refer it to an expensive phone number.
|
|
|
|
Function for Refer-To checking is called allow_refer_to and the
|
|
algorithm is very similar to the algorithm described in Section 1.1.1.
|
|
The only difference is in the way how pairs are created.
|
|
|
|
Instead of Request-URI the function uses Refer-To header field because
|
|
Refer-To header field in REFER messages contains the URI to which the
|
|
UA is being referred to. The algorithm of matching is same as described
|
|
in Section 1.1.1.
|
|
|
|
1.1.4. Messages catching
|
|
|
|
The module can be also used for catching messages coming from or going
|
|
to specific network elements, for example gateways or peering partners.
|
|
|
|
Users can register or forward the calls to the address of a gateway
|
|
resulting unauthorized access to them. Such calls must be catched and
|
|
dropped, see ipmatch functions for details.
|
|
|
|
1.2. Parameters
|
|
|
|
1.2.1. default_allow_file (string)
|
|
|
|
Default allow file used by functions without parameters. If you don't
|
|
specify full pathname then the directory in which is the main config
|
|
file is located will be used.
|
|
|
|
Default value is “permissions.allow”.
|
|
|
|
Example 1. Set default_allow_file parameter
|
|
...
|
|
modparam("permissions", "default_allow_file", "/etc/permissions.allow")
|
|
...
|
|
|
|
1.2.2. default_deny_file (string)
|
|
|
|
Default file containing deny rules. The file is used by functions
|
|
without parameters. If you don't specify full pathname then the
|
|
directory in which the main config file is located will be used.
|
|
|
|
Default value is “permissions.deny”.
|
|
|
|
Example 2. Set default_deny_file parameter
|
|
...
|
|
modparam("permissions", "default_deny_file", "/etc/permissions.deny")
|
|
...
|
|
|
|
If both of the default file parameters are set to "" the module does
|
|
not try to load them.
|
|
|
|
1.2.3. check_all_branches (integer)
|
|
|
|
If set then allow_routing functions will check Request-URI of all
|
|
branches (default). If disabled then only Request-URI of the first
|
|
branch will be checked.
|
|
|
|
Warning
|
|
|
|
Do not disable this parameter unless you really know what you are
|
|
doing.
|
|
|
|
Default value is 1.
|
|
|
|
Example 3. Set check_all_branches parameter
|
|
...
|
|
modparam("permissions", "check_all_branches", 0)
|
|
...
|
|
|
|
1.2.4. allow_suffix (string)
|
|
|
|
Suffix to be appended to basename to create filename of the allow file
|
|
when version with one parameter of either allow_routing or
|
|
allow_register is used.
|
|
|
|
Note
|
|
|
|
Including leading dot.
|
|
|
|
Default value is ".allow".
|
|
|
|
Example 4. Set allow_suffix parameter
|
|
...
|
|
modparam("permissions", "allow_suffix", ".allow")
|
|
...
|
|
|
|
1.2.5. deny_suffix (string)
|
|
|
|
Suffix to be appended to basename to create filename of the deny file
|
|
when version with one parameter of either allow_routing or
|
|
allow_register is used.
|
|
|
|
Note
|
|
|
|
Including leading dot.
|
|
|
|
Default value is ".deny".
|
|
|
|
Example 5. Set deny_suffix parameter
|
|
...
|
|
modparam("permissions", "deny_suffix", ".deny")
|
|
...
|
|
|
|
1.2.6. max_rule_files (int)
|
|
|
|
Maximum number of allow/deny file pairs.
|
|
|
|
Default value is 64.
|
|
|
|
1.2.7. safe_file_load (int)
|
|
|
|
Module initialization fails in case of a missing config file if
|
|
safe_file_load is true.
|
|
|
|
Default value is 0 (false).
|
|
|
|
1.2.8. db_url (string)
|
|
|
|
URL of the database to be used.
|
|
|
|
1.2.9. db_mode (int)
|
|
|
|
Disables/enables database cache.
|
|
|
|
Default value is 0 (cache is disabled)
|
|
|
|
NOTE: ipmatch functions can operate only in cache mode, set db_mode to
|
|
1 if you want to use them.
|
|
|
|
1.2.10. ipmatch_table (string)
|
|
|
|
Name of the table containing ipmatch entries.
|
|
|
|
Default value is "ipmatch".
|
|
|
|
1.2.11. declare_ipset (string)
|
|
|
|
Declares name of ip set which can be manipulated via RPC commands and
|
|
tested using ip_is_trusted. Identifier must start with letter or
|
|
underscore.
|
|
|
|
IP mask may follow equal sign to initialize ipset on startup.
|
|
|
|
1.3. Functions
|
|
|
|
1.3.1. allow_routing()
|
|
|
|
Returns true if all pairs constructed as described in Section 1.1.1,
|
|
“Call Routing” have appropriate permissions according to the
|
|
configuration files. This function uses default configuration files
|
|
specified in default_allow_file and default_deny_file.
|
|
|
|
Example 6. allow_routing usage
|
|
...
|
|
if (allow_routing()) {
|
|
t_relay();
|
|
};
|
|
...
|
|
|
|
1.3.2. allow_routing(basename)
|
|
|
|
Returns true if all pairs constructed as described in Section 1.1.1,
|
|
“Call Routing” have appropriate permissions according to the
|
|
configuration files given as parameters.
|
|
|
|
Meaning of the parameters is as follows:
|
|
* basename - Basename from which allow and deny filenames will be
|
|
created by appending contents of allow_suffix and deny_suffix
|
|
parameters.
|
|
If the parameter doesn't contain full pathname then the function
|
|
expects the file to be located in the same directory as the main
|
|
configuration file of the server.
|
|
|
|
Example 7. allow_routing(basename) usage
|
|
...
|
|
if (allow_routing("basename")) {
|
|
t_relay();
|
|
};
|
|
...
|
|
|
|
1.3.3. allow_routing(allow_file, deny_file)
|
|
|
|
Returns true if all pairs constructed as described in Section 1.1.1,
|
|
“Call Routing” have appropriate permissions according to the
|
|
configuration files given as parameters.
|
|
|
|
Meaning of the parameters is as follows:
|
|
* allow_file - File containing allow rules.
|
|
If the parameter doesn't contain full pathname then the function
|
|
expects the file to be located in the same directory as the main
|
|
configuration file of the server.
|
|
* deny_file - File containing deny rules.
|
|
If the parameter doesn't contain full pathname then the function
|
|
expects the file to be located in the same directory as the main
|
|
configuration file of the server.
|
|
|
|
Example 8. allow_routing(allow_file, deny_file) usage
|
|
...
|
|
if (allow_routing("rules.allow", "rules.deny")) {
|
|
t_relay();
|
|
};
|
|
...
|
|
|
|
1.3.4. allow_register(basename)
|
|
|
|
The function returns true if all pairs constructed as described in
|
|
Section 1.1.2, “Registration Permissions” have appropriate permissions
|
|
according to the configuration files given as parameters.
|
|
|
|
Meaning of the parameters is as follows:
|
|
* basename - Basename from which allow and deny filenames will be
|
|
created by appending contents of allow_suffix and deny_suffix
|
|
parameters.
|
|
If the parameter doesn't contain full pathname then the function
|
|
expects the file to be located in the same directory as the main
|
|
configuration file of the server.
|
|
|
|
Example 9. allow_register(basename) usage
|
|
...
|
|
if (method=="REGISTER") {
|
|
if (allow_register("register")) {
|
|
save("location");
|
|
break;
|
|
} else {
|
|
sl_send_reply("403", "Forbidden");
|
|
};
|
|
};
|
|
...
|
|
|
|
1.3.5. allow_register(allow_file, deny_file)
|
|
|
|
The function returns true if all pairs constructed as described in
|
|
Section 1.1.2, “Registration Permissions” have appropriate permissions
|
|
according to the configuration files given as parameters.
|
|
|
|
Meaning of the parameters is as follows:
|
|
* allow_file - File containing allow rules.
|
|
If the parameter doesn't contain full pathname then the function
|
|
expects the file to be located in the same directory as the main
|
|
configuration file of the server.
|
|
* deny_file - File containing deny rules.
|
|
If the parameter doesn't contain full pathname then the function
|
|
expects the file to be located in the same directory as the main
|
|
configuration file of the server.
|
|
|
|
Example 10. allow_register(allow_file, deny_file) usage
|
|
...
|
|
if (method=="REGISTER") {
|
|
if (allow_register("register.allow", "register.deny")) {
|
|
save("location");
|
|
break;
|
|
} else {
|
|
sl_send_reply("403", "Forbidden");
|
|
};
|
|
};
|
|
...
|
|
|
|
1.3.6. allow_refer_to(basename)
|
|
|
|
The function returns true if all pairs constructed as described in
|
|
Section 1.1.2, “Registration Permissions” have appropriate permissions
|
|
according to the configuration files given as parameters.
|
|
|
|
Meaning of the parameters is as follows:
|
|
* basename - Basename from which allow and deny filenames will be
|
|
created by appending contents of allow_suffix and deny_suffix
|
|
parameters.
|
|
If the parameter doesn't contain full pathname then the function
|
|
expects the file to be located in the same directory as the main
|
|
configuration file of the server.
|
|
|
|
Example 11. allow_register(basename) usage
|
|
...
|
|
if (method=="REGISTER") {
|
|
if (allow_register("register")) {
|
|
save("location");
|
|
break;
|
|
} else {
|
|
sl_send_reply("403", "Forbidden");
|
|
};
|
|
};
|
|
...
|
|
|
|
1.3.7. allow_refer_to(allow_file, deny_file)
|
|
|
|
The function returns true if all pairs constructed as described in
|
|
Section 1.1.2 have appropriate permissions according to the
|
|
configuration files given as parameters.
|
|
|
|
Meaning of the parameters is as follows:
|
|
* allow_file - File containing allow rules.
|
|
If the parameter doesn't contain full pathname then the function
|
|
expects the file to be located in the same directory as the main
|
|
configuration file of the server.
|
|
* deny_file - File containing deny rules.
|
|
If the parameter doesn't contain full pathname then the function
|
|
expects the file to be located in the same directory as the main
|
|
configuration file of the server.
|
|
|
|
Example 12. allow_register(allow_file, deny_file) usage
|
|
...
|
|
if (method=="REFER") {
|
|
if (allow_register("refer.allow", "refer.deny")) {
|
|
...
|
|
} else {
|
|
sl_send_reply("403", "Forbidden");
|
|
};
|
|
};
|
|
...
|
|
|
|
1.3.8. ipmatch (string/AVP/select, [avp])
|
|
|
|
The function tries to find an IP address and port pair (defined by the
|
|
first function parameter) in the cached database table. Port is
|
|
optional, it is compared only if both the function parameter and the
|
|
database entry contain it.
|
|
|
|
Meaning of the parameters is as follows:
|
|
* string/AVP/select - File containing allow rules.
|
|
+ string:
|
|
"src": the source address of the packet is used "via2": the ip
|
|
address of the 2nd via line is used other values are not
|
|
defined currently
|
|
+ AVP:
|
|
e.g. "$myavp"
|
|
+ select call:
|
|
e.g. "@via[0].host"
|
|
* The second parameter is optional, it is used to set an AVP value
|
|
from the database. Suitable for assigning logical identifiers to
|
|
gateways.
|
|
|
|
Note that IPv6 addresses must be enclosed in square brackets in case of
|
|
port is defined: [1111:2222::3333]:5060
|
|
|
|
1.3.9. ipmatch_onsend (string)
|
|
|
|
ipmatch() function replacement for onsend_route block.
|
|
|
|
The function accepts only string parameter, because even AVP reading is
|
|
unsafe in onsend_route.
|
|
|
|
Meaning of the parameter:
|
|
* "dst":
|
|
the destination address is used
|
|
* "ruri":
|
|
the ip:port pair is extracted from the Request URI
|
|
|
|
The function can be used for example to catch unauthorized requests
|
|
going to gateways: Use a flag to mark the call as PSTN either in
|
|
request or in failure_route, and do not touch it in onreply_route. See
|
|
the examples below.
|
|
|
|
1.3.10. ipmatch_filter (unsigned int)
|
|
|
|
Entries in the database can be marked to group the different kind of
|
|
network elements. The function sets the filter which is used on the
|
|
mark while comparing the IP addresses. The mark must be the power of 2
|
|
in the database!
|
|
|
|
Note that ipmatch() and ipmatch_onsend() functions reset the filter!
|
|
|
|
Example 13. ipmatch_filter (unsigned int) usage
|
|
+-----------------+-------------------+------+------+
|
|
| ip | avp_val | mark | flag |
|
|
+-----------------+-------------------+------+------+
|
|
| 1111:2222::1001 | first_gw | 1 | 1 |
|
|
| 10.38.2.10:5060 | second_gw | 1 | 1 |
|
|
| 10.0.0.10 | first_peering | 2 | 1 |
|
|
+-----------------+-------------------+------+------+
|
|
|
|
|
|
route[0] {
|
|
# is this a request from a GW?
|
|
ipmatch_filter("1");
|
|
if (ipmatch("src", "$gw_id")) {
|
|
# yes, it is from a GW
|
|
...
|
|
} else {
|
|
# is this a request from a peering partner?
|
|
ipmatch_filter("2");
|
|
if (ipmatch("src", "$peering_id")) {
|
|
# yes, it is from a peering partner
|
|
...
|
|
};
|
|
}
|
|
...
|
|
# request goes to PSTN
|
|
setflag(PSTN);
|
|
}
|
|
|
|
onsend_route[0] {
|
|
if (method == "INVITE" && (!isflagset(PSTN))) {
|
|
# is this a request to a GW?
|
|
ipmatch_filter("1");
|
|
if (ipmatch_onsend("dst")) {
|
|
# request is not marked with PSTN flag, but it goes to a gateway
|
|
drop;
|
|
}
|
|
}
|
|
...
|
|
}
|
|
|
|
1.3.11. ip_is_trusted(ip_set, ip)
|
|
|
|
The function returns true if ip is contained in ip_set. Both IPv4 and
|
|
IPv6 are supported.
|
|
|
|
Meaning of the parameters is as follows:
|
|
* ip_set is identified by comma/space/semicolon delimited list of IP
|
|
addresses or subnet masks. The subnet mask is written in
|
|
IP_slash_number form or as IP. If the mask is not mentioned then
|
|
default value is taken, the default value is number of bits of
|
|
particular IP address, i.e. 32 in case of IPv4, 128 in case of
|
|
IPv6.
|
|
Besides list also ip set identifier declared by declare_ipset may
|
|
be provided. In this case ip is checked against set maintainded by
|
|
RPC commands.
|
|
* ip to test. Besides direct address in string form there are extra
|
|
identifiers to force IP related to current message: Source,
|
|
Destination, Received. Note that only the first character is
|
|
essential.
|
|
|
|
Example 14. ip_is_trusted usage
|
|
modparam("permissions", "declare_ipset", "my_ipset1");
|
|
modparam("permissions", "declare_ipset", "my_ipset2=127.0.0.0/24;10.0.0.0/255.25
|
|
5.255.0");
|
|
|
|
route[TT2] {
|
|
if (ip_is_trusted("$net", "$ip")) {
|
|
xplog("L_E", "'%$ip' - TRUE\n");
|
|
} else {
|
|
xplog("L_E", "'%$ip' - FALSE\n");
|
|
}
|
|
}
|
|
|
|
route[TT1] {
|
|
xplog("L_E", "Testing netmask '%$net'\n");
|
|
|
|
$ip = "s"; # source address
|
|
route(TT2);
|
|
|
|
$ip = "127.0.0.1";
|
|
route(TT2);
|
|
|
|
$ip = "127.0.0.2";
|
|
route(TT2);
|
|
|
|
$ip = "10.0.0.1";
|
|
route(TT2);
|
|
|
|
$ip = "11.0.0.1";
|
|
route(TT2);
|
|
|
|
$ip = "172.1.8.1";
|
|
route(TT2);
|
|
|
|
$ip = "192.168.1.1";
|
|
route(TT2);
|
|
|
|
$ip = "192.168.1.255";
|
|
route(TT2);
|
|
|
|
$ip = "192.168.2.1";
|
|
route(TT2);
|
|
|
|
$ip = "192.168.3.1";
|
|
route(TT2);
|
|
|
|
$ip = "192.168.4.97";
|
|
route(TT2);
|
|
|
|
$ip = "192.168.4.100";
|
|
route(TT2);
|
|
|
|
$ip = "[0:2:4:A:B:D:E:F301]";
|
|
route(TT2);
|
|
|
|
$ip = "[0:2:4:A:B:D:E:F401]";
|
|
route(TT2);
|
|
|
|
$ip = "[0:0:0:0:0:0:0:0]";
|
|
route(TT2);
|
|
}
|
|
|
|
route[TEST] {
|
|
$net = "0.0.0.0 128.2.3.4/1 127.0.128.16 [0:2:4:A:B:D:E:F301]";
|
|
route(TT1);
|
|
|
|
$net = "255.255.255.255/0"; # all IPv4 addresses, dentical to 0.0.0.0/0
|
|
route(TT1);
|
|
|
|
$net = "127.0.0.1/255.255.255.0";
|
|
route(TT1);
|
|
|
|
$net = "10.0.0.0/8"; # All type A addresses
|
|
route(TT1);
|
|
|
|
$net = "192.168.1.0/24";
|
|
route(TT1);
|
|
|
|
$net = "192.168.4.96/27";
|
|
route(TT1);
|
|
|
|
$net = "192.168.1.1/32"; # only one IP matches
|
|
route(TT1);
|
|
|
|
$net = "192.168.1.0/24,192.168.2.0/24";
|
|
route(TT1);
|
|
|
|
$net = "192.168.1.0/24,192.168.2.0/24,127.0.0.1/31";
|
|
route(TT1);
|
|
|
|
$net = "[0:0:0:0:0:0:0:0]/0"; # all IPv6 addresses
|
|
route(TT1);
|
|
|
|
$net = "[0:2:4:A:B:D:E:f300]/120";
|
|
route(TT1);
|
|
|
|
$net = "my_ipset1";
|
|
route(TT1);
|
|
|
|
}
|
|
# the result is:
|
|
|
|
Testing netmask '0.0.0.0 128.2.3.4/1 127.0.128.16 [0:2:4:A:B:D:E:F301]'
|
|
's' - FALSE
|
|
'127.0.0.1' - FALSE
|
|
'127.0.0.2' - FALSE
|
|
'10.0.0.1' - FALSE
|
|
'11.0.0.1' - FALSE
|
|
'172.1.8.1' - TRUE
|
|
'192.168.1.1' - TRUE
|
|
'192.168.1.255' - TRUE
|
|
'192.168.2.1' - TRUE
|
|
'192.168.3.1' - TRUE
|
|
'192.168.4.97' - TRUE
|
|
'192.168.4.100' - TRUE
|
|
'[0:2:4:A:B:D:E:F301]' - TRUE
|
|
'[0:2:4:A:B:D:E:F401]' - FALSE
|
|
'[0:0:0:0:0:0:0:0]' - FALSE
|
|
Testing netmask '255.255.255.255/0'
|
|
's' - TRUE
|
|
'127.0.0.1' - TRUE
|
|
'127.0.0.2' - TRUE
|
|
'10.0.0.1' - TRUE
|
|
'11.0.0.1' - TRUE
|
|
'172.1.8.1' - TRUE
|
|
'192.168.1.1' - TRUE
|
|
'192.168.1.255' - TRUE
|
|
'192.168.2.1' - TRUE
|
|
'192.168.3.1' - TRUE
|
|
'192.168.4.97' - TRUE
|
|
'192.168.4.100' - TRUE
|
|
'[0:2:4:A:B:D:E:F301]' - FALSE
|
|
'[0:2:4:A:B:D:E:F401]' - FALSE
|
|
'[0:0:0:0:0:0:0:0]' - FALSE
|
|
Testing netmask '127.0.0.1/24'
|
|
's' - FALSE
|
|
'127.0.0.1' - TRUE
|
|
'127.0.0.2' - TRUE
|
|
'10.0.0.1' - FALSE
|
|
'11.0.0.1' - FALSE
|
|
'172.1.8.1' - FALSE
|
|
'192.168.1.1' - FALSE
|
|
'192.168.1.255' - FALSE
|
|
'192.168.2.1' - FALSE
|
|
'192.168.3.1' - FALSE
|
|
'192.168.4.97' - FALSE
|
|
'192.168.4.100' - FALSE
|
|
'[0:2:4:A:B:D:E:F301]' - FALSE
|
|
'[0:2:4:A:B:D:E:F401]' - FALSE
|
|
'[0:0:0:0:0:0:0:0]' - FALSE
|
|
Testing netmask '10.0.0.0/8'
|
|
's' - FALSE
|
|
'127.0.0.1' - FALSE
|
|
'127.0.0.2' - FALSE
|
|
'10.0.0.1' - TRUE
|
|
'11.0.0.1' - FALSE
|
|
'172.1.8.1' - FALSE
|
|
'192.168.1.1' - FALSE
|
|
'192.168.1.255' - FALSE
|
|
'192.168.2.1' - FALSE
|
|
'192.168.3.1' - FALSE
|
|
'192.168.4.97' - FALSE
|
|
'192.168.4.100' - FALSE
|
|
'[0:2:4:A:B:D:E:F301]' - FALSE
|
|
'[0:2:4:A:B:D:E:F401]' - FALSE
|
|
'[0:0:0:0:0:0:0:0]' - FALSE
|
|
Testing netmask '192.168.1.0/24'
|
|
's' - FALSE
|
|
'127.0.0.1' - FALSE
|
|
'127.0.0.2' - FALSE
|
|
'10.0.0.1' - FALSE
|
|
'11.0.0.1' - FALSE
|
|
'172.1.8.1' - FALSE
|
|
'192.168.1.1' - TRUE
|
|
'192.168.1.255' - TRUE
|
|
'192.168.2.1' - FALSE
|
|
'192.168.3.1' - FALSE
|
|
'192.168.4.97' - FALSE
|
|
'192.168.4.100' - FALSE
|
|
'[0:2:4:A:B:D:E:F301]' - FALSE
|
|
'[0:2:4:A:B:D:E:F401]' - FALSE
|
|
'[0:0:0:0:0:0:0:0]' - FALSE
|
|
Testing netmask '192.168.4.96/27'
|
|
's' - FALSE
|
|
'127.0.0.1' - FALSE
|
|
'127.0.0.2' - FALSE
|
|
'10.0.0.1' - FALSE
|
|
'11.0.0.1' - FALSE
|
|
'172.1.8.1' - FALSE
|
|
'192.168.1.1' - FALSE
|
|
'192.168.1.255' - FALSE
|
|
'192.168.2.1' - FALSE
|
|
'192.168.3.1' - FALSE
|
|
'192.168.4.97' - TRUE
|
|
'192.168.4.100' - TRUE
|
|
'[0:2:4:A:B:D:E:F301]' - FALSE
|
|
'[0:2:4:A:B:D:E:F401]' - FALSE
|
|
'[0:0:0:0:0:0:0:0]' - FALSE
|
|
Testing netmask '192.168.1.1/32'
|
|
's' - FALSE
|
|
'127.0.0.1' - FALSE
|
|
'127.0.0.2' - FALSE
|
|
'10.0.0.1' - FALSE
|
|
'11.0.0.1' - FALSE
|
|
'172.1.8.1' - FALSE
|
|
'192.168.1.1' - TRUE
|
|
'192.168.1.255' - FALSE
|
|
'192.168.2.1' - FALSE
|
|
'192.168.3.1' - FALSE
|
|
'192.168.4.97' - FALSE
|
|
'192.168.4.100' - FALSE
|
|
'[0:2:4:A:B:D:E:F301]' - FALSE
|
|
'[0:2:4:A:B:D:E:F401]' - FALSE
|
|
'[0:0:0:0:0:0:0:0]' - FALSE
|
|
Testing netmask '192.168.1.0/24,192.168.2.0/24'
|
|
's' - FALSE
|
|
'127.0.0.1' - FALSE
|
|
'127.0.0.2' - FALSE
|
|
'10.0.0.1' - FALSE
|
|
'11.0.0.1' - FALSE
|
|
'172.1.8.1' - FALSE
|
|
'192.168.1.1' - TRUE
|
|
'192.168.1.255' - TRUE
|
|
'192.168.2.1' - TRUE
|
|
'192.168.3.1' - FALSE
|
|
'192.168.4.97' - FALSE
|
|
'192.168.4.100' - FALSE
|
|
'[0:2:4:A:B:D:E:F301]' - FALSE
|
|
'[0:2:4:A:B:D:E:F401]' - FALSE
|
|
'[0:0:0:0:0:0:0:0]' - FALSE
|
|
Testing netmask '192.168.1.0/24,192.168.2.0/24,127.0.0.1/31'
|
|
's' - FALSE
|
|
'127.0.0.1' - TRUE
|
|
'127.0.0.2' - FALSE
|
|
'10.0.0.1' - FALSE
|
|
'11.0.0.1' - FALSE
|
|
'172.1.8.1' - FALSE
|
|
'192.168.1.1' - TRUE
|
|
'192.168.1.255' - TRUE
|
|
'192.168.2.1' - TRUE
|
|
'192.168.3.1' - FALSE
|
|
'192.168.4.97' - FALSE
|
|
'192.168.4.100' - FALSE
|
|
'[0:2:4:A:B:D:E:F301]' - FALSE
|
|
'[0:2:4:A:B:D:E:F401]' - FALSE
|
|
'[0:0:0:0:0:0:0:0]' - FALSE
|
|
Testing netmask '[0:0:0:0:0:0:0:0]/0'
|
|
's' - FALSE
|
|
'127.0.0.1' - FALSE
|
|
'127.0.0.2' - FALSE
|
|
'10.0.0.1' - FALSE
|
|
'11.0.0.1' - FALSE
|
|
'172.1.8.1' - FALSE
|
|
'192.168.1.1' - FALSE
|
|
'192.168.1.255' - FALSE
|
|
'192.168.2.1' - FALSE
|
|
'192.168.3.1' - FALSE
|
|
'192.168.4.97' - FALSE
|
|
'192.168.4.100' - FALSE
|
|
'[0:2:4:A:B:D:E:F301]' - TRUE
|
|
'[0:2:4:A:B:D:E:F401]' - TRUE
|
|
'[0:0:0:0:0:0:0:0]' - TRUE
|
|
Testing netmask '[0:2:4:A:B:D:E:f300]/120'
|
|
's' - FALSE
|
|
'127.0.0.1' - FALSE
|
|
'127.0.0.2' - FALSE
|
|
'10.0.0.1' - FALSE
|
|
'11.0.0.1' - FALSE
|
|
'172.1.8.1' - FALSE
|
|
'192.168.1.1' - FALSE
|
|
'192.168.1.255' - FALSE
|
|
'192.168.2.1' - FALSE
|
|
'192.168.3.1' - FALSE
|
|
'192.168.4.97' - FALSE
|
|
'192.168.4.100' - FALSE
|
|
'[0:2:4:A:B:D:E:F301]' - TRUE
|
|
'[0:2:4:A:B:D:E:F401]' - FALSE
|
|
'[0:0:0:0:0:0:0:0]' - FALSE
|
|
}
|
|
|
|
1.4. XMLRPC Interface
|
|
|
|
Some functionality may be controled using RPC commands.
|
|
* ipmatch.reload - Reloads the cached ipmatch table. The original
|
|
table remains active in case of any failure.
|
|
* ipset.clean(ipset_name) - Clear all entries in "pending" ipset.
|
|
* ipset.add(ipset_name, ip, netmask) - Add ip and mask into ipset.
|
|
IPv6 should should be enclosed in brackets. Netmask may be
|
|
identified as number or in IP form. Note that number requires
|
|
leading slash, e.g. "/24" or "255.255.255.0".
|
|
* ipset.commit(ipset_name) - Makes pending ip set usable by
|
|
ip_is_trusted. Pending ip set is cleared.
|
|
* ipset.list() - List declared ip sets.
|
|
* ipset.print(ipset_name, pending) - Dump ipset trees. If pending non
|
|
zero then pending ipset is dumped.
|