Block an IP address based on the X-Forwarded-For header:
1 2 3 |
RewriteEngine on RewriteCond %{HTTP:X-Forwarded-For} 172\.89\.51\.228 RewriteRule .* - [F] |
Block an IP address based on the X-Forwarded-For header:
1 2 3 |
RewriteEngine on RewriteCond %{HTTP:X-Forwarded-For} 172\.89\.51\.228 RewriteRule .* - [F] |
Sort “find” results by date:
1 |
find . -type f -printf "%T@\t%Tc %6k KiB %p\n" | sort -n | cut -f 2- |
Find files newer then a specific file:
1 |
find . -type f -newer somefile.txt |
And combined:
1 |
find . -type f -newer somefile.txt -printf "%T@\t%Tc %6k KiB %p\n" | sort -n | cut -f 2- |
We want to password protect a WordPress development site but allow unauthenticated access to the wp-json/ path. Hosting platform is Plesk with Apache 2.4. We’ll assume the domain is “acme.com” and the assigned IP is “w.x.y.z”.
There are probably better ways to accomplish the goal but this approach seems to work.
Step 1. – In Plesk add a Protected Directory named “/donotremove” and add appropriate user/passwords.
Step 2. – In Plesk on the “Apache & nginx Setting” screen under “Additional nginx directives” add the following:
1 2 3 4 5 6 7 8 9 |
location ~ /wp-json { proxy_set_header AUTH_OVERRIDE true; proxy_pass http://w.x.y.z:7080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Accel-Internal /internal-nginx-static-location; access_log on; } |
Step 3. – In Plesk on the “Apache & nginx Setting” screen under “Additional directives for HTTP” and “Additional directives for HTTPS” add the following:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
<Directory "/var/www/vhosts/acme.com/httpdocs" > # set an environment variable if there is an AUTH_OVERRIDE header SetEnvIf AUTH_OVERRIDE ^true AUTH_REQUEST # basic auth AuthName "Dev Login" AuthType Basic # password file is maintained from Plesk AuthUserFile /var/www/vhosts/system/acme.com/pd/d..httpdocs@donotremove <RequireAny> # require login Require valid-user # allow request if the environment variable is set Require env AUTH_REQUEST </RequireAny> </Directory> |
Situations have been observed where the network interface will fail to start on an AWS EC2 instance created from a snapshot of another instance. Since AWS EC2 lacks a facility to access the console, it’s not possible to login and fix this condition. One way to solve the problem is to:
This will work but it takes significant effort and you have to have an available alternate server to mount and fix the root volume.
An alternate approach is to use the “User data” feature when creating the EC2 instance to inject a script that fixes the network config. For example let’s assume that we have a CentOS based AMI image named “host1-backup” which we wish to use create a new EC2 instance. The network config in the image has the MAC address explicitly specified in “/etc/sysconfig/network-scripts/ifcfg-ens5”. When the AMI boots, the specified MAC address does not match the interface and the new instance fails to start networking. This can be resolved as follows:
a. Launch a new EC2 using the “host1-backup” AMI from the AWS console. On “Step 3: Configure instance details”, in the “Advanced details” section enter the following:
1 2 |
#!/bin/bash sed -i 's/HWADDR=.*//g' /etc/sysconfig/network-scripts/ifcfg-ens5 |
b. When the instance starts the user data script will run and remove the HWADDR line from the interface control file.
c. Reboot the instance to allow the modified network config to activate.
There are other cases where this approach might be useful. for example a broken iptables / firewall config could be disabled from user data script.
Note that the “user data” script runs late in the boot process so it can not be used to fix problem like a missing volume from /etc/fstab or a corrupt boot loader.
In some cases you may wish to allow Diffie–Hellman (DHE) ciphers in order to support older clients like IE on Windows 7. On Plesk we often use the “intermediate” level in the Mozilla cipher set as described here:
https://wiki.mozilla.org/Security/Server_Side_TLS
The “intermediate” level includes:
Of course the “ECDSA” or “Elliptic Curve Digital Signature Algorithm” ciphers will only be available if you are using ECC signed certificates.
Additionally the “DHE” ciphers will not be available by default if you are using Nginx releases greater then 1.11. With the 1.11 release Nginx moved the DHE key to an external setting instead of an internally generated key. The stock Nginx packages on Ubuntu and CentoOS do not setup a DHE key which results in the DHE ciphers not being available.
To address this problem, start by generating a key:
1 2 |
cd /etc/ssl/certs openssl dhparam -out dhparam.pem 4096 |
Next tell Nginx where to find the key:
1 |
echo "ssl_dhparam /etc/ssl/certs/dhparam.pem;" > /etc/nginx/conf.d/ssl_dh.conf |
Verify Nginx config and restart:
1 2 |
nginx -t systemctl restart nginx |
Now the DHE ciphers will be offered to clients and Window 7 / IE clients will be able to connect to the sites hosted on the server.