Apache Web Log Analysis Lab

Lab Blue Team focalizzato sull'analisi dei log del server HTTP Apache per rilevare attività di scansione web, enumerazione delle directory e tentativi di path traversal.

Obiettivo

Installare ed esporre un server web Apache in un ambiente di laboratorio isolato, simulare la scansione web automatizzata utilizzando strumenti standard del settore e analizzare i log generati da una prospettiva Blue Team — identificando pattern di attacco, firme degli strumenti e indicatori di attività di ricognizione malevola.

Ambiente

Passaggi Eseguiti

1. Validazione del Servizio Apache

Confermato che il server HTTP Apache era attivo e in esecuzione sulla macchina target.```bash sudo systemctl status apache2 --no-pager

Risultato: `active (running)` since Wed 2026-05-06 21:09:17. Apache 2.4.67 (Debian), Main PID 3164, 55 tasks active.

---

### 2. Identificazione dell'IP del target

Identificato l'indirizzo IP della macchina target Debian.```bash
ip a

Target IP: 10.0.2.15/24 — interface enp0s3

3. Test di connettività

Verificata la connettività di rete tra la macchina attaccante Kali e il target Debian.```bash ping -c 4 10.0.2.15

**Result:** 4 packets transmitted, 4 received, 0% packet loss. RTT min/avg/max: 0.495/1.288/2.139ms.

---

### 4. Test del Browser Apache

Accesso al server Apache dal browser Kali per confermare la disponibilità del servizio HTTP.```
http://10.0.2.15

Risultato: Pagina predefinita di Apache2 su Debian caricata con successo — conferma che il server web era raggiungibile e rispondeva alle richieste HTTP.

5. Configurazione del Contenuto Web

Create directory e pagine di test sul server di destinazione per simulare una struttura realistica di un'applicazione web.```bash sudo mkdir -p /var/www/html/admin sudo mkdir -p /var/www/html/backup sudo mkdir -p /var/www/html/login echo "

Admin Panel

Login Page

Directory create: `/admin`, `/backup`, `/login`

---

### 6. Nikto Scansione

Eseguito Nikto contro il server web di destinazione per simulare una scansione automatica delle vulnerabilità.```bash
nikto -h http://10.0.2.15

Nikto v2.5.0 — Ora di inizio: 2026-05-06 20:16:56 — Ora di fine: 20:17:13 (17 secondi)

Risultati segnalati da Nikto:

• Server: Apache/2.4.67 (Debian)
• Missing header: X-Frame-Options — protezione clickjacking assente
• Missing header: X-Content-Type-Options — protezione MIME sniffing assente
• ETag leak: Il server potrebbe perdere numeri di inode tramite ETag (CVE-2003-1418)
• Allowed methods: GET, POST, OPTIONS, HEAD
• Interesting directories found: /admin/, /backup/, /login/
• Confirmed: /admin/index.html — Pagina di accesso admin accessibile
• Total requests: 8102 in 17 secondi

7. Scansione Dirb

Eseguita Dirb per effettuare brute forcing delle directory sul server web di destinazione.```bash dirb http://10.0.2.15

**DIRB v2.22 — Inizio: Wed May 6 20:19:50 2026 — Fine: 20:19:59 2026 (9 secondi)**

Wordlist utilizzata: `/usr/share/dirb/wordlists/common.txt` — 4612 parole testate

Directory e file trovati:

| URL                               | Code | Size  |
| --------------------------------- | ---- | ----- |
| http://10.0.2.15/index.html       | 200  | 10703 |
| http://10.0.2.15/server-status    | 403  | 314   |
| http://10.0.2.15/admin/           | 200  | —     |
| http://10.0.2.15/admin/index.html | 200  | 21    |
| http://10.0.2.15/backup/          | 200  | —     |
| http://10.0.2.15/login/           | 200  | —     |
| http://10.0.2.15/login/index.html | 200  | 20    |

**Attenzione:** La directory `/backup/` ha il listing abilitato — nessun file index presente, i contenuti della directory sono direttamente navigabili.

**Totale scaricato:** 13836 byte — **Trovate:** 4 risorse

---

### 8. Analisi del Log di Accesso

Ispezionate le voci grezze del log di accesso per identificare lo schema dell'attacco.```bash
sudo cat /var/log/apache2/access.log

