Logs & Βασικό Blue-Team Mindset: Διαβάζοντας τα Ίχνη μιας Επίθεσης

Πριν κυνηγήσεις επιτιθέμενους, πρέπει να μάθεις να διαβάζεις τα ίχνη που αφήνουν πίσω τους. Κάθε σύνδεση, κάθε αποτυχημένος κωδικός, κάθε νέος λογαριασμός καταγράφεται κάπου — στα logs. Σε αυτόν τον οδηγό για αρχάριους ανοίγουμε το /var/log/auth.log, φιλτράρουμε με grep και journalctl μέσα σε ένα απομονωμένο εργαστήριο (isolated lab), κι έτσι χτίζουμε το πιο θεμελιώδες εργαλείο κάθε αμυνόμενου: το blue-team mindset — τη συνήθεια να σκέφτεσαι «τι θα φαινόταν αυτό στα logs;».

1. Εισαγωγή: γιατί τα logs είναι η καρδιά της άμυνας

Στην ασφάλεια υπολογιστών μιλάμε συχνά για δύο ομάδες: την κόκκινη ομάδα (red team) που προσομοιώνει επιθέσεις και την μπλε ομάδα (blue team) που ανιχνεύει και αμύνεται. Οι αρχάριοι εντυπωσιάζονται με το επιθετικό κομμάτι — τα exploits, τα shells, τα «σπασίματα». Όμως η αλήθεια είναι ότι το 90% της πραγματικής δουλειάς σε ένα SOC (Security Operations Center) είναι να διαβάζεις logs και να αναγνωρίζεις τι είναι φυσιολογικό και τι όχι.

Γιατί; Επειδή ένας επιτιθέμενος, όσο προσεκτικός κι αν είναι, αφήνει ίχνη. Μια απόπειρα brute-force αφήνει δεκάδες αποτυχημένες συνδέσεις. Μια κλιμάκωση προνομίων (privilege escalation) αφήνει μια εγγραφή sudo ή έναν νέο λογαριασμό. Ένας έξυπνος αντίπαλος που καθαρίζει τα logs αφήνει… το ίδιο το γεγονός του καθαρισμού. Το blue-team mindset είναι ακριβώς αυτό: να ξέρεις πού να κοιτάξεις και τι σημαίνει αυτό που βλέπεις.

Θα δουλέψουμε αποκλειστικά μέσα σε ένα απομονωμένο εργαστήριο, με ουδέτερες διευθύνσεις IP (10.10.10.x). Δεν επιτιθέμεθα σε τίποτα — απλώς διαβάζουμε τα ίχνη μιας επίθεσης που έχει ήδη προσομοιωθεί μέσα στο lab.

2. Βασικές έννοιες

2.1 Τι είναι ένα log και πού ζει στο Linux

Ένα log είναι απλώς ένα αρχείο κειμένου όπου το σύστημα και οι υπηρεσίες γράφουν, γραμμή-γραμμή, τι συνέβη και πότε. Στα κλασικά συστήματα Linux τα περισσότερα ζουν στον φάκελο /var/log/:

• /var/log/auth.log — ό,τι αφορά ταυτοποίηση (authentication): συνδέσεις SSH, χρήση sudo, αλλαγές κωδικών. Το πιο σημαντικό αρχείο για έναν αρχάριο defender.
• /var/log/syslog — γενικά μηνύματα συστήματος και υπηρεσιών.
• /var/log/kern.log — μηνύματα του πυρήνα (kernel).

Κάθε γραμμή έχει συνήθως την ίδια δομή: χρονοσφραγίδα (timestamp), το όνομα του μηχανήματος (hostname), η υπηρεσία που έγραψε (π.χ. sshd) και το μήνυμα. Αυτή η σταθερή δομή είναι που μας επιτρέπει να φιλτράρουμε αυτόματα.

2.2 journald — το σύγχρονο, δομημένο log

Τα σύγχρονα συστήματα με systemd κρατούν επιπλέον ένα δομημένο, δυαδικό ημερολόγιο μέσω της υπηρεσίας journald. Δεν το διαβάζεις με απλό cat· χρησιμοποιείς την εντολή journalctl, που σου δίνει ισχυρά φίλτρα: ανά υπηρεσία (-u ssh), ανά χρόνο (--since), ανά επίπεδο σοβαρότητας (-p). Οι δύο κόσμοι (κείμενο σε /var/log και journald) συχνά συνυπάρχουν.

2.3 Το ισοδύναμο στα Windows: Event Viewer

