Aldolat.it — Post con tag Webserver

La direttiva Order in Apache

aldolat@gmail.com (Aldo Latino) — Sun, 06 Aug 2023 10:25:24 +0200

Uno dei punti fondamentali¹ da comprendere per il controllo del proprio server Apache è la direttiva Order, quella in cui vediamo Allow,Deny o Deny,Allow. Non è di immediata comprensione ma, una volta capito il meccanismo che sta alla base, non dovrebbe risultare difficile applicarla con relativa semplicità.

Poniamo il caso che abbiamo queste direttive nel nostro file .htaccess:

<Directory "/www">
    Order Deny,Allow
    Deny from all
    Allow from 192.168.0.100 123.456.
    Allow from example.org example.com
    Allow from foo.example.
</Directory>

Quello su cui questo post si concentra è la riga che inizia con Order. Questa direttiva dice ad Apache in quale ordine deve applicare le successive direttive Deny e Allow, vale a dire se prima l’una o l’altra. Nel caso in esempio, l’ordine è prima quelle Deny e poi quelle Allow. L’ordine è importante perché in Apache l’ultima direttiva ha priorità sulle precedenti.

Detta in modo semplice quelle righe significano:

nega (Deny) a tutti l’accesso alla directory /www;
permettilo (Allow) a chi proviene dall’indirizzo IP 192.168.0.100 e a chi abbia indirizzo IP che comincia con 123.456.;
permettilo (Allow) a chi proviene dal dominio example.org o da example.com;
permettilo (Allow) a chi proviene dal dominio foo.example. di qualsiasi TLD.

Se, invece, invertissimo l’ordine della direttiva Order da Order Deny,Allow a Order Allow,Deny, l’effetto sarebbe di bloccare tutti. Avremmo infatti che Apache leggerebbe così:

permetti l’accesso all’indirizzo IP 192.168.0.100 e a chi abbia…;
permetti l’accesso al dominio example.org…;
ecc…
nega a tutti l’accesso.

La regola finale avrebbe la prevalenza sulle precedenti, finendo così per bloccare tutti.

L’ordine con cui le direttive sono scritte nel blocco di codice non ha invece alcuna influenza.² Potremmo anche scriverle così:

<Directory "/www">
    Order Deny,Allow
    Allow from 192.168.0.100 123.456.
    Allow from example.org example.com
    Deny from all
    Allow from foo.example.
</Directory>

In ogni caso Apache leggerà e applicherà in blocco prima tutte le direttive Deny e poi tutte quelle Allow. In linea generale, Jeff Starr³ consiglia di tenere queste due regole di base:

Quando si vogliono bloccare specifici indirizzi, usare Order Allow,Deny, quindi la direttiva Allow from all e a seguire le direttive Deny from .... Ad esempio:
```
<Directory "/www">
    Order Allow,Deny
    Allow from all
    Deny from 192.168.0.100
</Directory>
```
Quando si vogliono permettere specifici indirizzi, usare Order Deny,Allow, quindi la direttiva Deny from all e a seguire le direttive Allow from .... Ad esempio:
```
<Directory "/www">
    Order Deny,Allow
    Deny from all
    Allow from 192.168.0.100
</Directory>
```

Bibliografia

The Apache Software Foundation, Apache Module mod_access_compat.
Ben Laurie – Peter Laurie, Apache: The Definitive Guide, O’Reilly & Associates, 2001.
Jeff Starr, .htaccess made easy, Perishable Press Books, aprile 2023.

«Getting the order and syntax of these directives is critical to their operation». Jeff Starr, .htaccess made easy, Perishable Press Books, aprile 2023, p. 123. ↩︎
«The order in which lines appear in the configuration files is not significant — all Allow lines are processed as one group, all Deny lines are considered as another, and the default state is considered by itself». Cfr. The Apache Software Foundation, Apache Module mod_access_compat, par. “Order Directive”. ↩︎
Jeff Starr, op. cit., p. 123. ↩︎

L'articolo La direttiva Order in Apache è uno scritto di aldolat.it. Rispettane le condizioni di licenza.

Reindirizzamenti con htaccess

aldolat@gmail.com (Aldo Latino) — Sun, 01 May 2022 10:18:47 +0200

