WASD has had global configuration [Accept] and [Reject] since public release.
Used by few due to limited functionality. Basically wildcard matching to
host name and IP address. So, host.example.com, *.example.com, 93.184.216.1
and 93.184.216.*, fullstop. Also, existing in global configuration, the
server(s) needed (re)starting for changes in the patterns to be updated.
WASD v12.2 has addressed these limitations.
Most notably, [Accept] and [Reject] now allow logical and physical file
specifications, decoupling rules from global configuration, along with
/DO=ACCEPT=LOAD and /DO=REJECT=LOAD providing for simple rule update.
Logical names for these are suggested to be along the lines of current
configuration files, WASD_CONFIG_ACCEPT and WASD_CONFIG_REJECT and located in
the WASD_LOCAL (default WASD_ROOT:[LOCAL]) directory.
The Server Administration menu also has added an Access Control section
providing Report and Revise for Accept and Reject, along with Reload and
reject Purge functionality.
The foremost reason is internet facing systems benefit from excluding some
classes of host connection. It has been observed, most often (though not
exclusively) 'interesting' requests and overt break-in attempts originate
from IP addresses that have no associated domain name. In other cases
constantly repeated attempted penetrations originate form observed ranges;
for example 46.148.32.0-46.148.47.255 (via WHOIS Lookup (46.148.32.0);
inetnum: 46.148.32.0 - 46.148.47.255, netname: PARTPATAM, descr: Region :
Esfahan, City : shahin shahr, country: IR).
Where [DNSLookupClient] is enabled, and host name resolution has occurred, a
wildcard match may be employed for both [Accept] and [Reject].
host.example.com
*.example.com
[Accept] has precedence over [Reject] so once accepted the rejection rules
are not checked. Where a host name is not resolved both rely on matching IP
addresses.
IP address matching may be done with a simple wildcard or by IP address range
or CIDR mask. The first is a simple IP address, the second a wildcard, the
third a range, the fourth a CIDR mask.
93.184.216.1
93.184.216.*
93.184.216.1-93.184.216.63
93.184.216.1/26
There are a number of [Reject] directives that may be used to configure
additional functionality. These must occur before any pattern usage.
$DNS if the IP address does not resolve reject the connection
$LOG if rejected add an access log entry
152.208.29.248 - - [5/Jan/2024:10:37:03 -0400] "CONNECT \
/REJECT~152.208.29.248 HTTP/1.0" 418 0 "-" "-"
$NOTE if rejected note this is in the server process log
%HTTPD-I-REJECT, 05-JAN-2024 10:39:34, 18, 152.208.29.248 the.site.name:443
(these $NOTEs also provide input to the Server Admin reject report)
$OFF disable accept/reject processing
$OPCOM report to OPCOM (essentially as per $NOTE)
$4/5nn see below
WASD has for a long time supported #WASD_CONFIG_MAP rules that can be mapped
to HTTP status.
https://wasd.vsm.com.au/wasd_root/wasdoc/config/#mappassfailrules
In WASD v11.4 the specific status 418 (I'm a teapot) was selected for
specific functionality; immediate connection closure. The connection was
accepted and the request read with subsequent processing curtailed. Request
mapping provides significant capability for complex request analysis and
resultants.
https://wasd.vsm.com.au/wasd_root/wasdoc/config/#conditionalconfiguration
https://wasd.vsm.com.au/wasd_root/wasdoc/config/#ifendifconditionals
https://wasd.vsm.com.au/wasd_root/wasdoc/config/#conditionalkeywords
An example would be to drop a likely SQL injection attempt.
if (query-string:"*%20select%20*" || \
query-string:"*%20union%20*" || \
query-string:"*%20and%20*" || \
query-string:"*(select+*" || \
query-string:"*+select+*")
pass * "418 injecting?"
endif
The v12.2 [Reject] directives allow a selected HTTP status to be added to the
IP rejection list. Subsequent connection attempts from this IP address
immediately will be closed for the specified period. The rule syntax is
$<HTTP-status> <IP-address-size> <duration-minutes>
$418 250 60
and the example redeploys status 418 (can be any reasonable 4nn or 5nn,
except 400 and 403), allows for up to 250 concurrent IP addresses, and
maintains those IP address rejections for one hour. After setting up 4/5nn
status, a 400 directive includes IP addresses that have a significantly
malformed header, and a 403 includes IP addresses exceeding the authorisation
failure limit.
NOTE: any site currently employing [Accept] and/or [Reject] will need to
evaluate usage under the v12.2 functionality.
This item is one of a collection at
https://wasd.vsm.com.au/other/#occasional
|