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 $ $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