Αυτός είναι ο οδηγός εγκατάστασης, ρύθμισης και συντήρησης του Arcivéo Security Monitor. Οι ενότητες είναι ομαδοποιημένες: γενική επισκόπηση, ανάπτυξη του πίνακα, σύνδεση εργαλείων ασφαλείας, ενσωματωμένες μονάδες και διαγνωστικά. Οι εντολές αντιγράφονται με το κουμπί δεξιά.
Η εγκατάσταση του πίνακα βρίσκεται σε ξεχωριστές σελίδες βήμα προς βήμα. Επιλέξτε μέθοδο:
Arcivéo Security Monitor — πίνακας ασφαλείας διακομιστή. Συλλέγει δεδομένα από τα εγκατεστημένα εργαλεία (Fail2ban, UFW, Lynis, ModSecurity, AIDE, ClamAV, Auditd, CrowdSec, Suricata, Falco κ.ά.) και τα εμφανίζει σε ενιαία διεπαφή με dashboard, χάρτη επιθέσεων και αναλυτικές σελίδες για κάθε εργαλείο.
Το Monitor δεν είναι ενεργό μέσο προστασίας — δεν μπλοκάρει επιθέσεις από μόνο του. Ο σκοπός του είναι να συγκεντρώνει τις πληροφορίες από τα ήδη ενεργά εργαλεία και να τις παρουσιάζει με βολικό τρόπο.
Ο monitor λειτουργεί μόνο τοπικά — πρέπει να εγκατασταθεί στον ίδιο διακομιστή που παρακολουθεί. Δεν χρησιμοποιεί SSH ούτε απομακρυσμένο API.
Όλες τις εντολές (fail2ban-client, ufw status, ipset list κ.λπ.) το dashboard τις εκτελεί ως χρήστης του web server (συνήθως www-data, στα hosting panel — ο λογαριασμός του site) με περιορισμένο σύνολο δικαιωμάτων sudo — μόνο σε συγκεκριμένα εργαλεία, χωρίς γενική πρόσβαση root. Τα αποτελέσματα αναλύονται και εμφανίζονται στον browser.
Δύο ρυθμοί λειτουργίας. Οι σελίδες του πίνακα ρωτούν τα εργαλεία τη στιγμή που τις ανοίγετε — βλέπετε πάντα την τρέχουσα κατάσταση. Επιπλέον, στο παρασκήνιο τρέχουν εργασίες βάσει προγράμματος (cron):
Ο πλήρης κατάλογος των εργασιών βρίσκεται στην ενότητα «Όλες οι εργασίες cron σε ένα μέρος».
Η βαθμολογία ξεκινά από το μέγιστο και μειώνεται για κάθε πρόβλημα που εντοπίζεται:
PermitRootLogin yes) — −20PasswordAuthentication yes) — −10X11Forwarding, MaxAuthTries πάνω από 3 ή sshd_config αναγνώσιμο από όλους τους λογαριασμούς — −5TRACE είναι ενεργή ή λείπει η κεφαλίδα Strict-Transport-Security ή X-Frame-Options — −5Σύνολο: 80+ = Προστατευμένος, 60–79 = Προσοχή, <60 = Σε κίνδυνο.
WebAuthn — πρότυπο ελέγχου ταυτότητας χωρίς κωδικό μέσω κλειδιού υλικού. Υποστηρίζει YubiKey, Touch ID, Face ID, Windows Hello, Passkey.
Μετά την είσοδο με κωδικό, το σύστημα ζητά επιβεβαίωση μέσω του καταχωρημένου κλειδιού. Ακόμη κι αν διαρρεύσει ο κωδικός, η είσοδος είναι αδύνατη χωρίς το φυσικό κλειδί ή τη βιομετρία.
Για ρύθμιση, ανοίξτε τα Κλειδιά WebAuthn στο πλαϊνό μενού και πατήστε «Καταχώριση κλειδιού». Καταχωρίστε αμέσως δύο κλειδιά: αν το μοναδικό κλειδί χαθεί ή χαλάσει, η είσοδος στον πίνακα με αυτό θα είναι αδύνατη.
Τα κανάλια είναι τέσσερα: Telegram, Email, webhook και push στο πρόγραμμα περιήγησης. Είναι ανεξάρτητα μεταξύ τους — ενεργοποιήστε όποια θέλετε, ακόμη και τα τέσσερα. Από τα ίδια κανάλια περνούν η ημερήσια αναφορά ασφάλειας, οι ειδοποιήσεις φορτίου και τα ευρήματα του αισθητήρα συμβάντων· ρυθμίζονται μία φορά, εδώ, στην ενότητα «Ρυθμίσεις».
Telegram. Χρειάζονται το token του bot και το chat id:
@BotFather → /newbot → λάβετε το token της μορφής 123456:ABC....@userinfobot, ή ανοίξτε το https://api.telegram.org/bot<TOKEN>/getUpdates και βρείτε το "chat":{"id":...}.Email. Δύο τρόποι επιλογής στις «Ρυθμίσεις» → Email:
re_...) και επιβεβαιωμένο domain αποστολέα.Webhook. Μία μόνο διεύθυνση που δέχεται POST καλύπτει Slack, Discord, Mattermost, n8n και δικό σας χειριστή. «Ρυθμίσεις» → Webhook: επικολλήστε τη διεύθυνση και ενεργοποιήστε τον διακόπτη.
{"text": …}, στο Discord {"content": …} (το Discord απορρίπτει μηνύματα άνω των 2000 χαρακτήρων, οπότε το κείμενο περικόπτεται)·text, event, severity, source, count, host, ts — δεν χρειάζεται να αναλυθεί ξανά το κείμενο του μηνύματος.Ειδοποιήσεις push. Το μήνυμα φτάνει απευθείας στο πρόγραμμα περιήγησης και, αν ο πίνακας έχει προστεθεί στην αρχική οθόνη του τηλεφώνου, ως συνηθισμένη ειδοποίηση εφαρμογής — χωρίς bot και χωρίς διακομιστή αλληλογραφίας ενδιάμεσα. «Ρυθμίσεις» → Ειδοποιήσεις push: ενεργοποιήστε τον διακόπτη και πατήστε «Σύνδεση αυτής της συσκευής» σε κάθε συσκευή που πρέπει να λαμβάνει ειδοποιήσεις. Ο μετρητής «Συνδεδεμένες συσκευές» δείχνει πόσες είναι.
Κατάσταση αναφοράς: «ΠΡΟΣΟΧΗ» ή «ΟΚ». Ο τίτλος γίνεται «ΠΡΟΣΟΧΗ» μόνο σε πραγματικό πρόβλημα ή εκκρεμή ενέργεια: εντοπίστηκε απειλή ClamAV, αλλαγές αρχείων στο AIDE, κρίσιμα συμβάντα Falco (Emergency/Alert/Critical τις τελευταίες 24 ώρες), σταματημένη υπηρεσία στο Monit, απαιτείται επανεκκίνηση, λήγει SSL (≤14 ημέρες) ή εκκρεμούν ενημερώσεις ασφαλείας. Ο θόρυβος παρασκηνίου — δοκιμές SSH από bots, IP που έχουν μπλοκαριστεί από fail2ban, ειδοποιήσεις Suricata, προειδοποιήσεις Lynis και ήδη αποκρουσμένα αιτήματα ModSecurity — δεν ανεβάζει την κατάσταση, οπότε τέτοιοι αριθμοί στην αναφορά δεν σημαίνουν «ΠΡΟΣΟΧΗ» από μόνοι τους.
Οι αναλυτικές μονάδες παρακολούθησης (Lynis, UFW, ModSecurity, χάρτης επιθέσεων, AIDE, ClamAV κ.ά.) ξεκλειδώνουν εφόσον υπάρχει έγκυρη άδεια χρήσης. Χωρίς αυτήν, το dashboard, οι ρυθμίσεις και ο λογαριασμός λειτουργούν, ενώ οι μονάδες εμφανίζουν την κάρτα «Απαιτείται άδεια χρήσης».
Μετά την αγορά, στον λογαριασμό σας έχετε έναν κωδικό ενεργοποίησης της μορφής ARCIVEO-XXXX-XXXX-XXXX-XXXX. Πρέπει να τον «ενεργοποιήσετε» στον τομέα του panel σας — αυτό μετατρέπει τον κωδικό σε υπογεγραμμένο αρχείο άδειας (μπλοκ [license]), που εισάγετε στο panel.
Πώς γίνεται η ενεργοποίηση (3 βήματα):
my.arciveo.com → ενότητα «Άδειες» / «Ενεργοποίηση άδειας» — αντιγράψτε τον κωδικό ARCIVEO-….monitor.example.com). Πατήστε ενεργοποίηση — το σύστημα δημιουργεί αρχείο άδειας συνδεδεμένο με αυτόν τον τομέα και το εμφανίζει σε πεδίο με κουμπί «Αντιγραφή».Το panel ελέγχει το κλειδί κρυπτογραφικά: υπογραφή, σύνδεση με τον τομέα και διάρκεια ισχύος.
APP_URL στο config.php και εισαγάγετε μόνο το όνομα του host — χωρίς https:// και χωρίς πρόθεμα www. Η ενεργοποίηση είναι μία φορά: ο κωδικός μετατρέπεται σε άδεια για τον τομέα που δώσατε και δεν ενεργοποιείται ξανά — σε λάθος τομέα το κλειδί δεν θα ταιριάζει στο panel σας και ο κωδικός θα έχει αναλωθεί. Γι' αυτό εισαγάγετε τον τομέα προσεκτικά.
Όλες οι βασικές παράμετροι του πίνακα ορίζονται σε ένα αρχείο config.php στη ρίζα (δίπλα στον φάκελο public/) με απλές σταθερές define(). Το αρχείο δημιουργείται κατά την εγκατάσταση· χρειάζεται σπάνια χειροκίνητη επεξεργασία — κυρίως όταν αλλάζετε domain, κατά τη μεταφορά ή τη σύνδεση σε άλλη βάση. Μετά από κάθε αλλαγή επανεκκινήστε το PHP-FPM (αλλιώς, λόγω του OPcache, οι αλλαγές δεν θα εφαρμοστούν).
Συμπληρώστε τις δικές σας τιμές στα επισημασμένα σημεία· τα υπόλοιπα αφήστε τα ως έχουν:
Βάση δεδομένων. Στοιχεία σύνδεσης στη MySQL/MariaDB:
DB_HOST — ο host της βάσης, σχεδόν πάντα localhost·DB_NAME — το όνομα της βάσης δεδομένων του πίνακα·DB_USER — ο χρήστης της βάσης (πρόσβαση μόνο στη δική του βάση)·DB_PASS — ο κωδικός αυτού του χρήστη·DB_CHARSET — η κωδικοποίηση της σύνδεσης, αφήστε utf8mb4.Εφαρμογή.
APP_URL — η πλήρης διεύθυνση του πίνακα (π.χ. https://monitor.example.com). Πρέπει να συμπίπτει με το domain για το οποίο ενεργοποιήθηκε η άδεια — αλλιώς το κλειδί θα απορριφθεί (δείτε την ενότητα «Άδεια»)·TIMEZONE — η ζώνη ώρας του PHP: επηρεάζει μόνο τον τρόπο που ο πίνακας εμφανίζει ημερομηνίες και ώρα. Στην ώρα εκτέλεσης των εργασιών cron δεν επηρεάζει — εκεί ισχύει η ζώνη του συστήματος (δείτε «Όλες οι εργασίες cron»).Διάρκεια συνεδρίας. SESSION_LIFETIME — το χρονικό όριο αδράνειας της συνεδρίας σε δευτερόλεπτα (κυλιόμενο: ανανεώνεται με τη δραστηριότητα). Προεπιλογή 28800 = 8 ώρες· μετά από αυτό το διάστημα αδράνειας ο πίνακας θα ζητήσει νέα σύνδεση. Για παράδειγμα, 3600 = 1 ώρα, 86400 = μία ημέρα.
Καταγραφή σφαλμάτων. Τα σφάλματα δεν εμφανίζονται ποτέ στους επισκέπτες, αλλά γράφονται στο logs/php_errors.log — φαίνονται στη σελίδα «Αρχεία καταγραφής εφαρμογής». Αυτές οι γραμμές (display_errors=0, log_errors=1, η διαδρομή error_log) συνήθως δεν χρειάζονται αλλαγή — οι ρυθμίσεις ορίζονται απευθείας στο αρχείο και δεν εξαρτώνται από το php.ini.
public/), ενώ η ρίζα ιστού (DocumentRoot) αυτού του πίνακα είναι ακριβώς η ρίζα του πίνακα, όχι το public/. Το ίδιο το αρχείο δεν «διαρρέει»: στο ριζικό .htaccess υπάρχει ρητή απαγόρευση γι' αυτό (Require all denied) — ο διακομιστής επιστρέφει 403. Ακόμη και χωρίς αυτόν τον κανόνα ο πηγαίος κώδικας δεν θα διέρρεε: είναι PHP — ο διακομιστής το εκτελεί, δεν το παραδίδει ως κείμενο. Για κάθε ενδεχόμενο: μην το ανεβάζετε σε δημόσια αποθετήρια και μην το στέλνετε στην υποστήριξη με πραγματικό κωδικό. Δικαιώματα στο αρχείο — 640.
Ο πίνακας προστατεύεται από τη σύνδεση με κωδικό και, αν είναι ενεργό, από το φίλτρο IP. Σε ένα πρόγραμμα δεν ταιριάζει τίποτα από τα δύο, γι’ αυτό τα εξωτερικά συστήματα έχουν δική τους είσοδο — δύο διευθύνσεις μόνο για ανάγνωση, προστατευμένες με διακριτικό. Το διακριτικό δεν αλλάζει τίποτα στον διακομιστή: με αυτό μπορούν μόνο να ληφθούν δείκτες.
Ενεργοποίηση — «Ρυθμίσεις» → «API μόνο για ανάγνωση»: ο διακόπτης «Ενεργοποίηση του API»· το διακριτικό δημιουργείται αυτόματα κατά την πρώτη αποθήκευση. Το κουμπί «Νέο διακριτικό» εκδίδει άλλο και την ίδια στιγμή αποκόπτει όλους όσοι χρησιμοποιούσαν το προηγούμενο.
/api/status.php — JSON: βαθμολογία ασφάλειας, κατάσταση των μονάδων, η τελευταία μέτρηση φορτίου με τις κορυφαίες διεργασίες και τα συμβάντα ασφάλειας των τελευταίων 24 ωρών·/api/metrics.php — οι ίδιοι αριθμοί στην κειμενική μορφή του Prometheus (μετρικές arciveo_*: arciveo_security_score, arciveo_fail2ban_banned, arciveo_cpu_busy_pct κ.ο.κ.).Αν ο πελάτης σας δεν μπορεί να θέσει κεφαλίδα, το διακριτικό γίνεται δεκτό και ως παράμετρος — ?token=…. Λάβετε υπόψη ότι σε αυτή τη μορφή καταλήγει στο αρχείο καταγραφής προσπελάσεων του διακομιστή web, οπότε η κεφαλίδα είναι προτιμότερη.
Prometheus. Έτοιμο μπλοκ για το scrape_configs:
api disabled — το API είναι απενεργοποιημένο στις ρυθμίσεις. Τα απορριφθέντα αιτήματα καταγράφονται στο αρχείο καταγραφής της εφαρμογής μαζί με την IP του αποστολέα, οπότε οι απόπειρες μαντέματος του διακριτικού φαίνονται στη σελίδα «Αρχεία καταγραφής εφαρμογής».
Ο πίνακας εγκαθίσταται σε κάθε διακομιστή ξεχωριστά και απαντά καλά στο ερώτημα «πώς πάει αυτό το μηχάνημα». Στο ερώτημα «πώς πάνε όλα τα μηχανήματά μου» δεν απαντά — γι’ αυτό κάθε πίνακας μπορεί να στέλνει μια σύντομη επισκόπηση στον λογαριασμό, όπου οι διακομιστές φαίνονται σε έναν κατάλογο.
Τι να πάρετε στον λογαριασμό my.arciveo.com → ενότητα «Οι διακομιστές μου»: εκεί εκδίδεται ένα διακριτικό (της μορφής fk_…) και αναγράφεται η διεύθυνση παραλήπτη https://my.arciveo.com/api/fleet.php. Το διακριτικό είναι ένα ανά λογαριασμό — το ίδιο για όλους τους διακομιστές σας.
Τι να ρυθμίσετε στον πίνακα — «Ρυθμίσεις» → «Επισκόπηση διακομιστών»: διεύθυνση παραλήπτη, διακριτικό, όνομα διακομιστή (πώς θα εμφανίζεται στον κατάλογο· αν το αφήσετε κενό, λαμβάνεται το domain του πίνακα) και ο διακόπτης «Αποστολή της επισκόπησης». Το κουμπί «Αποστολή τώρα» ελέγχει τη σύνδεση αμέσως, χωρίς να περιμένει το πρόγραμμα.
Στη συνέχεια η επισκόπηση φεύγει μέσω cron, κάθε 15 λεπτά:
Τι ακριβώς στέλνεται: όνομα και domain του διακομιστή, λειτουργικό σύστημα, χρόνος λειτουργίας, έκδοση PHP· η βαθμολογία ασφάλειας· η κατάσταση των μονάδων (UFW, αριθμός jail του Fail2ban, αποκλεισμοί σήμερα, αν τρέχουν CrowdSec, Suricata και Falco, απειλές ClamAV, αλλαγές AIDE, δείκτης Lynis, εκκρεμείς ενημερώσεις, αν χρειάζεται επανεκκίνηση, ημέρες μέχρι τη λήξη του πιστοποιητικού, αριθμός επικίνδυνα ανοιχτών θυρών)· η τελευταία μέτρηση φορτίου (load, CPU, RAM, δίσκος, inodes)· οι μετρητές συμβάντων των τελευταίων 24 ωρών και το τελευταίο κρίσιμο συμβάν. Αρχεία καταγραφής, κωδικοί και περιεχόμενα αρχείων δεν υπάρχουν στην επισκόπηση.
sudo crontab -l) και τι απαντά το κουμπί «Αποστολή τώρα». Τα σφάλματα αποστολής γράφονται στο αρχείο καταγραφής της εφαρμογής με τη σήμανση FLEET — εκεί φαίνεται αν απορρίφθηκε το διακριτικό (HTTP 401) ή αν δεν πραγματοποιήθηκε καν η σύνδεση.
Το UFW (Uncomplicated Firewall) είναι ένα απλό περιβάλλον για το nftables/iptables. Κλείνει όλες τις εισερχόμενες θύρες εκτός από τις ρητά επιτρεπόμενες. Η σελίδα «Τείχος προστασίας UFW» εμφανίζει την κατάσταση και τους κανόνες.
ufw enable επιτρέψτε οπωσδήποτε το SSH (ufw allow OpenSSH), αλλιώς θα χάσετε την πρόσβαση στον διακομιστή.
deny δεν θεωρείται προσβάσιμη από έξω.
Skipping adding existing rule — δεν είναι σφάλμα. Έτσι το UFW αναφέρει ότι ο ίδιος ακριβώς κανόνας υπάρχει ήδη και δεν τον προσθέτει ξανά. Κατά την επανάληψη της αυτόματης ρύθμισης (είναι ιδεμποτεντική) αυτό είναι κανονικό μήνυμα — δεν χρειάζεται καμία ενέργεια.
Μπλοκάρει αυτόματα IP μετά από υπέρβαση του αριθμού αποτυχημένων προσπαθειών σύνδεσης. Αναλύει τα αρχεία καταγραφής των SSH, nginx, Apache και άλλων υπηρεσιών.
Η βασική εγκατάσταση βρίσκεται παραπάνω. Εδώ είναι η λειτουργική διαμόρφωση που δίνει δεκάδες ενεργά jail και χιλιάδες αποκλεισμούς: γενικές ρυθμίσεις, βασικά jail και αυτόματο μπαν κακόβουλων IP από τη λίστα ipsum.
Το αρχείο /etc/fail2ban/jail.local — γενικές ρυθμίσεις και τα σημαντικότερα jail:
ignoreip βάλτε οπωσδήποτε το δικό σας IP και τα έμπιστα δίκτυα, αλλιώς μπορεί να μπανάρετε τον εαυτό σας. Μετά τις αλλαγές: sudo fail2ban-client reload.
Αυτόματη φόρτωση της λίστας αποκλεισμού ipsum — στο cron του root (sudo crontab -e): το level 1 (100+ χιλιάδες IP) φορτώνεται στο σύνολο ipsum, που αποκόπτεται στο firewall (περισσότερα — στην ενότητα «Λίστα αποκλεισμού IPset»):
ipsum — αυτό ακριβώς διαβάζει ο πίνακας (κάρτα «IPset ipsum»). Επίπεδα: levels/1.txt — μέγιστη κάλυψη, levels/3.txt — πιο ακριβές (3+ πηγές).
Γιατί ο «Μόνιτορ ασφαλείας» χωρίζεται σε δύο ζώνες. Η προστασία λειτουργεί σε δύο επίπεδα, και ο πίνακας δεν τα ανακατεύει:
sshd, apache-*, nginx-* κ.λπ.) και κακόβουλοι υπότροποι (jail recidive — αυτοί που έχουν ήδη μπαναριστεί πολλές φορές). Είναι IP που πραγματικά σας επιτέθηκαν — βρίσκονται στον χάρτη επιθέσεων και στη «Χρονογραμμή».ipset ipsum, που αποκόπτεται στο firewall με κανόνα DROP. Οι περισσότερες από αυτές τις διευθύνσεις ούτε καν άγγιξαν τον διακομιστή σας — αποκόπτονται εκ των προτέρων· ο μετρητής «IPset ipsum» δείχνει πόσες αποκόπηκαν προληπτικά.Η διαφορά είναι απλή: αντιδραστικά — «αυτοί επιτέθηκαν και έφαγαν μπαν», προληπτικά — «αυτοί αποκλείστηκαν πριν καν την απόπειρα». Παλιότερα στο recidive φορτωνόταν τεχνητά η list-3 του ipsum (από εκεί ο παλιός διαχωρισμός «recidive λίστας»)· τώρα το recidive έχει μόνο πραγματικούς υπότροπους, ενώ το προληπτικό είναι εξ ολοκλήρου στο firewall.
ipsum — δημόσια λίστα κακόβουλων IP που ενημερώνεται καθημερινά. Η μονάδα εμφανίζει τον αριθμό των φορτωμένων διευθύνσεων στον πίνακα και στον χάρτη επιθέσεων και τον συνυπολογίζει στη Βαθμολογία ασφάλειας (−10 αν το σύνολο δεν έχει φορτωθεί).
Η ελάχιστη επιλογή χωρίς fail2ban — ξεχωριστό σύνολο ipsum με αποκλεισμό μέσω iptables:
@reboot. Παράλληλα η εντολή create … -exist ορίζει το όριο maxelem 300000 (η προεπιλογή 65536 — το level 1 δεν χωράει, θα βγει «Hash is full»):
ipsum και, αν το τείχος προστασίας το διαχειρίζεται ο εγκαταστάτης (νέο VPS — προφίλ «Πλήρες»/«Ελαφρύ»), συνδέει το σύνολο στο UFW με κανόνα DROP — η κίνηση από αυτές τις IP όντως αποκλείεται. Ο κανόνας βρίσκεται μετά το ESTABLISHED,RELATED, γι' αυτό οι τρέχουσες συνδέσεις (μαζί με το SSH σας) δεν διακόπτονται — κόβονται μόνο οι νέες συνδέσεις από τη λίστα. Το σύνολο αποκαθίσταται κατά τη φόρτωση της υπηρεσίας ipsum-load.service πριν το τείχος προστασίας (αλλιώς το UFW δεν θα σηκωνόταν) και ενημερώνεται με cron στις 04:00. Σε έναν ήδη διαμορφωμένο διακομιστή (πίνακας, δικό σας τείχος προστασίας) ο εγκαταστάτης δεν αγγίζει το τείχος προστασίας — εκεί το ipsum παραμένει λίστα για τον πίνακα και τον χάρτη επιθέσεων, ενώ ο κανόνας DROP προστίθεται χειροκίνητα αν το επιθυμείτε (η ελάχιστη επιλογή με iptables … --match-set ipsum … -j DROP — παραπάνω). Στην αυτόματη εγκατάσταση δεν χρειάζεται να κάνετε τίποτα χειροκίνητα.
Σύγχρονη αντικατάσταση του Fail2ban με συλλογικό threat intelligence: αποκλεισμοί από την κοινότητα συν δικοί σας κανόνες. Απαιτεί ξεχωριστό bouncer για την εφαρμογή των αποκλεισμών στο firewall.
systemctl is-active crowdsec). Εκκίνηση: sudo systemctl enable --now crowdsec· σε αποτυχία δείτε sudo journalctl -u crowdsec -n 30. Ο ίδιος κανόνας ισχύει για κάθε υπηρεσία σε κατάσταση «Δεν εκτελείται» (Suricata, Falco, Monit, MySQL).
stream halted / οι αποκλεισμοί δεν εφαρμόζονται. Πρόκειται για ορφανό api-key: το bouncer αφαιρέθηκε από το cscli bouncers list, αλλά το παλιό του κλειδί παρέμεινε στο /etc/crowdsec/bouncers/*.yaml. Καταχωρήστε ξανά το bouncer και ορίστε το νέο κλειδί:
AIDE (Advanced Intrusion Detection Environment) δημιουργεί στιγμιότυπο του συστήματος αρχείων και σε κάθε έλεγχο αναφέρει τις αλλαγές σε /etc, /bin, /usr. Μετά την εγκατάσταση είναι υποχρεωτική η αρχικοποίηση της βάσης (aideinit).
aideinit το τερματικό μένει 5–15 λεπτά στη γραμμή Running aide --init... — αυτό είναι φυσιολογικό (κατακερματισμός όλου του συστήματος αρχείων, φόρτος στον δίσκο). Μην το διακόπτετε με Ctrl+C. Αν η διεργασία «κολλάει» αλλά δεν γράφει τίποτα — ίσως περιμένει απάντηση σε ένα κρυφό ερώτημα Overwrite existing aide.db.new [Yn]? (πατήστε Y). Ελέγξτε τη δραστηριότητα από άλλη συνεδρία: pgrep -af aide.
aideinit: «21_aide_spamassassin … printf: invalid number» (return code 20) — γνωστό bug του config-snippet του AIDE στο Ubuntu 22.04. Η βάση δεν δημιουργείται. Αφαιρέστε το ελαττωματικό snippet και επαναλάβετε:
aideinit, είτε (Ubuntu 24.04) ο κατάλογος /var/lib/aide δημιουργήθηκε σε λειτουργία 700 και δεν είναι προσβάσιμος από τον www-data — διορθώνεται με sudo chmod 755 /var/lib/aide (δείτε το μπλοκ παραπάνω). «Δεν έγιναν έλεγχοι» = η βάση υπάρχει, αλλά δεν έχει εκτελεστεί ακόμη έλεγχος — δεν είναι σφάλμα. Τα αποτελέσματα το monitor τα διαβάζει από το /var/log/aide/aide.log.
/etc/cron.daily/aide στα νέα Ubuntu/Debian μπορεί να μη γράφει το /var/log/aide/aide.log στη σωστή μορφή (και το aide.wrapper δεν υπάρχει πλέον σε αυτά). Πιο αξιόπιστο είναι να προσθέσετε δικό σας cron με ρητό --config — γράφει το αρχείο ως root σε λειτουργία 644, και το monitor το διαβάζει χωρίς επιπλέον ομάδες:
chmod 755 /var/lib/aide και cron ελέγχου στις 02:00 — δεν χρειάζεται τίποτα χειροκίνητα.
sudo aideinit && sudo cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db.
Σαρωτής antivirus για Linux. Ιδιαίτερα χρήσιμος για έλεγχο του /var/www για PHP-shells και κακόβουλο κώδικα.
enable --now; Τρεις συνηθισμένες αιτίες:
1. Στο config έχει μείνει η γραμμή Example — ο clamd αρνείται να ξεκινήσει όσο υπάρχει:
2. Δεν έχει κατέβει η βάση υπογραφών — ο clamd δεν ξεκινά χωρίς αυτήν:
3. Απλώς φορτώνει — ο clamd φορτώνει ~8 εκατ. υπογραφές στη μνήμη σε 30–60 δευτ. Περιμένετε και ελέγξτε: systemctl is-active clamav-daemon (κατάσταση activating → φορτώνει ακόμη).
sudo journalctl -u clamav-daemon -n 30 --no-pager.
clamd απλώς κρατά τις υπογραφές στη μνήμη, ο ίδιος δεν σαρώνει τίποτα βάσει προγράμματος. Ο πίνακας δείχνει τα αποτελέσματα προγραμματισμένης σάρωσης, οπότε χρειάζεται ένα cron που σαρώνει και γράφει log. Η αυτόματη εγκατάσταση τοποθετεί το wrapper /usr/local/bin/clamav-scan.sh και cron στη 01:30 — μετά την πρώτη εκτέλεση θα συμπληρωθούν τα «Ελεγμένα αρχεία» και «Τελευταία σάρωση». Εκτελέστε το αμέσως, χωρίς να περιμένετε το πρόγραμμα: sudo /usr/local/bin/clamav-scan.sh.
Linux Malware Detect (LMD) — σαρωτής κακόβουλου λογισμικού για διαδικτυακές απειλές: PHP-shells, web backdoors, downloaders. Χρησιμοποιεί τη μηχανή του ClamAV και τη συμπληρώνει με τις δικές του υπογραφές.
maldet --report.
update-rc.d: error: unable to read /etc/init.d/maldet — είναι ακίνδυνη. Το maldet δεν χρησιμοποιεί init.d, η ενημέρωση υπογραφών και οι σαρώσεις εκτελούνται μέσω /etc/cron.daily/maldet. Αν παρακάτω βλέπετε installation completed — όλα εγκαταστάθηκαν.
apt, αλλά στο /usr/local/maldetect, και όταν είναι ενεργό το open_basedir η ύπαρξή του ελέγχεται μέσω shell — δείτε την ενότητα «Η σελίδα είναι κενή, ενώ υπάρχουν δεδομένα στον διακομιστή».
Δικτυακό σύστημα ανίχνευσης εισβολών: αναλύει την κίνηση σε επίπεδο πακέτων και γνωρίζει χιλιάδες υπογραφές επιθέσεων. Συμπληρώνει το ModSecurity (το οποίο λειτουργεί σε επίπεδο HTTP, ενώ το Suricata σε επίπεδο TCP/IP).
/var/log/suricata/eve.json ως root με δικαιώματα 750 στον κατάλογο, και ο διακομιστής web (www-data) δεν μπορεί να το διαβάσει. Ανοίξτε τον κατάλογο για διέλευση — τα αρχεία μέσα παραμένουν προστατευμένα:
Παρεμβάλλεται στις κλήσεις συστήματος μέσω eBPF/kernel module και εντοπίζει ανωμαλίες σε πραγματικό χρόνο: shell από nginx, ανάγνωση του /etc/passwd από διεργασία web, εγγραφή στο /bin κ.λπ.
journalctl -u falco (χωρίς sudo — μέσω της ομάδας systemd-journal). Βεβαιωθείτε ότι ο www-data ανήκει σε αυτή την ομάδα — δείτε «Ρύθμιση sudo» (σημ.2) στη σελίδα χειροκίνητης εγκατάστασης.
/etc/passwd, εγγραφή σε καταλόγους συστήματος). Μηδέν κρίσιμα σε ένα εικοσιτετράωρο σε έναν ήσυχο διακομιστή είναι υγιής κατάσταση.
journalctl απαιτεί δικαιώματα στο journal· για να βλέπει ο πίνακας τα συμβάντα σταθερά, η αυτόματη εγκατάσταση ενεργοποιεί στο Falco το file_output → /var/log/falco/falco.log και θέτει στην υπηρεσία UMask=0022 (το log διαβάζεται από τον web server). Σε νέα εγκατάσταση δεν χρειάζεται να το ρυθμίσετε χειροκίνητα.
ModSecurity — τείχος προστασίας web (WAF) για Apache ή Nginx. Μπλοκάρει επιθέσεις σε επίπεδο εφαρμογής: SQL injection, XSS, path traversal, σαρωτές.
IncludeOptional /etc/modsecurity/*.conf, ενώ το πακέτο τοποθετεί μόνο το modsecurity.conf-recommended — αυτό δεν ταιριάζει με τη μάσκα *.conf. Αν δεν το αντιγράψετε στο modsecurity.conf, το SecRuleEngine παραμένει Off: η μονάδα είναι φορτωμένη, οι κανόνες CRS είναι φορτωμένοι, αλλά η κίνηση δεν ελέγχεται και δεν δημιουργείται αρχείο ελέγχου. Η ενδιάμεση λειτουργία DetectionOnly απλώς καταγράφει συμβάντα χωρίς να μπλοκάρει τα αιτήματα — ο πίνακας τη δείχνει κίτρινη.
Πρόσβαση του πίνακα στο αρχείο ελέγχου. Το αρχείο /var/log/apache2/modsec_audit.log ανήκει στον root (δικαιώματα 640), ο web χρήστης δεν μπορεί να το διαβάσει. Ο πίνακας λαμβάνει τα δεδομένα μέσω ενός wrapper — δημιουργήστε το:
SecRuleEngine χωρίς εσοχή: οι γραμμές με εσοχή βρίσκονται μέσα σε μπλοκ <LocationMatch>/<Directory> (για παράδειγμα, απενεργοποίηση του WAF για το phpMyAdmin) και δεν καθορίζουν την καθολική λειτουργία.www-data, στο HestiaCP το pool του ιστότοπου τρέχει από τον ιδιοκτήτη του ιστότοπου (για παράδειγμα, admin) — ελέγξτε με grep -E '^user' /etc/php/*/fpm/pool.d/monitor.example.com.conf.X-Forwarded-For. Στα στατιστικά καταλήγουν μόνο οι συναλλαγές με ενεργοποιημένο κανόνα: η οδηγία SecAuditLogRelevantStatus γράφει στο αρχείο ελέγχου οποιεσδήποτε αποκρίσεις 4xx/5xx, οπότε εκεί καταλήγουν και τα συνηθισμένα 403/500 — ο πίνακας δεν τα θεωρεί συμβάντα WAF.---RULES--- χρειάζεται για την ενότητα «Όλοι οι ενεργοί κανόνες» — ο πίνακας δεν δείχνει μόνο τους κανόνες που ενεργοποιήθηκαν, αλλά όλους τους φορτωμένους κανόνες CRS + τους προσαρμοσμένους. Οι τρεις διαδρομές στον βρόχο for f in … είναι τα τυπικά σημεία για κανόνες CRS και τοπικές προσθήκες· αν έχετε διαφορετική διάταξη (το πακέτο τοποθετεί τα αρχεία στον δικό του κατάλογο, ή οι προσαρμοσμένοι κανόνες δεν βρίσκονται στο /etc/modsecurity/custom-rules.conf), βρείτε τις πραγματικές διαδρομές με την εντολή sudo grep -rl 'IncludeOptional\|^Include ' /etc/apache2/mods-enabled/security2.conf /etc/apache2/conf-enabled/*.conf 2>/dev/null και τοποθετήστε τις στη λίστα. Αν το wrapper είναι παλιό (χωρίς αυτή την ενότητα) — η ενότητα απλώς θα δείξει την προειδοποίηση «μη διαθέσιμο», η υπόλοιπη σελίδα λειτουργεί όπως πριν.
Auditd (Linux Audit Daemon) καταγράφει τις κλήσεις συστήματος σε επίπεδο πυρήνα: συνδέσεις και αποσυνδέσεις, εντολές sudo, αποτυχημένες προσπάθειες ταυτοποίησης, αλλαγές αρχείων. Η μονάδα εμφανίζει τις συνδέσεις, τις αποτυχημένες προσπάθειες και τις εντολές sudo της σημερινής ημέρας.
ausearch (/usr/sbin/ausearch) και, όταν χρειάζεται, από το /var/log/audit/audit.log με την εντολή tail. Και τα δύο πρέπει να βρίσκονται στο sudoers.
Παρακολουθεί υπηρεσίες (nginx, php-fpm, mysql κ.λπ.) και τις επανεκκινεί όταν πέσουν. Μπορεί να στέλνει ειδοποιήσεις σε email.
monit status. Στο /etc/monit/monitrc πρέπει να είναι ενεργοποιημένο το HTTP interface (μπλοκ set httpd με allow localhost), αλλιώς το monit status θα επιστρέψει σφάλμα.
monitrc η γραμμή set httpd είναι σε σχόλιο (από προεπιλογή είναι ως # set httpd port 2812 …). Αφαιρέστε το σχόλιο από το μπλοκ και επιτρέψτε το localhost. (2) Το ενεργοποιημένο httpd από μόνο του δεν παρακολουθεί τίποτα — το Monit μετράει μόνο ό,τι περιγράφεται με στάντζες check· χωρίς αυτές η λίστα είναι κενή ακόμη και με λειτουργικό interface. Ελάχιστη λειτουργική ρύθμιση:
conf.d με httpd στη 2812 και ένα σύνολο ελέγχων — σε νέα εγκατάσταση δεν χρειάζεται χειροκίνητη ρύθμιση.
PSAD αναλύει το αρχείο καταγραφής του iptables και εντοπίζει σαρώσεις θυρών και δικτυακές επιθέσεις, αποδίδοντας σε κάθε πηγή ένα επίπεδο απειλής (1–5). Συμπληρώνει τα fail2ban και Suricata.
psad --Status (απαιτείται στο sudoers). Χωρίς καταγραφή του iptables η σελίδα θα είναι κενή — αυτό είναι φυσιολογικό όσο δεν έχουν γίνει σαρώσεις.
Mandatory Access Control περιορίζει σε ποια αρχεία και πόρους μπορεί να έχει πρόσβαση ένα πρόγραμμα, ακόμη κι αν παραβιαστεί. Στα Ubuntu/Debian χρησιμοποιείται από προεπιλογή το AppArmor (συνήθως ήδη εγκατεστημένο και ενεργό).
aa-status (απαιτείται στο sudoers). Δείχνει τον αριθμό των προφίλ σε λειτουργία enforce/complain και τις διεργασίες χωρίς προφίλ.
Τα «φορτωμένα προφίλ» είναι περισσότερα από enforce + complain — αυτό είναι φυσιολογικό. Στο AppArmor 4.x (Ubuntu 24.04 και νεότερα) προστέθηκε η λειτουργία unconfined: το προφίλ είναι φορτωμένο στον πυρήνα, αλλά δεν περιορίζει τίποτα. Το Ubuntu επισημαίνει έτσι δεκάδες προφίλ για προγράμματα που χρησιμοποιούν user namespaces (προγράμματα περιήγησης, πελάτες torrent και παρόμοια). Όταν υπάρχουν τέτοια προφίλ, η κάρτα «Φορτωμένα προφίλ» γίνεται πορτοκαλί και δείχνει τον αριθμό τους — για παράδειγμα unconfined: 90 με 120 φορτωμένα και 26 σε enforce. Πραγματική προστασία παρέχουν μόνο τα προφίλ σε enforce· στο Ubuntu 22.04 (AppArmor 3.x) δεν υπάρχει αυτή η λειτουργία και οι αριθμοί πάντα ταιριάζουν.
unconfined αξίζει μόνο συνειδητά: είναι απενεργοποιημένα όχι κατά λάθος, αλλά επειδή διαφορετικά χαλάει η λειτουργία των ίδιων των προγραμμάτων. Τα προφίλ σε complain είναι άλλη υπόθεση: εκεί οι κανόνες έχουν ήδη γραφτεί και απλώς δεν εφαρμόζονται.
Το debsums ελέγχει ότι τα αρχεία των εγκατεστημένων πακέτων ταιριάζουν με τα αθροίσματα ελέγχου του αποθετηρίου — εντοπίζει αλλοιωμένα εκτελέσιμα του συστήματος (συμπληρώνει το AIDE). Ο πλήρης έλεγχος διαρκεί 1–2 λεπτά, γι' αυτό εκτελείται μέσω cron, και ο πίνακας διαβάζει το αποτέλεσμα από το data/debsums/debsums.log και το κατηγοριοποιεί μόνος του (σημασία έχουν μόνο τα εκτελέσιμα και οι βιβλιοθήκες).
Η εργασία μπαίνει στο root-cron (sudo crontab -e). Το έτοιμο περιτύλιγμα debsums-scan.sh τοποθετείται στο /usr/local/bin/ (chmod +x· δείτε τη σύνοψη εργασιών cron) και γράφει μόνο του την αναφορά στο data/debsums/ του πίνακα.
Το περιτύλιγμα debsums-scan.sh βρίσκει μόνο του το data/ του πίνακα — δεν χρειάζεται να ορίσετε διαδρομή.
/etc/ (ρυθμίσεις) και /usr/share/ (πόροι) στον διακομιστή είναι συνήθως φυσιολογικές — ο πίνακας τις επισημαίνει με ξεχωριστό χρώμα. Ανησυχητικές είναι οι αλλαγές σε εκτελέσιμα και βιβλιοθήκες (/bin, /sbin, /usr/lib κ.λπ.) — η κάρτα «Εκτελέσιμα / βιβλιοθήκες» δείχνει ακριβώς αυτές.
Το Lynis εκτελείται χειροκίνητα ή μέσω cron. Η αναφορά πρέπει να αποθηκεύεται στον φάκελο data/lynis/ του έργου — η μονάδα διαβάζει το αρχείο lynis-report.dat.
lynis-scan.sh στο παρασκήνιο απευθείας από τον πίνακα (χωρίς αναμονή για το cron): εμφανίζει «Σάρωση…» και με την ολοκλήρωση ενημερώνει μόνο του την αναφορά. Για αυτό, ο χρήστης web χρειάζεται μια γραμμή sudoers για την εκτέλεση του script — ο εγκαταστάτης την προσθέτει αυτόματα στο /etc/sudoers.d/monitor. Αν ο πίνακας εγκαταστάθηκε χειροκίνητα/παλαιότερα, προσθέστε την με τον ίδιο χρήστη που αναγράφεται ήδη στο αρχείο:
Το Logwatch πρέπει να αποθηκεύει τις καθημερινές αναφορές στον φάκελο data/logwatch/ του έργου σε μορφή .txt. Η μονάδα εμφανίζει την τελευταία αναφορά και το αρχείο.
Η παρακολούθηση δικτύου δεν απαιτεί εγκατάσταση — είναι μια ενσωματωμένη σελίδα του πίνακα. Εμφανίζει την κατάσταση δικτύου του διακομιστή από τοπικές πηγές:
/proc/net/dev·ip·ss·journalctl -k.Οι τρεις πρώτες πηγές λειτουργούν χωρίς sudo, οπότε οι διεπαφές, η κίνηση, οι συνδέσεις και οι θύρες φαίνονται αμέσως. Το τμήμα «Συμβάντα πυρήνα» χρησιμοποιεί journalctl -k — διαβάζεται μέσω της ομάδας systemd-journal («Ρύθμιση sudo», β.2), δεν χρειάζεται sudo. Ελέγξτε ότι όλα είναι προσβάσιμα από τον χρήστη web:
UFW BLOCK δεν εμφανίζονται εδώ — βρίσκονται στις σελίδες «Τείχος προστασίας UFW» και «Χάρτης επιθέσεων». Κενό τμήμα με πράσινο τικ = μέσα στο 24ωρο δεν υπήρξαν αστοχίες δικτύου.
Η ενσωματωμένη σελίδα εμφανίζει τρία πράγματα:
df)· η μπάρα κοκκινίζει στο ≥90%·lsblk), μόνο πραγματικά (τα loop/snap αποκρύπτονται)·smartctl).Ο χώρος και η λίστα συσκευών λειτουργούν αμέσως, χωρίς ρύθμιση. Για το SMART απαιτείται το πακέτο smartmontools. Η διεργασία web δεν έχει άμεση πρόσβαση στις συσκευές δίσκων, γι' αυτό το SMART λαμβάνεται μέσω cron στο αρχείο data/disk/smart.txt, και ο πίνακας το διαβάζει.
Η εργασία μπαίνει στο root-cron (sudo crontab -e). Το έτοιμο wrapper smart-scan.sh τοποθετείται στο /usr/local/bin/ (chmod +x· δείτε τη σύνοψη εργασιών cron) και γράφει το ίδιο στο data/disk/ του πίνακα.
Το wrapper smart-scan.sh εντοπίζει μόνο του το data/ του πίνακα — δεν χρειάζεται να ορίσετε διαδρομή. Εσωτερικά το lsblk -e7,11 εξαιρεί τα loop/cdrom.
Η σελίδα εμφανίζει το ιστορικό φορτίου του διακομιστή για τις τελευταίες 24 ώρες — Load Average, χρήση CPU και αναμονή I/O, RAM/Swap, δικτυακή κίνηση (λήψη/αποστολή), I/O δίσκου (ανάγνωση/εγγραφή), πλήρωση δίσκου και inodes, ανοιχτούς περιγραφείς αρχείων και συνδέσεις MySQL, καθώς και τον τρέχοντα αριθμό συνδέσεων TCP και διεργασιών. Το παράθυρο των 24 ωρών είναι το προεπιλεγμένο: τα κουμπιά επάνω το αλλάζουν σε 7 ημέρες ή 30 ημέρες.
Τα δεδομένα συλλέγει το cron/collect_metrics.php — κάθε 5 λεπτά γράφει ένα «ακατέργαστο» στιγμιότυπο των μετρητών (/proc/loadavg, /proc/meminfo, /proc/stat, /proc/net/dev, /proc/diskstats, df/df -i, /proc/sys/fs/file-nr, SHOW GLOBAL STATUS LIKE 'Threads_connected') στον πίνακα ΒΔ system_metrics· τα ποσοστά και τις ταχύτητες τα υπολογίζει η ίδια η σελίδα από τη διαφορά μεταξύ γειτονικών στιγμιότυπων (πλήρωση δίσκου/inodes/περιγραφέων/συνδέσεων MySQL — στιγμιαίες τιμές, χωρίς επανυπολογισμό). Δεν απαιτείται sudo — οι πηγές διαβάζονται χωρίς δικαιώματα root.
Δύο βάθη αποθήκευσης. Τα «ακατέργαστα» πεντάλεπτα στιγμιότυπα ζουν ένα εικοσιτετράωρο (συν μία ώρα περιθώριο, ώστε το παλαιότερο σημείο του γραφήματος να έχει ακόμη προκάτοχο για τον υπολογισμό). Κάθε ώρα που ολοκληρώνεται συμπτύσσεται σε μία γραμμή· αυτή η ωριαία σειρά διατηρείται 30 ημέρες και ακριβώς αυτήν διαβάζουν οι προβολές «7 ημέρες» και «30 ημέρες». Έτσι ένας μήνας ιστορικού κοστίζει περίπου 720 γραμμές αντί για περίπου 8600.
Το wrapper collect-metrics-all.sh (δείτε τη σύνοψη εργασιών cron) εντοπίζει μόνο του όλα τα εγκατεστημένα instances του πίνακα στον διακομιστή και εκτελεί το cron/collect_metrics.php του καθενός με ταυτότητα του κατόχου του ιστότοπου.
Κορυφαίες διεργασίες. Κάτω από τα γραφήματα υπάρχουν δύο πίνακες με τις πέντε διεργασίες που καταναλώνουν την περισσότερη CPU:
Και οι δύο πίνακες περιγράφουν πάντα τις τελευταίες 24 ώρες, ακόμη κι όταν τα γραφήματα δείχνουν έναν μήνα: στιγμιότυπο διεργασιών φέρουν μόνο οι πεντάλεπτες γραμμές, και αυτές δεν διατηρούνται πάνω από ένα εικοσιτετράωρο.
ps, το σενάριο PHP της συλλογής και η αλυσίδα cron/sudo από πάνω) εξαιρούνται από τον κατάλογο — αλλιώς θα βρίσκονταν στην κορυφή κάθε στιγμιότυπου: το ps, τη στιγμή της εκκίνησης, δείχνει σχεδόν 100 % CPU. Οι υπόλοιπες εργασίες cron που έτρεξαν το ίδιο λεπτό εμφανίζονται κανονικά — ακριβώς γι’ αυτό υπάρχει ο πίνακας.
Ειδοποιήσεις φορτίου (ενότητα «Ρυθμίσεις» → «Ειδοποιήσεις φορτίου») — όταν ξεπεραστεί το όριο για CPU/RAM/δίσκο/inodes ο πίνακας στέλνει ειδοποίηση από όλα τα ενεργοποιημένα κανάλια (Telegram, Email, webhook, push — τα ίδια με την ημερήσια αναφορά· για τις ειδοποιήσεις δεν χρειάζεται να ενεργοποιηθεί κάτι επιπλέον) και άλλη μία όταν η μέτρηση επανέλθει στο φυσιολογικό. Όσο το όριο διατηρείται, δεν επαναλαμβάνει: η επόμενη ειδοποίηση έρχεται μόνο μετά από κύκλο «επανήλθε → ξεπεράστηκε ξανά».
collect_metrics.php σε κάθε εκτέλεση (κάθε 5 λεπτά) — δεν χρειάζεται ξεχωριστό cron. Η κατάσταση «ήδη ειδοποιήσαμε / όχι ακόμη» αποθηκεύεται στο data/alerts_state.json, τα όρια — στις ρυθμίσεις του πίνακα.
Η ημερήσια αναφορά απαντά στο ερώτημα «πώς πάει ο διακομιστής». Ο αισθητήρας απαντά σε άλλο — «τι μόλις συνέβη». Κάθε 5 λεπτά ρωτά τις γρήγορες πηγές και καταγράφει μόνο ό,τι άλλαξε από τον προηγούμενο έλεγχο· η σελίδα «Συμβάντα ασφάλειας» στο μενού δείχνει τη λίστα των ευρημάτων.
Τους αργούς ελέγχους — Lynis, debsums, ενημερώσεις πακέτων, λήξη SSL — ο αισθητήρας δεν τους αγγίζει: οι αριθμοί τους έτσι κι αλλιώς αλλάζουν μία φορά την ημέρα και παραμένουν αρμοδιότητα της ημερήσιας αναφοράς.
Τι εντοπίζει — εννέα πηγές:
[Priority: 1] ανεβάζει το εύρημα σε κρίσιμο·FOUND στο αρχείο καταγραφής της σάρωσης·root (κρίσιμο) και σύνδεση από διεύθυνση που δεν είχε εμφανιστεί ξανά (προειδοποίηση)·Ένα εργαλείο που δεν είναι εγκατεστημένο ή του οποίου το αρχείο καταγραφής δεν μπορεί να διαβάσει ο πίνακας απλώς σιωπά — αυτό δεν είναι ούτε σφάλμα ούτε συμβάν.
data/secwatch_state.json) και το πρώτο πέρασμα απλώς γράφει αυτή τη σήμανση. Διαφορετικά, με την ενεργοποίηση της παρακολούθησης θα ερχόταν ειδοποίηση για όλα όσα έχουν συσσωρευτεί στα αρχεία καταγραφής επί μήνες.
Ρύθμιση — «Ρυθμίσεις» → «Παρακολούθηση συμβάντων»:
23-7, κατά το οποίο οι προειδοποιήσεις δεν αποστέλλονται.Οι ειδοποιήσεις πηγαίνουν από τα ίδια κανάλια με την ημερήσια αναφορά (Telegram, Email, webhook, push) — δεν χρειάζεται να ενεργοποιηθεί κάτι επιπλέον. Όλα τα ευρήματα γράφονται στη λίστα ανεξάρτητα από το αν στάλθηκε ειδοποίηση, και διατηρούνται 90 ημέρες.
Η λίστα συμβάντων. Φίλτρα: περίοδος (24 ώρες, 7, 30 ή 90 ημέρες), σημαντικότητα και πηγή· εμφανίζονται οι τελευταίες 500 εγγραφές. Το κουμπί «Έλεγχος τώρα» εκτελεί ακριβώς το ίδιο πέρασμα με το cron — βολικό αμέσως μετά τη ρύθμιση, για να μην περιμένετε πέντε λεπτά· αναφέρει επίσης τον λόγο όταν δεν στάλθηκε ειδοποίηση («κάτω από το όριο σημαντικότητας», «ώρες ησυχίας», «δεν έχει ρυθμιστεί κανένα κανάλι ειδοποιήσεων»). Ο κόκκινος μετρητής δίπλα στο στοιχείο του μενού είναι ο αριθμός των κρίσιμων συμβάντων των τελευταίων 24 ωρών.
Η κάρτα διεύθυνσης. Ένα κλικ σε γραμμή της λίστας συμβάντων ή του μπλοκ Συσχετισμένες διευθύνσεις ανοίγει όσα είναι γνωστά για μία διεύθυνση: το χρονολόγιο των συμβάντων της, τη χώρα και, στην πρώτη γραμμή, ένα συμπέρασμα. Η γραμμή της λίστας ανοίγει την κάρτα όταν το συμβάν αφορά ακριβώς μία διεύθυνση· αν αναφέρει περισσότερες, σύνδεσμοι είναι οι ίδιες οι διευθύνσεις μέσα στη γραμμή. Τα συμπεράσματα είναι τέσσερα:
Κάτω από το χρονολόγιο βρίσκεται το μπλοκ Τι συνέβαινε στον διακομιστή την ίδια ώρα: συμβάντα που δεν έχουν καθόλου διεύθυνση. Το AIDE δεν ξέρει ποιος άλλαξε το αρχείο, το ClamAV δεν ξέρει ποιος έφερε το μολυσμένο. Εμφανίζονται όσα εμπίπτουν στη δράση της διεύθυνσης και στις έξι ώρες μετά. Ακριβώς η σύνδεση μαζί με ό,τι ακολούθησε ξεχωρίζει την απόπειρα από την πραγματική πρόσβαση.
Πρόγραμμα. Η εργασία μπαίνει στο crontab του root (sudo crontab -e), με μετατόπιση 2 λεπτών από τη συλλογή μετρήσεων, ώστε οι δύο να μην ξεκινούν ταυτόχρονα:
php cron/security_watch.php. Το wrapper βρίσκει όλες τις εγκαταστάσεις του πίνακα στον διακομιστή και εκτελεί τον έλεγχο εκ μέρους του ιδιοκτήτη του ιστότοπου — με ακριβώς τα δικαιώματα sudo που χρησιμοποιεί ο πίνακας από τον ιστό. Μια απευθείας κλήση από το crontab του root θα δημιουργούσε το αρχείο κατάστασης data/secwatch_state.json με ιδιοκτήτη τον root, και το κουμπί «Έλεγχος τώρα» θα έπαυε να λειτουργεί.
Η σελίδα «Διακομιστής web» αναλύει το αρχείο καταγραφής προσπελάσεων και δείχνει πόσα αιτήματα υπήρξαν, ποιο μέρος τους κατέληξε σε σφάλμα και ποιος τα έκανε. Το ModSecurity απαντά στο ερώτημα «τι μπλοκαρίστηκε», αυτή η σελίδα στο ερώτημα «τι έφτασε γενικά στον ιστότοπο».
Τι φαίνεται: αριθμός αιτημάτων, RPS, ποσοστό σφαλμάτων, ξεχωριστός μετρητής 5xx και ο όγκος που στάλθηκε· γράφημα αιτημάτων ανά ώρα· κατανομή των κωδικών 2xx/3xx/4xx/5xx· συχνές διευθύνσεις, συχνές IP, συχνά σφάλματα (κωδικός συν διαδρομή) και πελάτες (User-Agent). Περίοδος: 24 ώρες ή 7 ημέρες.
Πηγή είναι το αρχείο καταγραφής προσπελάσεων σε μορφή combined, οπότε ταιριάζουν και ο Nginx και ο Apache, και δεν χρειάζεται πρόσθετο άρθρωμα. Ο πίνακας αναζητά το αρχείο καταγραφής ανάμεσα στα τυπικά αρχεία:
/var/log/nginx/access.log/var/log/apache2/access.log/var/log/apache2/other_vhosts_access.log/var/log/httpd/access_logΕκτός από αυτά, ο πίνακας ελέγχει τα αρχεία *access*.log και *requests*.log στους καταλόγους /var/log/nginx/, /var/log/apache2/ και /var/log/httpd/. Έτσι βρίσκεται και το αρχείο καταγραφής που ένας ιστότοπος γράφει σε δικό του αρχείο με την οδηγία CustomLog — για παράδειγμα το arciveo-monitor_requests.log, που δημιουργεί ο εγκαταστάτης του Arcivéo.
Διαβάζεται μόνο ένα αρχείο καταγραφής: όταν ο Nginx βρίσκεται μπροστά από τον Apache, η άθροιση δύο αρχείων θα μετρούσε κάθε αίτημα δύο φορές. Λαμβάνεται το πρώτο αρχείο της παραπάνω λίστας στο οποίο έγινε εγγραφή το τελευταίο εικοσιτετράωρο (όσα βρέθηκαν μέσω μοτίβου ονόματος δοκιμάζονται μετά, από το νεότερο)· αν δεν έγινε εγγραφή σε κανένα για ένα εικοσιτετράωρο, λαμβάνεται το πιο πρόσφατο μη κενό. Έτσι, ένα αρχείο που άδειασε από το logrotate ή έμεινε από σταματημένο διακομιστή web δεν κρύβει πια το ενεργό. Διαβάζεται το τελευταίο τμήμα του αρχείου (3 MB) και το αποτέλεσμα αποθηκεύεται προσωρινά για 5 λεπτά — σε φορτωμένο ιστότοπο η επιλεγμένη περίοδος μπορεί λοιπόν να μην καλύπτεται πλήρως· η πραγματική κάλυψη αναγράφεται πάνω από το γράφημα.
adm, και ο χρήστης του web δεν ανήκει σε αυτήν. Ο εγκαταστάτης του Arcivéo τον προσθέτει σε αυτή την ομάδα· μετά από χειροκίνητη εγκατάσταση βοηθά ένα μικρό wrapper του root, στο οποίο επιτρέπεται ένα ακριβώς πράγμα — να εμφανίζει το αρχείο καταγραφής (η σελίδα του ModSecurity λειτουργεί με τον ίδιο τρόπο). Το wrapper επιλέγει το αρχείο με τους ίδιους κανόνες με τον πίνακα. Η εντολή εμφανίζεται στην ίδια τη σελίδα· ορίστε και εδώ. Επικολλήστε την ολόκληρη — είναι μία εντολή:
Ο χρήστης του web μπορεί να διαφέρει από τον www-data — ελέγξτε με ποιον χρήστη τρέχει η δεξαμενή PHP-FPM του ιστότοπου (ps -o user= -C php-fpm) και βάλτε τον στη γραμμή του sudoers. Αν το όνομα του αρχείου καταγραφής δεν περιέχει ούτε access ούτε requests, προσθέστε τη διαδρομή του στην αρχή της γραμμής L=… μέσα στο wrapper.
Απόπειρες γνωστών exploits. Ο πίνακας ελέγχου συγκρίνει τα αιτήματα του αρχείου καταγραφής με τις υπογραφές περίπου είκοσι διαδεδομένων exploits: PHP-CGI, διάσχιση καταλόγων στον Apache, PHPUnit, Log4Shell, ευπάθειες δρομολογητών, καμερών και πυλών VPN. Για κάθε απόπειρα απαντά αν μπορεί να λειτουργήσει σε αυτόν τον server και στηρίζεται σε γεγονότα: τις εγκατεστημένες εκδόσεις του Apache και της PHP, την ύπαρξη Java και τον κωδικό με τον οποίο ο server απάντησε στο αίτημα του αρχείου. Με κόκκινο σημειώνεται μόνο ό,τι μπορεί πραγματικά να λειτουργήσει.
Θωράκιση του web server. Ο πίνακας ελέγχου ζητά κάθε ιστότοπο του server μέσω 127.0.0.1 και ελέγχει τι λαμβάνει ο επισκέπτης: αν φαίνονται οι εκδόσεις του web server και της PHP, αν η μέθοδος TRACE είναι ενεργή και αν υπάρχουν οι προστατευτικές κεφαλίδες Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy και Content-Security-Policy. Οι ιστότοποι λαμβάνονται από τη διεύθυνση στην οποία ανοίγει ο πίνακας και από τα αρχεία των εικονικών κεντρικών υπολογιστών, αν ο πίνακας μπορεί να τα διαβάσει. Το αποτέλεσμα ανανεώνεται κάθε 10 λεπτά.
Αν κάτι λείπει, κάτω από τον πίνακα εμφανίζεται μία εντολή. Δημιουργεί ξεχωριστό αρχείο, zz-arciveo-hardening.conf, και επαναφορτώνει τον web server μόνο αφού περάσει ο έλεγχος ρυθμίσεων· οι κεφαλίδες που ο ιστότοπος ήδη στέλνει δεν διπλασιάζονται. Το CSP δεν προτείνεται ως μία γραμμή: η πολιτική φτιάχνεται για τον συγκεκριμένο ιστότοπο, αλλιώς σταματά να φορτώνει τα δικά του scripts, στυλ και γραμματοσειρές. Αναίρεση της αλλαγής στον Apache:
ServerSignature) δεν επισημαίνεται όταν η έκδοση του web server είναι ήδη κρυφή: χωρίς έκδοση δείχνει μόνο το όνομα του server και το όνομα του κεντρικού υπολογιστή.
Η σελίδα «Χάρτης επιθέσεων» εντοπίζει τη χώρα από την IP με την εντολή geoiplookup. Χωρίς το πακέτο GeoIP δεν εντοπίζονται οι χώρες και δεν εμφανίζονται σημεία στον χάρτη:
/usr/share/GeoIP/GeoIP.dat είναι αναγνώσιμη από όλους, τα αποτελέσματα αποθηκεύονται προσωρινά στο tmp/geoip_cache.json. Ο ίδιος ο χάρτης (Leaflet + πλακίδια OpenStreetMap) φορτώνεται στο πρόγραμμα περιήγησης — χρειάζεται σύνδεση στο διαδίκτυο στον υπολογιστή όπου είναι ανοιχτός ο πίνακας.
Δύο ενσωματωμένες κάρτες του dashboard που δείχνουν όχι το «ενεργό/ανενεργό» ενός εργαλείου, αλλά την πραγματική προστασία του διακομιστή. Δεν χρειάζονται εγκατάσταση, διαβάζονται τοπικά χωρίς sudo.
Εξωτερική έκθεση — πόσες υπηρεσίες ακούν σε όλες τις διεπαφές (0.0.0.0/[::]) και είναι προσβάσιμες από έξω. Επισημαίνει με κόκκινο αν εκτίθενται προς τα έξω βάσεις δεδομένων ή cache (MySQL, PostgreSQL, Redis, MongoDB, Memcached, Elasticsearch) — είναι άμεση τρύπα (−10 στη Βαθμολογία ασφάλειας). Πηγή: ss -tuln.
127.0.0.1 (bind-address στη ρύθμιση του MySQL/PostgreSQL, bind 127.0.0.1 στο Redis) ή κλείστε τη θύρα στο UFW.
127.0.0.1 (loopback) είναι ορατή μόνο στον ίδιο τον διακομιστή — από έξω δεν την προσεγγίζεις, ακόμη κι αν η θύρα είναι «ανοιχτή». Γι' αυτό το Postfix στη θύρα 25, δεμένο στο loopback, είναι ασφαλές: η αυτόματη ρύθμιση ορίζει inet_interfaces = loopback-only (συν ουδέτερο smtpd_banner — κλείνει την παρατήρηση MAIL-8818 του Lynis για την αποκάλυψη έκδοσης). Η κάρτα «Εξωτερική έκθεση» θεωρεί εκτεθειμένο προς τα έξω μόνο ό,τι ακούει στο 0.0.0.0/[::]· οι υπηρεσίες loopback δεν συμπεριλαμβάνονται.
/etc/postfix/main.cf ορίστε smtpd_banner = $myhostname ESMTP (χωρίς έκδοση και ΛΣ) και inet_interfaces = loopback-only, μετά sudo systemctl restart postfix.
Ενημερώσεις ασφαλείας — πόσα security patch περιμένουν εγκατάσταση και αν χρειάζεται επανεκκίνηση μετά την ενημέρωση του πυρήνα (−5 στη Βαθμολογία ασφάλειας όταν υπάρχουν patch). Πηγή: /usr/lib/update-notifier/apt-check, αρχείο /var/run/reboot-required. Αναλυτική λίστα — στη σελίδα «Ενημερώσεις ασφαλείας».
update-notifier-common). Αν λείπει το apt-check — η μονάδα μετρά τα patch μέσω apt-get -s upgrade.
Αυτόματες ενημερώσεις ασφαλείας (unattended-upgrades) — στη σελίδα «Ενημερώσεις ασφαλείας» μια ξεχωριστή κάρτα δείχνει αν είναι ενεργή η αυτόματη εγκατάσταση των security patch και πότε εκτελέστηκε τελευταία φορά. Δεν χρειάζεται sudo — η κατάσταση διαβάζεται μέσω apt-config dump.
Το backup είναι η βασική ασφάλεια: η απώλεια δεδομένων είναι χειρότερη από κάθε παραβίαση. Χρειάζονται δύο πράγματα — backup του διακομιστή/των ιστότοπων και ξεχωριστά backup της ΒΔ του πίνακα (εκεί βρίσκονται χρήστες, κλειδιά WebAuthn, ρυθμίσεις, άδεια).
Επιλογή A — HestiaCP: καρτέλα Backup στον χρήστη → κουμπί δημιουργίας backup (ή προγραμματισμένα στις ρυθμίσεις του διακομιστή). Το backup περιλαμβάνει ιστότοπους και τις ΒΔ τους.
Επιλογή B — χειροκίνητα (cron): dump της ΒΔ + αρχειοθέτηση του καταλόγου data/ του πίνακα:
Ενημέρωση σε νέα έκδοση. Πρώτα κάντε αντίγραφο ασφαλείας. Στη συνέχεια ανεβάστε ξανά τα αρχεία κώδικα, διατηρώντας τα δεδομένα σας:
public/, includes/, assets/, cron/, database/, καθώς και τα βασικά .htaccess (front controller — η δρομολόγηση δεν πρέπει να παραμένει από την παλιά έκδοση), manifest.json, sw.js;config.php (δεδομένα ΒΔ), data/ (αναφορές), logs/, tmp/ (συνεδρίες και προσωρινή μνήμη).SSH_FX_PERMISSION_DENIED — Permission denied. Τα αρχεία του πίνακα ανήκουν στον www-data (έτσι ορίστηκαν κατά την εγκατάσταση), ενώ ο πελάτης SFTP συνδέεται με τον δικό σας χρήστη, που δεν έχει δικαίωμα εγγραφής. Το να δώσετε στον www-data ολόκληρο τον πίνακα «για να δουλέψει» είναι ακριβώς αυτό που οδηγεί σε αυτό το σφάλμα· παρακάτω τρεις τρόποι, οποιοσδήποτε λύνει το πρόβλημα.
data/ (αναφορές), tmp/ (συνεδρίες και προσωρινή μνήμη), logs/· αυτοί παραμένουν στον www-data. Τα υπόλοιπα είναι κώδικας, και ο διακομιστής web τον χρειάζεται μόνο για ανάγνωση, την οποία δίνει η ομάδα www-data με δικαιώματα 644. Επιπλέον όφελος: με ευπάθεια στην PHP τα αρχεία του πίνακα δεν μπορούν πλέον να αντικατασταθούν. Στους πίνακες φιλοξενίας (HestiaCP και παρόμοιους) η παραλλαγή A δεν χρειάζεται: εκεί τα αρχεία του ιστότοπου ανήκουν έτσι κι αλλιώς στον λογαριασμό με τον οποίο συνδέεστε μέσω SFTP, ενώ ο διακομιστής web τα διαβάζει μέσω ομάδας.
chmod στα αρχεία μηδενίζει τη μάσκα ACL, και η πρόσβαση χάνεται σιωπηλά. Αν μετά από «τακτοποίηση των δικαιωμάτων» το ανέβασμα σκοντάφτει ξανά σε Permission denied — επαναλάβετε και τις δύο εντολές setfacl.
2 στην παραλλαγή C είναι το setgid: τα αρχεία που ανεβαίνουν μέσω SFTP παραμένουν στην ομάδα www-data, αλλιώς ο πίνακας δεν μπορεί να τα αντικαταστήσει. Μετά την παραλλαγή C συνδεθείτε ξανά στο FileZilla — η νέα ομάδα ισχύει μόνο σε νέα σύνδεση. Έλεγχος: id deploy (πρέπει να εμφανιστεί η ομάδα www-data) και ls -ld /path/to/monitor (drwxrwsr-x — το γράμμα s σημαίνει ότι το setgid είναι ενεργό).
Μεταφορά σε άλλον διακομιστή:
config.php, data/.mysqldump στον παλιό → εισαγωγή στον νέο· διορθώστε τα δεδομένα ΒΔ στο config.php.adm, εργασίες cron.Ο πίνακας λειτουργεί ήδη και στον ίδιο διακομιστή χρειάζεται ακόμη ένας ιστότοπος — με δικό του domain δίπλα στον monitor. Μετά την αυτόματη εγκατάσταση ο διακομιστής είναι ένας συνηθισμένος Apache + PHP-FPM, οπότε ο ιστότοπος χρειάζεται τρία πράγματα: δικό του κατάλογο, δικό του vhost και δικό του πιστοποιητικό. Ο πίνακας δεν πειράζεται: παρακολουθεί ολόκληρο τον διακομιστή, δεύτερο αντίγραφο για το δεύτερο domain δεν χρειάζεται.
site2.example.com είναι η διεύθυνση του νέου ιστότοπου. Μπορεί να είναι είτε ξεχωριστό domain (mycompany.com) είτε υποτομέας (shop.mycompany.com) — για τον Apache δεν υπάρχει διαφορά, αλλάζουν μόνο η εγγραφή DNS (βήμα 1) και η έκδοση του πιστοποιητικού (βήμα 5). Το site2 είναι απλώς ένα σύντομο όνομα του ιστότοπου: έτσι ονομάζονται ο κατάλογος /var/www/site2 και το αρχείο διαμόρφωσης site2.conf. Με το domain δεν έχει καμία σχέση, ο Apache παίρνει τη διεύθυνση μόνο από το ServerName· το όνομα μπορεί να είναι οποιοδήποτε — για το shop.mycompany.com, π.χ., βολεύει το shop: κατάλογος /var/www/shop, διαμόρφωση shop.conf.
1. DNS. Στον πίνακα DNS του καταχωρητή σας δημιουργήστε μια εγγραφή A προς την IP αυτού του διακομιστή:
Μετά από λίγα λεπτά ελέγξτε: το dig +short site2.example.com πρέπει να επιστρέψει την IP του διακομιστή.
2. Κατάλογος του ιστότοπου.
3. Το vhost. Το μπλοκ επικολλάται στο τερματικό ολόκληρο — η διαδρομή προς το socket του PHP-FPM εντοπίζεται μόνη της:
4. Ενεργοποιήστε τον ιστότοπο και ελέγξτε τη διαμόρφωση πριν την επαναφόρτωση:
5. SSL. Το certbot είναι ήδη εγκατεστημένο από την αυτόματη εγκατάσταση· σε αυτό το σημείο το DNS πρέπει να δείχνει στον διακομιστή:
Το τρίτο και τα επόμενα domain προστίθενται με τον ίδιο τρόπο — επαναλάβετε τα βήματα 1–5 αλλάζοντας domain και κατάλογο.
Host δεν ταιριάζει με κανένα ServerName (επίσκεψη μέσω IP ή ξένο domain στραμμένο στον διακομιστή σας), ο Apache σερβίρει τον πρώτο αλφαβητικά ενεργοποιημένο ιστότοπο από το /etc/apache2/sites-enabled/. Το τυπικό 000-default το απενεργοποιεί η αυτόματη εγκατάσταση, οπότε αυτόν τον ρόλο «υπηρεσίας» τον κρατά το vhost του πίνακα (arciveo-monitor.conf) — στους ιστότοπους που ανοίγουν με το δικό τους όνομα αυτό δεν επηρεάζει. Αν θέλετε μέσω IP να ανοίγει άλλος ιστότοπος, ονομάστε το αρχείο του ώστε να προηγείται αλφαβητικά (για παράδειγμα 000-site2.conf).
site2_error.log και site2_access.log στο /var/log/apache2/.
.htaccess (front controller) και ένας ένθετος ιστότοπος θα σέρβιρε κάτι διαφορετικό από αυτό που περιμένετε. Κρατήστε τους ιστότοπους δίπλα δίπλα: /var/www/monitor, /var/www/site2.
Αν δεν μπορείτε να συνδεθείτε — όλα διορθώνονται απευθείας στη ΒΔ από τον διακομιστή. Ανοίξτε τη ΒΔ (το όνομα από το config.php):
Χάθηκε το κλειδί WebAuthn (δεν περνά ο δεύτερος παράγοντας) — απενεργοποιήστε το 2FA, συνδεθείτε με κωδικό και καταχωρίστε νέο κλειδί:
Ξεχάσατε τον κωδικό — ορίστε νέο hash (δημιουργήστε τον στον διακομιστή και βάλτε τον):
Κλειδωθήκατε έξω με το φίλτρο IP — απενεργοποιήστε τον περιορισμό:
sudo mysql στον διακομιστή, ή phpMyAdmin / η ενότητα ΒΔ στον πίνακα του hosting. Μετά την επαναφορά, ενεργοποιήστε ξανά το WebAuthn και το φίλτρο IP.
Η σύνοψη των εργασιών βρίσκεται στο root-cron του διακομιστή (προστίθενται μέσω sudo crontab -e). Αφήστε μόνο τις γραμμές των εργαλείων που χρησιμοποιείτε· προσαρμόστε τις διαδρομές στον διακομιστή σας.
sudo crontab -l και ότι η υπηρεσία cron είναι ενεργή.
TIMEZONE από το config.php. Η σταθερά TIMEZONE επηρεάζει μόνο την PHP (πώς το panel εμφανίζει τις ημερομηνίες), αλλά ο δαίμονας cron εκτελεί τις εργασίες με βάση την ώρα του συστήματος του λειτουργικού. Αν η ζώνη του διακομιστή δεν συμπίπτει με τη δική σας, η αναφορά «08:00» θα φτάσει σε λάθος ώρα. Παράδειγμα: ο διακομιστής βρίσκεται σε άλλη ζώνη (Europe/Berlin, UTC+2) και εσείς στην Αθήνα (UTC+3) → η αναφορά «08:00» θα φτάσει στις 09:00 για εσάς. Ελέγξτε και, αν χρειάζεται, ρυθμίστε τη ζώνη του συστήματος στη δική σας:
0 8 * * * θα εκτελεστεί στις 08:00 τοπική ώρα. Διαφορετικά θα έπρεπε να μετατοπίζετε το ίδιο το cron, αλλά με τη μετάβαση σε χειμερινή/θερινή ώρα η μετατόπιση θα ξαναχαλάσει — γι' αυτό είναι σωστότερο να ρυθμίσετε τη ζώνη του συστήματος.
crontab.txt) βρίσκονται στον φάκελο system/ δίπλα στο έργο, εκτός του public_html. Αυτό δεν είναι μέρος του ιστότοπου — δεν χρειάζεται να τα ανεβάσετε στο web-root· τοποθετήστε τα στον διακομιστή στις διαδρομές του συστήματος (όπως στο crontab παραπάνω):
lynis-scan.sh → /usr/local/bin/ (chmod +x) — εκτελεί lynis audit system, κατά τη σάρωση θέτει το flag /tmp/lynis-running και αντιγράφει το lynis-report.dat στο data/lynis/ του panel·logwatch_daily.sh → /usr/local/bin/ (chmod +x) — δημιουργεί την καθημερινή αναφορά Logwatch (sshd, fail2ban, sudo, postfix) στο data/logwatch/·smart-scan.sh → /usr/local/bin/ (chmod +x) — καταγράφει την κατάσταση των δίσκων (smartctl) στο data/disk/·debsums-scan.sh → /usr/local/bin/ (chmod +x) — ελέγχει την ακεραιότητα των πακέτων (debsums) στο data/debsums/·clamav-scan.sh → /usr/local/bin/ (chmod +x) — σάρωση antivirus ClamAV σε επικίνδυνες διαδρομές (web, home, temp)· γράφει τη σύνοψη στο /var/log/clamav/scan.log, από όπου τη διαβάζει η σελίδα ClamAV (γραμμή 01:30 στο crontab παραπάνω)·load-ipsum.sh → /usr/local/bin/ (chmod +x) — ενημερώνει το σύνολο ipset ipsum (level 1) επιτόπου, χωρίς να σπάει τους ενεργούς κανόνες του firewall (γραμμή 04:00 στο crontab παραπάνω)·daily-report-all.sh → /usr/local/bin/ (chmod +x) — εκτελεί την αναφορά cron/daily_report.php του panel (γραμμή 08:00 στο crontab παραπάνω)·daily_report.php — περιλαμβάνεται ήδη στο panel (cron/daily_report.php), εκτελείται μέσω daily-report-all.sh, δεν χρειάζεται ξεχωριστή εγκατάσταση·collect-metrics-all.sh → /usr/local/bin/ (chmod +x) — εκτελεί το cron/collect_metrics.php του panel (σελίδα «Απόδοση», γραμμή */5 στο crontab παραπάνω)· το collect_metrics.php περιλαμβάνεται ήδη στο panel, δεν χρειάζεται ξεχωριστή εγκατάσταση·security-watch-all.sh → /usr/local/bin/ (chmod +x) — εκτελεί το cron/security_watch.php του πίνακα εκ μέρους του ιδιοκτήτη του ιστότοπου (σελίδα «Συμβάντα ασφάλειας», γραμμή 2-57/5 στο crontab παραπάνω)· το security_watch.php περιλαμβάνεται ήδη στον πίνακα και δεν εγκαθίσταται ξεχωριστά·fleet-push-all.sh → /usr/local/bin/ (chmod +x) — στέλνει την επισκόπηση του διακομιστή στον λογαριασμό μέσω του cron/fleet_push.php του πίνακα (γραμμή 3,18,33,48 παραπάνω)·crontab.txt (system/cron/) — δείγμα εργασιών· προσθέστε τις γραμμές που χρειάζεστε μέσω sudo crontab -e./usr/local/bin/. Απευθείας από το FileZilla δεν μπορείτε να γράψετε εκεί — ο κατάλογος ανήκει στον root και ο SFTP-client θα λάβει SSH_FX_PERMISSION_DENIED. Η σειρά είναι η εξής: πρώτα ανεβάστε το αρχείο στο /tmp (εκεί γράφουν όλοι), μετά μεταφέρετέ το στη θέση του με μία εντολή:
/tmp στη ρίζα του διακομιστή — όχι το /var/tmp ούτε το tmp/ μέσα στο ίδιο το panel (το τελευταίο ανήκει στον www-data και είναι κλειστό για τον χρήστη σας). Στο δέντρο του FileZilla το /tmp είναι κλάδος ανώτατου επιπέδου, δίπλα στο var, όχι μέσα σε αυτό.
/usr/local/bin/, log — /var/log/arciveo-cron.log) — δεν χρειάζεται να κάνετε τίποτα χειροκίνητα.
/home/*/web/*/public_html και /var/www/*, και τοποθετούν τις αναφορές στο data/ τους. Αν το panel βρίσκεται σε άλλη διαδρομή — προσθέστε τη στη γραμμή for app in … μέσα στα scripts, αλλιώς οι αναφορές Lynis/SMART/debsums/Logwatch δεν θα φτάσουν στο panel.
logs/cron.log το δημιουργεί πρώτο το root-cron — θα ανήκει στον root, και η καρτέλα «Αρχείο καταγραφής cron» στο panel δεν θα μπορεί ούτε να το διαβάσει ούτε να το καθαρίσει. Δημιουργήστε το αρχείο εκ των προτέρων ως χρήστης web (ιδιοκτήτης του καταλόγου του ιστότοπου· στο HestiaCP είναι ο λογαριασμός, π.χ. admin) — τότε το root-cron θα προσθέτει μόνο εγγραφές, χωρίς να αλλάζει τον ιδιοκτήτη:
stat -c %U /path/to/monitor.
sudo crontab -e), αλλιώς θα εκτελείται δύο φορές.
sudo crontab (αυτό θα ήταν άμεση κλιμάκωση σε root από οποιονδήποτε αποκτούσε πρόσβαση στη συνεδρία του panel), αλλά ένα στενό script με δύο εντολές (list/set), που αγγίζει μόνο το δικό του μπλοκ ανάμεσα στα ειδικά σχόλια. Εγκαταστήστε το μία φορά:
www-data — ελέγξτε υπό ποιον τρέχει το pool PHP-FPM του ιστότοπου (ps -o user= -C php-fpm) και βάλτε τον στη γραμμή sudoers.
public/crontab_monitor.php ανέβηκε μέσω FTP/SFTP υπό διαφορετικό χρήστη συστήματος (π.χ. root) από τα υπόλοιπα αρχεία του ιστότοπου, ο web server δεν θα μπορεί να το διαβάσει. Συγκρίνετε τον ιδιοκτήτη και τα δικαιώματα με ένα διπλανό αρχείο και προσαρμόστε τα:
Η μονάδα εντοπίζει τα εργαλεία μέσω του dpkg-query — της βάσης πακέτων APT. Αν το εργαλείο δεν εγκαταστάθηκε μέσω apt (χειροκίνητα, από snap ή από πηγαίο κώδικα), το dpkg δεν το βλέπει.
Σφάλμα 500 — ελέγξτε τα αρχεία καταγραφής της PHP, του nginx και του ίδιου του monitor:
www-data, αλλά ως λογαριασμός χρήστη (π.χ. admin — ιδιοκτήτης του καταλόγου του ιστότοπου). Όλοι οι κανόνες sudo και η συμμετοχή σε ομάδες (adm, systemd-journal) πρέπει να οριστούν σε αυτόν τον χρήστη, αλλιώς οι μονάδες θα δείξουν «Ανενεργό / 0» ενώ οι υπηρεσίες λειτουργούν. Για να βρείτε τον πραγματικό χρήστη της PHP: ps -o user= -C php-fpm | sort -u ή τον ιδιοκτήτη του καταλόγου του ιστότοπου stat -c '%U' /path/to/monitor. Στη συνέχεια σε όλες τις παρακάτω εντολές βάλτε αυτόν αντί για www-data. Η αυτόματη εγκατάσταση εντοπίζει μόνη της τον χρήστη web και ορίζει τα sudoers σε αυτόν.
Δεν εμφανίζονται δεδομένα — σχεδόν πάντα φταίνε τα μη ορισμένα δικαιώματα sudo. Ελέγξτε τη συγκεκριμένη εντολή ως χρήστης web (αντικαταστήστε το www-data με τον δικό σας). Η σημαία -n = χωρίς κωδικό, όπως στην PHP — αν ζητά κωδικό, τότε δεν υπάρχει κανόνας στο sudoers:
sudo aa-status στο τερματικό δείχνει προφίλ, αλλά η σελίδα «AppArmor» δείχνει «Ανενεργό»). Αιτία: ο χρήστης web δεν έχει δικαίωμα sudo για την εντολή αυτής της μονάδας. Ελέγξτε την από την παραπάνω λίστα: αν ζητά κωδικό — προσθέστε τη γραμμή που λείπει στο /etc/sudoers.d/monitor («Ρύθμιση sudo»). Συχνές «νέες» εντολές: /usr/sbin/aa-status (MAC), /usr/sbin/psad --Status (PSAD).
apache2ctl, ausearch, aa-status ή ss, ή ο χρήστης web δεν είναι στις ομάδες adm/systemd-journal (από εκεί διαβάζονται τα αρχεία καταγραφής fail2ban/auth/modsec και το journalctl — Falco και συμβάντα πυρήνα).
Σύμπτωμα: στον διακομιστή υπάρχουν δεδομένα (φαίνονται μέσω shell), αλλά η σελίδα δείχνει «δεν υπάρχουν δεδομένα» ή λανθασμένη κατάσταση — για παράδειγμα το AIDE γράφει «Μη αρχικοποιημένη», αν και η βάση έχει δημιουργηθεί.
Η αιτία είναι το open_basedir: πολλά panel και hosting περιορίζουν το pool του PHP-FPM στον κατάλογο του domain, γι' αυτό οι συναρτήσεις PHP file_exists(), file_get_contents(), filemtime() σε συστημικές διαδρομές (/var/lib/aide, /var/log, /proc…) μπλοκάρονται. Η μονάδα το παρακάμπτει διαβάζοντας τέτοιες διαδρομές με τυπικές συστημικές εντολές (cat, test, stat).
open_basedir. Η σωστή λύση είναι η ανάγνωση με συστημικές εντολές (έχει ήδη γίνει για το AIDE και τη Μονάδα δικτύου). Δεν χρειάζεται να επεκτείνετε το open_basedir στα /var, /proc και είναι λιγότερο ασφαλές.
Η μονάδα ελέγχει τα πιστοποιητικά συνδεόμενη απευθείας στους τομείς μέσω της θύρας 443. Αν ο τομέας δεν είναι προσβάσιμος από τον ίδιο τον διακομιστή ή η θύρα είναι κλειστή από το τείχος προστασίας, ο έλεγχος θα αποτύχει.
/etc/nginx/sites-enabled/, /etc/nginx/conf.d/) και του Apache (/etc/apache2/sites-enabled/), καθώς και τον τρέχοντα host από το HTTP_HOST.
Ο monitor συνδέεται στη MySQL με τον χρήστη από το config.php, ο οποίος έχει πρόσβαση μόνο στη δική του βάση. Η MySQL εμφανίζει στο information_schema μόνο τις βάσεις με δικαιώματα — γι' αυτό οι υπόλοιπες δεν φαίνονται.
Για να βλέπει ο monitor όλες τις ΒΔ, δώστε σε αυτόν τον χρήστη μόνο δικαίωμα ανάγνωσης (μία φορά ως root· βάλτε το όνομα χρήστη από το config.php):
sudo mysql δεν χρησιμοποιεί ο πίνακας: η λίστα των βάσεων λαμβάνεται μέσω της δικής του σύνδεσης PDO.
Η PostgreSQL απαιτεί πρόσβαση επιπέδου χρήστη postgres, την οποία ο διαδικτυακός χρήστης του πίνακα δεν διαθέτει. Το άνοιγμα ενός ευρέος sudo psql από την PHP είναι επισφαλές — αντ' αυτού ο πίνακας καλεί ένα στενό wrapper χωρίς παραμέτρους, που τυπώνει μόνο την έκδοση, το πλήθος συνδέσεων και τη λίστα βάσεων με τα μεγέθη τους. Δημιουργήστε το:
monitor-pgstat από το sudoers (βήμα 13 της χειροκίνητης εγκατάστασης) και μη δημιουργήσετε το script: η κάρτα της PostgreSQL απλώς θα παραμείνει ανενεργή.
Ο πίνακας δείχνει τι συμβαίνει· παρακάτω θα βρείτε τι να κάνετε σε τυπικές περιπτώσεις. Γενική αρχή: μην πανικοβάλλεστε, αντιπαραβάλετε με τη νόμιμη δραστηριότητα (οι ενέργειές σας, ενημερώσεις, αντίγραφα ασφαλείας) και αντιδράστε ανάλογα με τη σοβαρότητα.
ignoreip./etc, εκτός /usr/share) — πιθανή αντικατάσταση. Ελέγξτε το πακέτο: debsums PACKAGE_NAME, και αν έχετε αμφιβολίες επανεγκαταστήστε το (apt install --reinstall).127.0.0.1 ή κλείστε τη θύρα στο UFW. Είναι πραγματικό κενό ασφαλείας.certbot renew ή τις ρυθμίσεις στον πίνακα).sudo apt update && sudo apt upgrade· μετά από ενημέρωση του πυρήνα επανεκκινήστε τον διακομιστή.