Στον κόσμο των Windows δεν υπάρχει auth.log· υπάρχει ο Event Viewer και ειδικά το Security log. Εκεί κάθε γεγονός δεν έχει ελεύθερο κείμενο αλλά έναν αριθμητικό Event ID. Ένας αρχάριος blue-teamer πρέπει να ξέρει απ’ έξω μια χούφτα από αυτούς — π.χ. 4625 = αποτυχημένη σύνδεση, 4624 = επιτυχημένη, 4720 = δημιουργία νέου λογαριασμού, 1102 = καθαρισμός του Security log (σχεδόν πάντα ύποπτο).

3. Πρακτικό κομμάτι: διαβάζοντας τα ίχνη στο lab

3.1 Πρώτη ματιά στο auth.log — tail

Ξεκινάμε με το πιο απλό: κοιτάμε τις τελευταίες γραμμές του auth.log με tail. Στο lab μας, ένα δεύτερο μηχάνημα (10.10.10.5) μόλις προσπάθησε να μπει με SSH.

Δύο πράγματα ξεχωρίζουν αμέσως. Πρώτον, μια σειρά από Failed password για root και για invalid users (admin, test) — κλασικό μοτίβο brute-force από την 10.10.10.5. Δεύτερον, λίγο αργότερα, ένα Accepted password for devops από άλλη IP (10.10.10.9) που ακολουθείται από sudo ... USER=root. Το πρώτο είναι θόρυβος επίθεσης· το δεύτερο είναι φυσιολογική δραστηριότητα διαχειριστή. Το blue-team mindset είναι να ξεχωρίζεις τα δύο.

3.2 Από τον θόρυβο στο μοτίβο — grep, awk, sort, uniq

Ένα-δύο failed logins είναι φυσιολογικά (όλοι κάνουμε λάθος τον κωδικό). Σαράντα σε ένα λεπτό, από την ίδια IP, για ονόματα που δεν υπάρχουν — αυτό είναι επίθεση. Ας το μετρήσουμε αντί να το μαντεύουμε.

Η πρώτη εντολή μετράει πόσες αποτυχημένες συνδέσεις υπάρχουν συνολικά (47). Η δεύτερη είναι το «ψωμοτύρι» του analyst: το awk απομονώνει το πεδίο της IP, το sort | uniq -c | sort -rn τις ομαδοποιεί και τις κατατάσσει. Αποτέλεσμα: η 10.10.10.5 με 41 απόπειρες ξεχωρίζει ολοφάνερα. Η τρίτη εντολή δείχνει ποια ονόματα χρηστών δοκίμασε ο επιτιθέμενος (admin, test, oracle) — τυπικό λεξικό (wordlist) brute-force. Με τρεις γραμμές περάσαμε από «κάτι συμβαίνει» σε «ξέρω ποιος, από πού και τι δοκίμασε».

3.3 Το ίδιο, δομημένα — journalctl

Το journalctl μας δίνει τα ίδια δεδομένα αλλά με φίλτρα ανά υπηρεσία και χρόνο, χωρίς να ξέρουμε το ακριβές μονοπάτι του αρχείου.

Με journalctl -u ssh --since ... --until ... περιορίζουμε το παράθυρο στα δύο κρίσιμα λεπτά. Με -g 'Accepted' (grep pattern) βλέπουμε μόνο τις επιτυχημένες συνδέσεις — και προσέχουμε ότι η νόμιμη σύνδεση χρησιμοποίησε publickey νωρίτερα, ενώ η IP της επίθεσης δεν πέτυχε ποτέ. Τέλος, το -p warning φιλτράρει ανά επίπεδο σοβαρότητας. Η δύναμη εδώ είναι η συσχέτιση: ίδιο συμβάν, διαφορετική οπτική.

3.4 Ο κόσμος των Windows — Event IDs

Επειδή στην πράξη θα αμύνεσαι και συστήματα Windows, κρατάμε στο lab ένα σύντομο «cheat sheet» με τους πιο κρίσιμους Event IDs του Security log. Αυτή είναι η αντιστοιχία της ίδιας λογικής στο περιβάλλον του Event Viewer.

Η ίδια νοοτροπία μεταφέρεται αυτούσια: το 4625 είναι το ισοδύναμο του Failed password (brute-force), το 4720 προειδοποιεί για νέο λογαριασμό (persistence), και το 1102 — καθαρισμός του Security log — είναι σχεδόν πάντα ένδειξη ότι κάποιος προσπαθεί να καλύψει τα ίχνη του (anti-forensics). Στα Windows φιλτράρεις γραφικά μέσα στον Event Viewer ή από τη γραμμή εντολών με wevtutil.