Esempi di voci dalla fase di scansione Nikto (21:18:32):``` 10.0.2.5 - - [06/May/2026:21:18:32 -0300] "GET /10.0.2.15.tar.bz2 HTTP/1.1" 404 527 10.0.2.5 - - [06/May/2026:21:18:32 -0300] "GET /10_0_2_15.gz HTTP/1.1" 404 527 10.0.2.5 - - [06/May/2026:21:18:32 -0300] "GET /10.0.2.15.sql HTTP/1.1" 404 527 10.0.2.5 - - [06/May/2026:21:18:32 -0300] "GET /10.0.2.15.zip HTTP/1.1" 404 527

Esempi di voci dalla fase di scansione Dirb (21:21:34):```
10.0.2.5 - - [06/May/2026:21:21:34 -0300] "GET /login/xsql HTTP/1.1" 404 472
10.0.2.5 - - [06/May/2026:21:21:34 -0300] "GET /login/xxx HTTP/1.1" 404 472
10.0.2.5 - - [06/May/2026:21:21:34 -0300] "GET /login/zimbra HTTP/1.1" 404 472
10.0.2.5 - - [06/May/2026:21:21:34 -0300] "GET /login/zoom HTTP/1.1" 404 472

Pattern osservato: Centinaia di richieste sequenziali nello stesso secondo, tutte miranti a percorsi inesistenti — coerente con un comportamento di scansione automatizzato.

9. Pattern di scansione per IP sorgente

Filtrate tutte le voci del log di accesso provenienti dall'IP dell'attaccante.```bash sudo grep "10.0.2.5" /var/log/apache2/access.log | head -30

Ulteriori modelli osservati:

- Nikot ha tentato di accedere a file di backup utilizzando l'IP del server come nome file (ad es., `10.0.2.15.tar.bz2`, `10.0.2.15.sql`, `10.0.2.15.zip`)
- Dirb ha iterato attraverso wordlist ordinate alfabeticamente mirando a ciascuna directory scoperta
- Entrambi gli strumenti hanno generato richieste a velocità macchina — molteplici voci al secondo dalla stessa gamma di porte di origine

---

### 10. Distribuzione dei Codici di Stato HTTP

Conteggiate le richieste per codice di risposta HTTP per quantificare la superficie di attacco.```bash
sudo grep " 200 " /var/log/apache2/access.log | wc -l
sudo grep " 403 " /var/log/apache2/access.log | wc -l
sudo grep " 404 " /var/log/apache2/access.log | wc -l

Totale errori 404: 21.740 — la stragrande maggioranza delle richieste ha riguardato percorsi che non esistono, che è la caratteristica distintiva del brute-forcing automatico di directory.

11. Totale Richieste per IP Attaccante

Contate tutte le voci del log di accesso provenienti dall'attaccante.```bash sudo grep "10.0.2.5" /var/log/apache2/access.log | wc -l

**Totale richieste da 10.0.2.5: 21,962**

---

### 12. Identificazione delle Firme degli Strumenti

Ricerca di firme specifiche dello scanner nel log di accesso.

#### Firma di Nikto```bash
sudo grep "nikto" /var/log/apache2/access.log | head -5

Risultato:``` 10.0.2.5 - - [06/May/2026:21:18:32 -0300] "PUT /nikto-test-pk9VPSjF.html HTTP/1.1" 405 590 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"

Nikto ha creato un file di test (`nikto-test-pk9VPSjF.html`) tramite richiesta PUT per verificare i permessi di scrittura sul server.

#### Dirb signature```bash
sudo grep "DirBuster\|dirb" /var/log/apache2/access.log | head -5

Risultato:``` 10.0.2.5 - - [06/May/2026:21:21:26 -0300] "GET /dirb HTTP/1.1" 404 472 10.0.2.5 - - [06/May/2026:21:21:26 -0300] "GET /dirbmark HTTP/1.1" 404 472 10.0.2.5 - - [06/May/2026:21:21:29 -0300] "GET /admin/dirb HTTP/1.1" 404 472 10.0.2.5 - - [06/May/2026:21:21:29 -0300] "GET /admin/dirbmark HTTP/1.1" 404 472 10.0.2.5 - - [06/May/2026:21:21:32 -0300] "GET /login/dirb HTTP/1.1" 404 472

Il nome stesso di Dirb appare nella wordlist che utilizza, lasciando una chiara firma nei log.

---

### 13. Analisi dei Log degli Errori

Controllato il log degli errori di Apache per eventi di sicurezza lato server attivati dalla scansione.```bash
sudo cat /var/log/apache2/error.log