Uno degli aspetti più intriganti che mi è capitato nella mia avventura di migrazione da WordPress a Hugo è quella dei reindirizzamenti dei post da un permalink a un altro.

Nella precedente installazione di WordPress la struttura dei permalink era la seguente:

https://www.aldolat.it/<ANNO>/<CATEGORIA>/<TITOLO-DEL-POST>/

In Hugo ho deciso di cambiarla togliendo <CATEGORIA>/ dall’indirizzo e premettendovi posts/:

https://www.aldolat.it/posts/<ANNO>/<TITOLO-DEL-POST>/

lasciando così la stessa struttura in cui sono organizzati file e directory nel mio filesystem.

Chiaramente questo significa che il vecchio indirizzo non funziona più e genera un errore 404. Ma è possibile intervenire con una regola nel file .htaccess piuttosto semplice. Eccola.

RedirectMatch 301 ^/(\d{4})/(.*)/(.*)/$ https://www.aldolat.it/posts/$1/$3

Questo è quello che fa la regola, la quale utilizza mod_alias, il sistema più semplice per reindizzare cose, rispetto a mod_rewrite, più potente ma un pelo più complesso:

RedirectMatch: attiva mod_alias per il reindirizzamento.
301: applica una stato HTTP di Moved Permanently.
^/(\d{4})/(.*)/(.*)/$: contiene la stringa da cercare. In questo caso si tratta di una regex che in sostanza dice questo: trova una stringa che inizia (^) con /(quattro numeri) e prosegue con due parti contenenti qualsiasi carattere e delimitate con slash (/) e queste due parti sono la parte finale della stringa ($). Fate attenzione alle parentesi tonde, in quanto queste saranno considerate da mod_alias come variabili che si possono usare per il reindirizzamento. Le variabili saranno numerate sequenzialmente da mod_alias a partire da 1.
https://www.aldolat.it/posts/$1/$3: reindirizza ciò che hai trovato all’indirizzo indicato, sostituendo le variabili $1 e $3 in questo modo:
1. $1: fa riferimento al primo gruppo di parentesi tonde, vale a dire (\d{4});
2. $3: fa riferimento al terzo gruppo di parentesi tonde, vale a dire (.*).

Il risultato sarà quindi che un indirizzo del tipo:

<https://www.aldolat.it/2012/news/htaccess-made-easy/>

verrà reindirizzato a:

<https://www.aldolat.it/posts/2012/htaccess-made-easy/>

L'articolo Reindirizzamenti con htaccess è uno scritto di aldolat.it. Rispettane le condizioni di licenza.

Redirigere la chiamata a file non esistenti

aldolat@gmail.com (Aldo Latino) — Sun, 15 Mar 2015 10:05:12 +0000

Restando in tema di file .htaccess, condivido con voi qualche modifica che ho introdotto recentemente dopo aver dato uno sguardo al registro degli errori del mio hosting provider. Tra le righe presenti notavo che si tentava si accedere ripetutamente al file favicon.ico sia cercandolo nella directory radice del sito (dove non è presente) sia in altre posizioni, nonostante la chiamata al file favicon.ico era correttamente generata nell’HTML dal tema in uso.

Per questo motivo ho aggiunto alcune righe in .htaccess, in modo da dirigere la ricerca del file in questione.

Il file favicon.ico

Ecco cosa ho aggiunto nel file di configurazione di Apache:

<IfModule mod_rewrite.c>
    RewriteEngine on
    RewriteCond %{REQUEST_URI} !^/percorso/a/favicon\.ico [NC]
    RewriteCond %{REQUEST_URI} favicon\.ico [NC]
    RewriteRule .* http://www.example.com/percorso/a/favicon.ico [R=301,L]
</IfModule>

Queste righe fanno le seguenti operazioni:

controllare se è presente il modulo mod_rewrite in Apache;
attivare il motore di rewrite;
porre la prima condizione: l’URL richiesto non è quello del file favicon.ico corretto;
porre la seconda condizione: l’URL contiene la stringa favicon.ico;
avviare la regola: indirizza la richiesta alla posizione corretta e applica uno status HTML 301 “Moved permanently”.

Così, ad esempio, uno qualsiasi dei seguenti indirizzi:

http://www.example.com/files/favicon.ico
http://www.example.com/tag/apache/favicon.ico

viene indirizzato a:

http://www.example.com/percorso/a/favicon.ico

dove è presente fisicamente il file.

Altri file

Il file favicon.ico non è il solo ad essere vittima di questa ricerca errata, ma anche robots.txt, sitemap.xml e humans.txt. Possiamo quindi aggiungere anche queste righe, dove ogni blocco di righe si riferisce a uno specifico file:

<IfModule mod_rewrite.c>
    RewriteEngine on
    RewriteCond %{REQUEST_URI} !^/robots\.txt [NC]
    RewriteCond %{REQUEST_URI} robots\.txt [NC]
    RewriteRule .* http://www.domain.tld/robots.txt [R=301,L]
</IfModule>
<IfModule mod_rewrite.c>
    RewriteEngine on
    RewriteCond %{REQUEST_URI} !^/sitemap\.xml [NC]
    RewriteCond %{REQUEST_URI} sitemap\.xml [NC]
    RewriteRule .* http://www.domain.tld/sitemap.xml [R=301,L]
</IfModule>
<IfModule mod_rewrite.c>
    RewriteEngine on
    RewriteCond %{REQUEST_URI} !^/humans\.txt [NC]
    RewriteCond %{REQUEST_URI} humans\.txt [NC]
    RewriteRule .* http://www.domain.tld/humans.txt [R=301,L]
</IfModule>

Potete trovare l’argomento spiegato più in dettaglio nel libro di Jeff Starr, .htaccess made easy, A practical guide for administrators, designers & developers, Perishable Press, 2013, di cui vi ho già parlato in questo precedente post.

Photo courtesy: peterstuartmill, Senza titolo, CC0 Public Domain.

L'articolo Redirigere la chiamata a file non esistenti è uno scritto di aldolat.it. Rispettane le condizioni di licenza.

Bloccare l’accesso al file wp-login.php

aldolat@gmail.com (Aldo Latino) — Sat, 31 Jan 2015 20:35:00 +0000

È da molti mesi che riscontro tentativi continui di accesso non autorizzato alla dashboard di WordPress: qualcuno/qualcosa tenta senza sosta di indovinare il nome utente dell’amministratore e della sua password. Me ne accorgo dalle segnalazioni che mi arrivano tramite il plugin Limit login attempts.

Il plugin, che pare non essere più mantenuto (e per questo motivo cerco un’alternativa), fa bene il suo lavoro ma, nonostante ciò, non è bello per me ricevere tutte quelle email giornaliere da parte sua. Per cui ho deciso di risolvere alla base il problema.

Negare l’accesso

Poiché l’azione che si tenta è quella di autenticarsi, la via di ingresso è il file wp-login.php: è sufficiente quindi bloccare l’accesso a questo file. Bloccare l’accesso al file significa, però, che neanche noi riusciremo a entrare nella dashboard di WordPress: dovremo quindi permettere l’accesso al nostro indirizzo IP.

Basta aggiungere poche righe al file .htaccess presente nella directory radice del proprio dominio:

<Files ~ "wp-login.php">
Order Deny,Allow
Deny from all
Allow from 12.
</Files>

Con queste righe stiamo dicendo ad Apache di bloccare l’accesso al file wp-login.php a tutti (Deny from all) tranne a coloro il cui indirizzo IP inizia con 12. (Allow from 12.). Chiaramente questo numero è quello che interessa a me, per cui dovete conoscere con quale range di indirizzi generalmente il vostro provider vi fa accedere ad Internet. Se avete un indirizzo IP statico, potete aggiungerlo per intero:

Allow from 123.123.123.123

A coloro il cui indirizzo IP non inizia con 12. o non è quello esatto che avete definito, Apache restituirà un errore 403 “Accesso negato”, che eventualmente potete anche personalizzare, se il vostro hosting provider ve lo permette.

Una volta messe in opera quelle righe, il log del server mostrerà qualcosa del genere:

[Sat Jan 31 02:10:30 2015] [error] [client 5.196.253.201] client denied by server configuration: /path/to/domain.tld/folder/wp-login.php, referer: http://www.domain.tld/
[Sat Jan 31 02:10:31 2015] [error] [client 5.196.253.201] client denied by server configuration: /path/to/domain.tld/folder/wp-login.php, referer: http://www.domain.tld/wp-login.php?action=register
[Sat Jan 31 02:32:18 2015] [error] [client 192.240.201.20] client denied by server configuration: /path/to/domain.tld/folder/wp-login.php, referer: http://www.domain.tld/
[Sat Jan 31 02:32:18 2015] [error] [client 192.240.201.20] client denied by server configuration: /path/to/domain.tld/folder/wp-login.php, referer: http://www.domain.tld/wp-login.php?action=register
[Sat Jan 31 03:02:45 2015] [error] [client 104.143.23.249] client denied by server configuration: /path/to/domain.tld/folder/wp-login.php, referer: http://www.domain.tld/
[Sat Jan 31 03:02:46 2015] [error] [client 104.143.23.249] client denied by server configuration: /path/to/domain.tld/folder/wp-login.php, referer: http://www.domain.tld/wp-login.php?action=register
[Sat Jan 31 03:28:20 2015] [error] [client 173.232.118.182] client denied by server configuration: /path/to/domain.tld/folder/wp-login.php, referer: http://www.domain.tld/
[Sat Jan 31 03:28:21 2015] [error] [client 173.232.118.182] client denied by server configuration: /path/to/domain.tld/folder/wp-login.php, referer: http://www.domain.tld/wp-login.php?action=register
[Sat Jan 31 03:29:33 2015] [error] [client 198.23.134.163] client denied by server configuration: /path/to/domain.tld/folder/wp-login.php, referer: http://www.domain.tld/
[Sat Jan 31 03:29:33 2015] [error] [client 198.23.134.163] client denied by server configuration: /path/to/domain.tld/folder/wp-login.php, referer: http://www.domain.tld/wp-login.php?action=register
[Sat Jan 31 03:33:08 2015] [error] [client 37.59.75.59] client denied by server configuration: /path/to/domain.tld/folder/wp-login.php, referer: http://www.domain.tld/
[Sat Jan 31 03:33:08 2015] [error] [client 37.59.75.59] client denied by server configuration: /path/to/domain.tld/folder/wp-login.php, referer: http://www.domain.tld/wp-login.php?action=register
[Sat Jan 31 03:36:43 2015] [error] [client 88.251.177.222] client denied by server configuration: /path/to/domain.tld/folder/wp-login.php
[Sat Jan 31 03:39:33 2015] [error] [client 151.80.69.186] client denied by server configuration: /path/to/domain.tld/folder/wp-login.php, referer: http://www.domain.tld/

con la conferma che Apache sta bloccando gli accessi (client denied by server configuration). E le email di Limit login attempts sono terminate.

I motori di ricerca

Per evitare errori di scansione dei motori di ricerca ho inserito nel file robots.txt due righe che evitino la scansione delle pagine legate all’autenticazione, ad esempio:

User-agent: *
Disallow: /wp-login.php
Disallow: /wp-login.php?action=register

Chiaramente quanto sopra forse non è la soluzione migliore al problema, ma devo dire che sta funzionando bene per me ed è di facilissima implementazione.

L'articolo Bloccare l’accesso al file wp-login.php è uno scritto di aldolat.it. Rispettane le condizioni di licenza.

Spostare WordPress: i consigli degli esperti

aldolat@gmail.com (Aldo Latino) — Sun, 29 May 2011 11:20:42 +0000

Nella giornata di ieri del WordCamp di Milano, Andrea Beggi ha proposto un interessante intervento (qui il video registrato) su un argomento che ha affrontato più volte sul suo blog: come spostare la propria installazione di WordPress da un hosting (un hosting in senso stretto o VPS o server dedicato) a un altro. Di questo intervento ha anche rilasciato i suoi appunti nel suo post di oggi (qui le slide).

Tra i miei segnalibri su ~~Delicious~~ Pinboard ho ripescato quelli che mi sono conservato su questo argomento e ve li ripropongo qui sotto:

Penso sia sempre bene ascoltare più voci e, come vedete, gli autori sono tra i più noti su WordPress.

L'articolo Spostare WordPress: i consigli degli esperti è uno scritto di aldolat.it. Rispettane le condizioni di licenza.