Facebook
Twitter
Username:
TITLE
SECURITY - attack surface : ports 7080 and 7081
PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE
Product version: Plesk Obsidian 18.0.49.2
OS version: Ubuntu 18.04 x86_64
Build date: 2023/01/10 23:00
Revision: c825df0ebc392580c3443ca51b28c6cb88be266d
PROBLEM DESCRIPTION
PROBLEM 1 : ports 7080 and 7081 open and vulnerable for external attack
PROBLEM 2 : modsecurity overload
PROBLEM 3 : WordPress XMLRPC attacks via ports 7081 (not often on 7080) over HTTP/1.0
PROBLEM 4 : default Nginx config does not include a "deny all;" directive for xmlrpc.php calls
NOTE 1 : when having Nginx as reverse proxy, the usage of the "internal" directive closes connections, but does NOT prevent that connections are established
NOTE 2 : when running 3 servers, the average of blocked IPs was 5000 to 6000 unique IP addresses per 24 hours!!!!
STEPS TO REPRODUCE
1 - install WordPress and Modsecurity
2 - inspect the modsec_audit.log and count abusive IPs : grep -i 7081 /var/log/modsec_audit.log | wc -l
ACTUAL RESULT
A lot of blocked IPs, attempting to brute force WordPress installations one way or another.
EXPECTED RESULT
SOLUTION 1 : change Nginx default config to contain
location ~* /xmlrpc.php {
deny all;
#access_log configuration is optional;
}
at the vhost level ....... and please consider solution 2, since this directive is blocking all attempts (read: depending on which port Nginx is listening and which port is used to attack) and hence makes blocking aggressive and/or makes it more challenging to log all offending IPs and create a blocklist (read: to be used by Nginx).
SOLUTION 2 : add a throttle mechanism in the location directive, for instance of the kind
limit_req_zone $binary_remote_addr zone=one:15m rate=5r/s;
and please note that this is important, since this would offer a solution to the really fast brute force hack attempts and also would enable to create a blocklist (read: to be used by Nginx).
SOLUTION 3 : use Fail2Ban WITH INCREMENTAL BAN TIME ........ see my other bug report about the Web UI of Fail2Ban
ANY ADDITIONAL INFORMATION
IMPORTANT : the scripts are not really advanced, but please note that
- when blocking access to xmlrpc.php via Nginx : other brute force methods are immediately following
- when blocking those other methods : brute force actions become more severe and faster
IMPORTANT : using Fail2Ban (or even the Plesk firewall) as the only option to combat these types of brute forcing is not at all desirable! The vast amount of offending IPs would create big problems ...... and can cause system resource overusage of such a kind that one can break all defense mechanisms.
YOUR EXPECTATIONS FROM PLESK SERVICE TEAM
Confirm bug
TITLE
SECURITY - attack surface : ports 7080 and 7081
PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE
Product version: Plesk Obsidian 18.0.49.2
OS version: Ubuntu 18.04 x86_64
Build date: 2023/01/10 23:00
Revision: c825df0ebc392580c3443ca51b28c6cb88be266d
PROBLEM DESCRIPTION
PROBLEM 1 : ports 7080 and 7081 open and vulnerable for external attack
PROBLEM 2 : modsecurity overload
PROBLEM 3 : WordPress XMLRPC attacks via ports 7081 (not often on 7080) over HTTP/1.0
PROBLEM 4 : default Nginx config does not include a "deny all;" directive for xmlrpc.php calls
NOTE 1 : when having Nginx as reverse proxy, the usage of the "internal" directive closes connections, but does NOT prevent that connections are established
NOTE 2 : when running 3 servers, the average of blocked IPs was 5000 to 6000 unique IP addresses per 24 hours!!!!
STEPS TO REPRODUCE
1 - install WordPress and Modsecurity
2 - inspect the modsec_audit.log and count abusive IPs : grep -i 7081 /var/log/modsec_audit.log | wc -l
ACTUAL RESULT
A lot of blocked IPs, attempting to brute force WordPress installations one way or another.
EXPECTED RESULT
SOLUTION 1 : change Nginx default config to contain
location ~* /xmlrpc.php {
deny all;
#access_log configuration is optional;
}
at the vhost level ....... and please consider solution 2, since this directive is blocking all attempts (read: depending on which port Nginx is listening and which port is used to attack) and hence makes blocking aggressive and/or makes it more challenging to log all offending IPs and create a blocklist (read: to be used by Nginx).
SOLUTION 2 : add a throttle mechanism in the location directive, for instance of the kind
limit_req_zone $binary_remote_addr zone=one:15m rate=5r/s;
and please note that this is important, since this would offer a solution to the really fast brute force hack attempts and also would enable to create a blocklist (read: to be used by Nginx).
SOLUTION 3 : use Fail2Ban WITH INCREMENTAL BAN TIME ........ see my other bug report about the Web UI of Fail2Ban
ANY ADDITIONAL INFORMATION
IMPORTANT : the scripts are not really advanced, but please note that
- when blocking access to xmlrpc.php via Nginx : other brute force methods are immediately following
- when blocking those other methods : brute force actions become more severe and faster
IMPORTANT : using Fail2Ban (or even the Plesk firewall) as the only option to combat these types of brute forcing is not at all desirable! The vast amount of offending IPs would create big problems ...... and can cause system resource overusage of such a kind that one can break all defense mechanisms.
YOUR EXPECTATIONS FROM PLESK SERVICE TEAM
Confirm bug