Eventi critici trovati:

Path Traversal Attempts (Directory Traversal)

Nikto ha tentato di accedere a file di sistema sensibili attraversando i confini delle directory:``` [client 10.0.2.5] AH10244: invalid URI path (/../../../../../../../../../../../../etc/shadow) [client 10.0.2.5] AH10244: invalid URI path (/../../../../../../../../../../etc/passwd) [client 10.0.2.5] AH10244: invalid URI path (/%2E%2E/%2E%2E/%2E%2E/%2E%2E/%2E%2E/windows/win.ini) [client 10.0.2.5] AH10244: invalid URI path (/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd) [client 10.0.2.5] AH10244: invalid URI path (/../../../../../../../../../boot.ini) [client 10.0.2.5] AH10244: invalid URI path (/../../../../winnt/repair/sam._)

Targets inclusi: `/etc/passwd`, `/etc/shadow`, `boot.ini`, `win.ini`, Windows SAM database — tutti i classici target di path traversal.

#### Metodi HTTP non validi

Nikto ha testato metodi HTTP non standard per identificare configurazioni errate:```
[client 10.0.2.5] AH00135: Invalid method in request DIWHWPJH / HTTP/1.1
[client 10.0.2.5] AH00135: Invalid method in request DEBUG / HTTP/1.1
[client 10.0.2.5] AH00135: Invalid method in request TRACK / HTTP/1.0
[client 10.0.2.5] AH00135: Invalid method in request SEARCH / HTTP/1.1
[client 10.0.2.5] AH00135: Invalid method in request INDEX / HTTP/1.1

Tentativi di accesso a file protetti

Entrambi gli strumenti hanno tentato di accedere a file di configurazione protetti da Apache:``` [client 10.0.2.5] AH01630: client denied by server configuration: /var/www/html/.htpasswd [client 10.0.2.5] AH01630: client denied by server configuration: /var/www/html/.htaccess [client 10.0.2.5] AH01630: client denied by server configuration: /var/www/html/server-status [client 10.0.2.5] AH01630: client denied by server configuration: /var/www/html/admin/.htpasswd [client 10.0.2.5] AH01630: client denied by server configuration: /var/www/html/login/.htpasswd

#### Path Traversal Specifico di VMware

Nikto ha anche testato l'esposizione dell'infrastruttura VMware:```
[client 10.0.2.5] AH10244: invalid URI path (/sdk/%2E%2E/%2E%2E/%2E%2E/%2E%2E/%2E%2E/%2E%2E/etc/vmware/hostd/vmInventory.xml)

Analisi

I log di accesso e di errore hanno rivelato uno schema di attacco automatizzato in due fasi proveniente da un singolo indirizzo IP (10.0.2.5) mirato al server web Apache sulla porta 80.

Fase 1 — Scansione delle vulnerabilità (Nikto, 21:14 – 21:18)

Nikto ha effettuato 8.102 richieste in 17 secondi, testando le vulnerabilità web note, l'assenza di header di sicurezza, metodi HTTP pericolosi e vettori di path traversal. Il log degli errori ha registrato molteplici tentativi di accesso a /etc/passwd, /etc/shadow, boot.ini e file SAM di Windows — tutti bloccati dalla validazione URI di Apache. Nikto ha anche tentato una richiesta PUT per creare un file di prova sul server, confermando la verifica dei permessi di scrittura.

Fase 2 — Enumerazione delle directory (Dirb, 21:19 – 21:21)

Dirb ha testato 4.612 parole dalla sua wordlist comune contro la root e ogni sottodirectory scoperta. Ciò ha generato la maggior parte dei 21.740 errori 404 osservati. Dirb ha identificato con successo /admin/, /backup/ e /login/ come directory valide. È emerso che la directory /backup/ aveva l'elenco delle directory abilitato — una misconfigurazione significativa che avrebbe permesso a un attaccante di sfogliarne direttamente il contenuto.

Valutazione combinata

La concentrazione di 21.962 richieste HTTP da un unico IP sorgente in circa 7 minuti, unita alla presenza di tentativi di path traversal, metodi HTTP non validi e firme specifiche degli strumenti sia nei log di accesso che in quelli di errore, costituisce una chiara evidenza di attività di ricognizione web automatizzata.