4. Το εργαστηριακό περιβάλλον (isolated lab)

Όλα τα παραπάνω αφορούν ανάγνωση, όχι επίθεση — αλλά για να έχεις ρεαλιστικά logs, χρειάζεσαι ένα ελεγχόμενο περιβάλλον όπου προσομοιώνεις την επίθεση και μετά μελετάς τα ίχνη. Ένα ασφαλές beginner setup:

• Ένας hypervisor (VirtualBox ή VMware) με δίκτυο σε Host-Only ή Internal Network — ποτέ Bridged.
• Μία μηχανή «στόχος» (π.χ. ένας Ubuntu server με SSH) και μία μηχανή «επιτιθέμενος» (Kali Linux) στο ίδιο υποδίκτυο 10.10.10.0/24.
• Προαιρετικά ένα μικρό εργαλείο brute-force (π.χ. hydra) μόνο εναντίον της δικής σου VM, για να γεμίσει το auth.log με ρεαλιστικά ίχνη που μετά θα αναλύσεις.
• Snapshots πριν από κάθε πείραμα, για άμεση επαναφορά καθαρής κατάστασης.

Ο στόχος του lab δεν είναι να «νικήσεις» τον στόχο, αλλά να δεις πώς μοιάζει η επίθεση από τη μεριά του αμυνόμενου. Αυτή η αλλαγή οπτικής είναι το ουσιαστικό μάθημα.

5. Ηθικό & νομικό πλαίσιο

Η ανάγνωση logs σε συστήματα που σου ανήκουν ή διαχειρίζεσαι νόμιμα είναι απολύτως θεμιτή — είναι, στην ουσία, η δουλειά κάθε διαχειριστή και analyst. Δύο σημεία προσοχής όμως:

• Τα logs περιέχουν προσωπικά δεδομένα (ονόματα χρηστών, διευθύνσεις IP, ώρες πρόσβασης). Σε εταιρικό περιβάλλον η πρόσβαση και διατήρησή τους διέπεται από τον GDPR και εσωτερικές πολιτικές — δεν τα «κατεβάζεις» ή μοιράζεσαι ελεύθερα.
• Η προσομοίωση επίθεσης (π.χ. brute-force με hydra) γίνεται μόνο σε μηχανές που έστησες εσύ ή σε νόμιμες πλατφόρμες (Hack The Box, TryHackMe, VulnHub). Το ίδιο εργαλείο σε ξένο σύστημα, χωρίς ρητή γραπτή εξουσιοδότηση, είναι παράνομο στην Ελλάδα και την ΕΕ (ενδεικτικά Ν. 4411/2016 για το έγκλημα στον κυβερνοχώρο).
• Το authorized penetration testing και το threat hunting γίνονται πάντα με σαφώς οριοθετημένο εύρος (scope) και συμφωνία.

6. Βασικά συμπεράσματα

• Το blue-team mindset ξεκινά με μία ερώτηση: «τι θα φαινόταν αυτή η ενέργεια στα logs;» — η ανίχνευση είναι το αντίστροφο κάθε επίθεσης.
• Στο Linux, το /var/log/auth.log είναι η πρώτη σου στάση για ταυτοποίηση: αποτυχημένες/επιτυχημένες συνδέσεις SSH και χρήση sudo.
• Με grep + awk + sort + uniq -c περνάς από τον θόρυβο στο μοτίβο: ποια IP, πόσες απόπειρες, ποια ονόματα χρηστών.
• Το journalctl δίνει τα ίδια δεδομένα δομημένα, με φίλτρα ανά υπηρεσία (-u), χρόνο (--since) και σοβαρότητα (-p).
• Στα Windows η ίδια λογική ζει στον Event Viewer μέσω Event IDs (4625, 4720, 1102) — άλλη μορφή, ίδια νοοτροπία.
• Όλη η εξάσκηση γίνεται μόνο σε εξουσιοδοτημένο, απομονωμένο περιβάλλον, με σεβασμό στα προσωπικά δεδομένα που περιέχουν τα logs.

Από τη θεωρία στην πράξη. Η Audax Cybersecurity προσφέρει επαγγελματικές υπηρεσίες offensive security — penetration testing & offensive validation — ενώ για όσους ξεκινούν το ταξίδι τους στο ethical hacking, το #1 ελληνικό βιβλίο «Ethical Hacking — Η Κρυφή Γνώση» είναι ο ιδανικός οδηγός.