Ασφάλεια Web Servers και Reverse Proxies — DedSec Project

Ένας web server δεν είναι μόνο η εφαρμογή που επιστρέφει HTML. Η πραγματική επιφάνεια περιλαμβάνει TLS termination, reverse proxies, virtual hosts, static files, upload paths, modules/plugins, management endpoints, filesystem permissions, logs και upstream εφαρμογές. Η αξιολόγηση πρέπει να εξετάζει ολόκληρη αυτή την αλυσίδα.

Όριο εξουσιοδότησης: Έλεγχε μόνο hosts που ανήκουν στο scope. Μην εκτελείς active probing ή vulnerability validation σε δημόσιους servers τρίτων χωρίς άδεια.

Μαθησιακοί στόχοι

• Να χαρτογραφείς web server/reverse-proxy αρχιτεκτονική.
• Να αξιολογείς TLS, headers, virtual hosts και management exposure.
• Να εντοπίζεις unsafe default content, directory exposure και permission issues.
• Να κατανοείς proxy trust και forwarded headers.
• Να συνδέεις configuration findings με logs και remediation.

Αρχιτεκτονική και trust boundaries

Σχεδίασε τη διαδρομή client → CDN/WAF → reverse proxy → application → data service. Σημείωσε πού τερματίζει το TLS, πού γίνεται authentication, ποιος γράφει X-Forwarded-*/Forwarded, ποιο component θεωρείται trusted και ποια network path επιτρέπεται προς management interfaces.

TLS και HTTP configuration

Έλεγξε certificate lifecycle, hostname coverage, redirect από HTTP σε HTTPS, σύγχρονα protocol/cipher settings και HSTS όπου ταιριάζει. Security headers όπως CSP, frame protections και content-type controls πρέπει να σχεδιάζονται ανά εφαρμογή και όχι να αντιγράφονται τυφλά.

Virtual hosts και default sites

Default pages, test applications, παλιά virtual hosts και προσωρινά admin endpoints συχνά μένουν ξεχασμένα. Κάθε hostname πρέπει να έχει owner, business purpose και expected backend. Unknown Host values δεν πρέπει να δρομολογούνται αυθαίρετα σε ευαίσθητο site.

Filesystem και static content

Εξέτασε document roots, directory listing, backups, temporary files, source maps, configuration artifacts και upload directories. Η web process πρέπει να έχει μόνο τις permissions που απαιτούνται. Secrets δεν πρέπει να βρίσκονται σε static paths ή repository artifacts.

Reverse-proxy trust

Headers που υποτίθεται ότι δείχνουν πραγματικό client IP, scheme ή host είναι ασφαλή μόνο όταν ο proxy αφαιρεί μη έμπιστα values και η εφαρμογή εμπιστεύεται αποκλειστικά γνωστούς proxies. Διαφορετική canonicalization ανά layer μπορεί να δημιουργήσει routing ή access-control προβλήματα.

Management και observability

Admin panels, status pages, metrics και debugging endpoints πρέπει να είναι περιορισμένα. Τα logs πρέπει να καταγράφουν αρκετό context για troubleshooting/incident response χωρίς passwords, session tokens ή άλλα secrets.

Καθοδηγούμενο εργαστήριο

Στήσε έναν local web server ή reverse proxy. Κατέγραψε listening ports, document root, enabled modules, TLS state, default site, headers και logs. Δημιούργησε ένα harmless test file και επιβεβαίωσε ποιος μπορεί να το διαβάσει. Έλεγξε ότι management endpoint δεν είναι διαθέσιμο από μη έμπιστο test network.

Συνηθισμένα λάθη

• Ξεχασμένα default/test sites.
• Admin interfaces στο ίδιο trust zone με public clients.
• Blind trust σε forwarded headers.
• Secrets ή backups μέσα στο document root.
• Υπερβολικές filesystem permissions.
• Logs που αποθηκεύουν credentials/tokens.

Έλεγχος γνώσεων

1. Γιατί το reverse proxy είναι trust boundary;
2. Ποιος πρέπει να γράφει trusted forwarded headers;
3. Γιατί default virtual hosts αυξάνουν attack surface;
4. Ποια δεδομένα δεν πρέπει να γράφονται σε access logs;
5. Τι σημαίνει least privilege για τη web process;

Καθοδηγούμενη μελέτη

Χρησιμοποίησε τη Μεθοδολογία Μελέτης. Ξεκίνα από αρχιτεκτονικό διάγραμμα και απόδειξε κάθε finding με το ελάχιστο μη καταστροφικό evidence.

Συνέχισε με

Προτεινόμενα επόμενα modules: 14, 22, 40, 52, 69, 126.