Non è stata osservata alcuna compromissione riuscita. Tutti i tentativi di path traversal sono stati respinti dal motore di validazione URI di Apache. L'accesso ai file protetti (.htpasswd, .htaccess, server-status) è stato negato dalla configurazione del server.

Indicatori chiave

Raccomandazioni difensive

Sulla base dei risultati, si raccomandano i seguenti controlli:

• Aggiungere gli header di sicurezza alla configurazione di Apache: X-Frame-Options, X-Content-Type-Options, Content-Security-Policy
• Disabilitare gli header ETag per evitare la fuga di informazioni sugli inode
• Limitare i metodi HTTP consentiti a GET, POST, HEAD soltanto
• Disabilitare l'elenco delle directory per tutte le directory, in particolare /backup/
• Limitare l'accesso a /server-status al solo localhost
• Implementare il rate limiting per bloccare gli IP che generano richieste eccessive al secondo
• Distribuire un WAF (Web Application Firewall) per rilevare e bloccare pattern di path traversal
• Monitorare continuamente error.log per eventi AH10244 (percorso URI non valido)
• Rimuovere o limitare l'accesso alle directory sensibili (/admin/, /backup/) dall'esposizione pubblica
• Nascondere la versione di Apache dalle intestazioni di risposta HTTP (ServerTokens Prod, ServerSignature Off)

Conclusione

Questo laboratorio ha dimostrato come gli strumenti di scansione web automatizzati lascino pattern distinti e identificabili sia nei log di accesso che in quelli di errore di Apache. Correlando il volume di errori 404, la presenza di tentativi di path traversal in error.log, le richieste con metodi HTTP non validi e le firme specifiche degli strumenti nei percorsi delle richieste e nelle stringhe user-agent, è stato possibile ricostruire l'intera timeline dell'attacco e identificare gli strumenti utilizzati — senza alcuna conoscenza pregressa delle azioni dell'attaccante.

L'esercizio rafforza l'importanza del monitoraggio dei log del server web, della configurazione degli header di sicurezza e dei controlli di accesso alle directory come pratiche fondamentali per i Blue Team nell'infrastruttura web.

Strumenti utilizzati

• Kali Linux
• Debian 13
• Apache 2.4.67
• Nikto v2.5.0
• Dirb v2.22
• grep, wc, cat

Apache Web Log Analysis Lab

Laboratorio Blue Team incentrato sull'analisi dei log del server Apache per rilevare scansioni web, enumerazione di directory e tentativi di path traversal.

Obiettivo

Installare ed esporre un server web Apache in un ambiente di laboratorio isolato, simulare scansioni automatizzate utilizzando strumenti ampiamente usati nei test di sicurezza e analizzare i log generati da una prospettiva Blue Team — identificando pattern di attacco, firme degli strumenti e indicatori di attività di ricognizione malintenzionata.

Ambiente

Fasi eseguite

1. Validazione del servizio Apache

Confermato che il server Apache era attivo e in esecuzione sulla macchina bersaglio.```bash sudo systemctl status apache2 --no-pager

Resultato: `active (running)` da Wed 2026-05-06 21:09:17. Apache 2.4.67 (Debian), PID principale 3164, 55 attività attive.

---

### 2. Identificazione dell'IP del Target

Identificato l'indirizzo IP della macchina Debian target.```bash
ip a

IP del target: 10.0.2.15/24 — interfaccia enp0s3

3. Test di Connettività

Verificata la connettività di rete tra Kali e Debian.```bash ping -c 4 10.0.2.15

**Risultato:** 4 pacchetti trasmessi, 4 ricevuti, 0% di perdita. RTT min/medio/max: 0.495/1.288/2.139ms.

---

### 4. Test di Apache nel Browser

Accesso al server Apache dal browser di Kali per confermare la disponibilità del servizio HTTP.```
http://10.0.2.15

Risultato: Pagina predefinita di Apache2 Debian caricata con successo — confermando che il server web era accessibile e rispondeva alle richieste HTTP.

5. Creazione di Contenuto di Test

Creati directory e pagine di test sul server target per simulare una struttura di applicazione web realistica.```bash sudo mkdir -p /var/www/html/admin sudo mkdir -p /var/www/html/backup sudo mkdir -p /var/www/html/login echo "

Admin Panel

Login Page

Directory create: `/admin`, `/backup`, `/login`

---

### 6. Scansione con Nikto

Eseguito Nikto contro il server web target per simulare una scansione automatizzata delle vulnerabilità.```bash
nikto -h http://10.0.2.15

Nikto v2.5.0 — Inizio: 2026-05-06 20:16:56 — Fine: 20:17:13 (17 secondi)

Risultati riportati da Nikto:

• Server: Apache/2.4.67 (Debian)
• Header mancante: X-Frame-Options — protezione contro clickjacking assente
• Header mancante: X-Content-Type-Options — protezione contro MIME sniffing assente
• Fuga di ETag: Il server può divulgare numeri di inode tramite ETags (CVE-2003-1418)
• Metodi consentiti: GET, POST, OPTIONS, HEAD
• Directory interessanti trovate: /admin/, /backup/, /login/
• Confermato: /admin/index.html — pagina di amministrazione accessibile pubblicamente
• Totale richieste: 8102 in 17 secondi

7. Scansione con Dirb

Eseguito Dirb per eseguire brute force delle directory contro il server web di destinazione.```bash dirb http://10.0.2.15

**DIRB v2.22 — Inizio: Wed May 6 20:19:50 2026 — Fine: 20:19:59 2026 (9 secondi)**

Wordlist utilizzata: `/usr/share/dirb/wordlists/common.txt` — 4612 parole testate

Directory e file trovati:

| URL                               | Codice | Dimensione |
| --------------------------------- | ------ | ---------- |
| http://10.0.2.15/index.html       | 200    | 10703      |
| http://10.0.2.15/server-status    | 403    | 314        |
| http://10.0.2.15/admin/           | 200    | —          |
| http://10.0.2.15/admin/index.html | 200    | 21         |
| http://10.0.2.15/backup/          | 200    | —          |
| http://10.0.2.15/login/           | 200    | —          |
| http://10.0.2.15/login/index.html | 200    | 20         |

**Avviso:** La directory `/backup/` ha l'elenco abilitato — senza file di indice, il contenuto della directory può essere navigato direttamente.

**Totale scaricato:** 13836 byte — **Trovati:** 4 risorse

---

### 8. Analisi del Log di Accesso

Ispezionate le voci grezze del log di accesso per identificare il modello di attacco.```bash
sudo cat /var/log/apache2/access.log

Voci della fase di scan di Nikto (21:18:32):``` 10.0.2.5 - - [06/May/2026:21:18:32 -0300] "GET /10.0.2.15.tar.bz2 HTTP/1.1" 404 527 10.0.2.5 - - [06/May/2026:21:18:32 -0300] "GET /10_0_2_15.gz HTTP/1.1" 404 527 10.0.2.5 - - [06/May/2026:21:18:32 -0300] "GET /10.0.2.15.sql HTTP/1.1" 404 527 10.0.2.5 - - [06/May/2026:21:18:32 -0300] "GET /10.0.2.15.zip HTTP/1.1" 404 527

Voci della fase di scan di Dirb (21:21:34):```
10.0.2.5 - - [06/May/2026:21:21:34 -0300] "GET /login/xsql HTTP/1.1" 404 472
10.0.2.5 - - [06/May/2026:21:21:34 -0300] "GET /login/xxx HTTP/1.1" 404 472
10.0.2.5 - - [06/May/2026:21:21:34 -0300] "GET /login/zimbra HTTP/1.1" 404 472
10.0.2.5 - - [06/May/2026:21:21:34 -0300] "GET /login/zoom HTTP/1.1" 404 472

Modello osservato: Centinaia di richieste sequenziali nello stesso secondo, tutte dirette a percorsi inesistenti — comportamento coerente con scansione automatizzata.

9. Modello di Scansione per IP di Origine

Filtrate tutte le voci del log di accesso originate dall'IP dell'attaccante.```bash sudo grep "10.0.2.5" /var/log/apache2/access.log | head -30

Pattern aggiuntivi osservati:

- Nikto ha tentato di accedere a file di backup usando l'IP del server come nome file (es: `10.0.2.15.tar.bz2`, `10.0.2.15.sql`, `10.0.2.15.zip`)
- Dirb ha iterato le wordlist in ordine alfabetico indirizzando ogni directory scoperta
- Entrambi gli strumenti hanno generato richieste a velocità di macchina — ingressi multipli al secondo nella stessa fascia di porta di origine

---

### 10. Distribuzione dei Codici di Stato HTTP

Contate le richieste per codice di risposta HTTP per quantificare la superficie di attacco.```bash
sudo grep " 200 " /var/log/apache2/access.log | wc -l
sudo grep " 403 " /var/log/apache2/access.log | wc -l
sudo grep " 404 " /var/log/apache2/access.log | wc -l

Totale errori 404: 21.740 — la stragrande maggioranza delle richieste è stata direzionata verso percorsi inesistenti, che è la caratteristica distintiva del brute force automatizzato di directory.

11. Totale Richieste per IP dell'Attaccante

Contabilizzate tutte le voci del log di accesso originate dall'attaccante.```bash sudo grep "10.0.2.5" /var/log/apache2/access.log | wc -l

**Totale delle richieste da 10.0.2.5: 21.962**

---

### 12. Identificazione della Firma degli Strumenti

Cercate le firme specifiche degli scanner nel log di accesso.

#### Firma del Nikto```bash
sudo grep "nikto" /var/log/apache2/access.log | head -5

Risultato:``` 10.0.2.5 - - [06/May/2026:21:18:32 -0300] "PUT /nikto-test-pk9VPSjF.html HTTP/1.1" 405 590 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"

Nikto ha creato un file di test (`nikto-test-pk9VPSjF.html`) tramite richiesta PUT per verificare i permessi di scrittura sul server.

#### Firma del Dirb```bash
sudo grep "DirBuster\|dirb" /var/log/apache2/access.log | head -5

Risultato:``` 10.0.2.5 - - [06/May/2026:21:21:26 -0300] "GET /dirb HTTP/1.1" 404 472 10.0.2.5 - - [06/May/2026:21:21:26 -0300] "GET /dirbmark HTTP/1.1" 404 472 10.0.2.5 - - [06/May/2026:21:21:29 -0300] "GET /admin/dirb HTTP/1.1" 404 472 10.0.2.5 - - [06/May/2026:21:21:29 -0300] "GET /admin/dirbmark HTTP/1.1" 404 472 10.0.2.5 - - [06/May/2026:21:21:32 -0300] "GET /login/dirb HTTP/1.1" 404 472

Il nome stesso di Dirb appare nella wordlist che utilizza, lasciando una chiara firma nei log.

---

### 13. Analisi del Log degli Errori

Ispezionato il log degli errori di Apache per identificare eventi di sicurezza generati dallo scan.```bash
sudo cat /var/log/apache2/error.log

Eventi critici trovati:

Tentativi di Path Traversal (Directory Traversal)

Nikto ha tentato di accedere a file sensibili del sistema attraversando i limiti delle directory:``` [client 10.0.2.5] AH10244: invalid URI path (/../../../../../../../../../../../../etc/shadow) [client 10.0.2.5] AH10244: invalid URI path (/../../../../../../../../../../etc/passwd) [client 10.0.2.5] AH10244: invalid URI path (/%2E%2E/%2E%2E/%2E%2E/%2E%2E/%2E%2E/windows/win.ini) [client 10.0.2.5] AH10244: invalid URI path (/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd) [client 10.0.2.5] AH10244: invalid URI path (/../../../../../../../../../boot.ini) [client 10.0.2.5] AH10244: invalid URI path (/../../../../winnt/repair/sam._)

Alvos inclusi: `/etc/passwd`, `/etc/shadow`, `boot.ini`, `win.ini`, database SAM di Windows — tutti target classici di path traversal.

#### Metodi HTTP non validi

Nikto ha testato metodi HTTP non standard per identificare configurazioni errate:```
[client 10.0.2.5] AH00135: Invalid method in request DIWHWPJH / HTTP/1.1
[client 10.0.2.5] AH00135: Invalid method in request DEBUG / HTTP/1.1
[client 10.0.2.5] AH00135: Invalid method in request TRACK / HTTP/1.0
[client 10.0.2.5] AH00135: Invalid method in request SEARCH / HTTP/1.1
[client 10.0.2.5] AH00135: Invalid method in request INDEX / HTTP/1.1

Tentativi di Accesso a File Protetti

Entrambi gli strumenti hanno tentato di accedere a file di configurazione protetti da Apache:``` [client 10.0.2.5] AH01630: client denied by server configuration: /var/www/html/.htpasswd [client 10.0.2.5] AH01630: client denied by server configuration: /var/www/html/.htaccess [client 10.0.2.5] AH01630: client denied by server configuration: /var/www/html/server-status [client 10.0.2.5] AH01630: client denied by server configuration: /var/www/html/admin/.htpasswd [client 10.0.2.5] AH01630: client denied by server configuration: /var/www/html/login/.htpasswd

#### Path Traversal Specifico per VMware

Nikto ha anche testato l'esposizione dell'infrastruttura VMware:```
[client 10.0.2.5] AH10244: invalid URI path (/sdk/%2E%2E/%2E%2E/%2E%2E/%2E%2E/%2E%2E/%2E%2E/etc/vmware/hostd/vmInventory.xml)

Analisi

I log di accesso e di errore hanno rivelato un pattern di attacco automatizzato in due fasi, originato da un singolo indirizzo IP (10.0.2.5) diretto al server Apache sulla porta 80.

Fase 1 — Scansione delle vulnerabilità (Nikto, 21:14–21:18)

Nikto ha effettuato 8.102 richieste in 17 secondi, testando vulnerabilità web note, header di sicurezza mancanti, metodi HTTP pericolosi e vettori di path traversal. Il log degli errori ha registrato molteplici tentativi di accesso a /etc/passwd, /etc/shadow, boot.ini e al database SAM di Windows, tutti bloccati dalla convalida URI di Apache. Nikto ha anche tentato una richiesta PUT per creare un file di test sul server, confermando che stava verificando i permessi di scrittura.

Fase 2 — Enumerazione delle directory (Dirb, 21:19–21:21)

Dirb ha testato 4.612 parole dalla sua wordlist comune contro la directory root e ogni sottodirectory scoperta. Ciò ha generato la maggior parte dei 21.740 errori 404 osservati. Dirb ha identificato con successo /admin/, /backup/ e /login/ come directory valide. La directory /backup/ è stata trovata con il listing abilitato — una configurazione errata significativa che permetterebbe a un attaccante di navigarne il contenuto direttamente.

Valutazione combinata

La concentrazione di 21.962 richieste HTTP da un singolo IP sorgente in circa 7 minuti, combinata con la presenza di tentativi di path traversal, richieste con metodi HTTP non validi e firme specifiche di tool nei log di accesso e di errore, costituisce una chiara evidenza di attività di riconoscimento web automatizzato.

Non è stata osservata alcuna exploitazione riuscita. Tutti i tentativi di path traversal sono stati respinti dal meccanismo di convalida URI di Apache. L'accesso a file protetti (.htpasswd, .htaccess, server-status) è stato negato dalla configurazione del server.

Indicatori principali

Raccomandazioni difensive

Sulla base dei risultati, si raccomandano i seguenti controlli:

• Aggiungere header di sicurezza nella configurazione di Apache: X-Frame-Options, X-Content-Type-Options, Content-Security-Policy
• Disabilitare gli header ETag per evitare la fuga di informazioni sugli inode
• Limitare i metodi HTTP consentiti a GET, POST e HEAD soltanto
• Disabilitare il listing delle directory in tutte le directory, specialmente /backup/
• Limitare l'accesso a /server-status solo a localhost
• Implementare il rate limiting per bloccare IP che generano richieste eccessive al secondo
• Implementare un WAF (Web Application Firewall) per rilevare e bloccare pattern di path traversal
• Monitorare continuamente error.log per eventi AH10244 (URI path non valido)
• Rimuovere o limitare l'accesso pubblico a directory sensibili (/admin/, /backup/)
• Nascondere la versione di Apache negli header di risposta HTTP (ServerTokens Prod, ServerSignature Off)

Conclusione

Questo laboratorio ha dimostrato come tool di scansione web automatizzata lascino pattern distinti e identificabili nei log di accesso e di errore di Apache. Correlando il volume di errori 404, la presenza di tentativi di path traversal in error.log, richieste con metodi HTTP non validi e firme specifiche di tool nei path delle richieste e nelle stringhe user-agent, è stato possibile ricostruire l'intera timeline dell'attacco e identificare i tool utilizzati — senza alcuna conoscenza preventiva delle azioni dell'attaccante.

L'esercizio rafforza l'importanza del monitoraggio dei log dei server web, della configurazione degli header di sicurezza e dei controlli di accesso alle directory come pratiche fondamentali di Blue Team per l'infrastruttura esposta al web.

Tool utilizzati

• Kali Linux
• Debian 13
• Apache 2.4.67
• Nikto v2.5.0
• Dirb v2.22
• grep, wc, cat