Οδηγός Ασφαλούς Firewall για Server: Προστασία από DDoS και Κακόβουλα Bots

Η εγκατάσταση ενός firewall στον server είναι η διαδικασία κατά την οποία επιτρέπονται μόνο οι απαραίτητες θύρες και αποκλείεται κάθε περιττή πρόσβαση – αποτελώντας το πρώτο επίπεδο άμυνας ενάντια σε DDoS, brute force και κακόβουλη bot traffic. Ο στόχος στην πράξη είναι: να περιορίσετε το SSH, να ανοίξετε τις web υπηρεσίες με ασφάλεια, να θέσετε limits σε ύποπτες αιτήσεις, να παρακολουθείτε τα logs και – ιδανικά – να φιλτράρετε την κίνηση πριν φτάσει στον server μέσω CDN/WAF.

Ανοίγοντας έναν web server στο internet, μέσα σε λίγα λεπτά θα δείτε port scans, δοκιμές SSH, bots που ψάχνουν ευπάθειες και ψεύτικα user agents. Ειδικά σε WordPress, e-commerce, panel, API ή gaming servers, το firewall δεν είναι απλώς τεχνική επιλογή αλλά απαραίτητη προϋπόθεση για σταθερότητα. Σε αυτό τον οδηγό, θα στήσουμε βήμα-βήμα μια δομή firewall σε Linux: UFW, firewalld, nftables, Fail2ban, web application firewall και τεχνικές mitigation για DDoS – όλα σε ένα.

Ένα σημαντικό γεγονός: Ένα τοπικό firewall από μόνο του δεν μπορεί να σταματήσει μεγάλης κλίμακας DDoS επιθέσεις. Μια επίθεση των 20 Gbps ή 80 Gbps μπορεί να κορέσει το bandwidth πριν τα πακέτα φτάσουν καν στο σύστημα. Η σωστή προσέγγιση είναι πολυεπίπεδη: προστασία DDoS σε επίπεδο provider, CDN/WAF, λειτουργικό σύστημα firewall, περιορισμός ρυθμού αιτήσεων και συστηματική ανάλυση logs. Για κατάλληλη υποδομή δείτε Hostragons λύσεις διακομιστή VPS και VDS, και για ασφαλή web hosting Hostragons πακέτα web φιλοξενίας.

Ποια είναι η λειτουργία ενός Firewall στον Server;

Το server firewall φιλτράρει την δικτυακή κίνηση με βάση IP, port, πρωτόκολλο, κατάσταση σύνδεσης και χαρακτηριστικά πακέτου. Ένα απλό παράδειγμα: για το website σας πρέπει να είναι ανοιχτά μόνο τα ports 80 και 443, αλλά το port της βάσης δεδομένων (3306) δεν πρέπει να είναι προσβάσιμο από το internet. Για SSH (22), αντί να επιτρέπετε πρόσβαση σε όλους, περιορίστε μόνο στο IP του γραφείου σας.

Ο σκοπός του firewall δεν είναι να "εξαφανίσει" όλες τις επιθέσεις. Το βασικό είναι να μειώσει την επιφάνεια επίθεσης. Όσο μικρότερη η επιφάνεια, τόσο λιγότερες επιλογές έχει ο επιτιθέμενος. Σε έναν νέο Linux server, SSH, web panel, mail, database, monitoring agents και test services μπορεί να είναι όλα ανοιχτά – κάθε ένα είναι ξεχωριστός κίνδυνος. Ένα καλά ρυθμισμένο firewall δουλεύει με τη λογική: “απόρριψη ως default, άδεια μόνο όπου χρειάζεται”.

Κατανόηση DDoS και Bot Traffic

Γιατί οι DDoS επιθέσεις είναι ιδιαίτερες;

DDoS (Distributed Denial of Service) είναι επίθεση όπου πληθώρα αιτήσεων από πολλαπλές πηγές κάνουν την υπηρεσία μη διαθέσιμη. Μπορεί να κορέσει το bandwidth, να εξαντλήσει CPU/RAM ή να ενεργοποιήσει ακριβές λειτουργίες στην εφαρμογή. Ένα μικρό application server που δέχεται 50.000 HTTP requests/sec μπορεί να καταρρεύσει λόγω PHP, Node.js ή database connection pooling – ακόμη κι αν η γραμμή δεν γεμίσει.

Είναι όλα τα bots κακά;

Όχι. Googlebot, Bingbot και ορισμένα monitoring bots είναι χρήσιμα. Τα κακόβουλα bots, όμως, ψάχνουν admin panels, ανοιχτούς φακέλους, κάνουν spam στα forms, κλέβουν περιεχόμενο, εκμεταλλεύονται XML-RPC, δημιουργούν fake registrations και δοκιμάζουν logins. Στόχος στη διαχείριση bots είναι να διακρίνουμε τη συμπεριφορά: υψηλό error rate, υπερβολικά πολλές αιτήσεις σε σύντομο διάστημα, user-agent που δεν μοιάζει με browser, και ύποπτες URL patterns.

Checklist πριν την εγκατάσταση

Το μεγαλύτερο ρίσκο όταν γράφετε firewall rules σε live server είναι να κλειδωθείτε εκτός. Πριν κάνετε αλλαγές, ακολουθήστε αυτό το checklist – είναι η ασφαλής αφετηρία σε production περιβάλλον:

• Μην κλείνετε το ενεργό SSH session – ανοίξτε δεύτερο terminal για test.
• Επιβεβαιώστε ότι ο provider προσφέρει κονσόλα, VNC ή rescue mode.
• Καταγράψτε τα ενεργά ports: δείτε την έξοδο του ss -tulpn ή netstat -tulpn.
• Σημειώστε ποια ports χρησιμοποιούν web, mail, DNS, database, panel, monitoring.
• Αν έχετε IPv6, σχεδιάστε και τα αντίστοιχα firewall rules.
• Πρώτα εφαρμόστε allow rules, μετά τις deny.
• Βεβαιωθείτε ότι οι κανόνες είναι persistent – να παραμένουν μετά reboot.

Για παράδειγμα, σε έναν τυπικό server που φιλοξενεί μόνο website, ανοιχτά πρέπει να είναι τα ports 80, 443 και το περιορισμένο SSH port. Αν δεν τρέχει mail server, δεν χρειάζονται 25, 465, 587, 993. Αν η database χρησιμοποιείται μόνο εσωτερικά, ports 3306 ή 5432 πρέπει να είναι κλειστά προς το internet.

Ποιο Firewall εργαλείο να διαλέξετε;

Στο Linux υπάρχουν πολλές επιλογές – διαχειρίζονται το ίδιο core αλλά με διαφορετική ευκολία χρήσης. Για αρχάριους, το UFW είναι απλό και γρήγορο. Σε enterprise και Red Hat-based συστήματα, το firewalld είναι συνήθης επιλογή. Για advanced σενάρια, το nftables προσφέρει σύγχρονη ευελιξία. Ο παρακάτω πίνακας βοηθά στη σωστή επιλογή:

Βήμα-Βήμα Εγκατάσταση Firewall στον Server

1. Εντοπίστε τα ανοιχτά ports και υπηρεσίες

Πρώτο βήμα είναι να δείτε τι είναι ανοιχτό. Στο Linux, με ss -tulpn βλέπετε ποια services ακούν σε ποια ports. Αν το nginx ακούει σε 0.0.0.0:80 και 0.0.0.0:443, δέχεται web traffic από παντού. Αν η MariaDB ακούει σε 0.0.0.0:3306, είναι επικίνδυνο – συνήθως η database πρέπει να τρέχει σε 127.0.0.1.

Ο πρακτικός κανόνας: Κανένα service που δεν πρέπει να είναι προσβάσιμο από το internet δεν πρέπει να ακούει σε 0.0.0.0. Πρώτα διορθώστε το configuration του service, μετά κλείστε το port με firewall. Ακόμα κι αν το firewall απενεργοποιηθεί, το service δεν πρέπει να είναι ανοιχτό προς τα έξω.

2. Κάντε την default πολιτική κλειστή

Σε ασφαλή rule sets, το default incoming traffic απορρίπτεται, το outgoing επιτρέπεται ανάλογα με την ανάγκη. Έτσι, νέα services δεν ανοίγουν κατά λάθος προς το internet. Σε Ubuntu με UFW, πρώτα επιτρέπετε SSH, μετά τα ports 80/443, κατόπιν κάνετε default deny στα incoming και ενεργοποιείτε το firewall.

Ροή παραδείγματος: Άδεια για SSH στο admin IP, άνοιγμα HTTP/HTTPS, κλείσιμο περιττών ports, ενεργοποίηση. Αν ανοίξετε το firewall χωρίς να έχετε δώσει άδεια SSH, θα χάσετε την πρόσβαση – συχνό λάθος σε remote servers.

3. Περιορίστε το SSH

Το SSH είναι από τους πιο συχνούς στόχους bots. Ανοιχτό port 22 δέχεται εκατοντάδες ή χιλιάδες password tries καθημερινά. Ιδανικά, περιορίστε το SSH μόνο στο σταθερό IP σας (γραφείο ή VPN). Αν δεν έχετε σταθερό IP, χρησιμοποιήστε key-based authentication και απενεργοποιήστε τα passwords.

• Απενεργοποιήστε direct SSH login ως root.
• Χρησιμοποιήστε SSH keys αντί passwords.
• Χρησιμοποιήστε AllowUsers/AllowGroups για περιορισμό χρηστών.
• Εγκαταστήστε Fail2ban για αυτόματο block σε failed attempts.
• Αν έχετε admin panel, κάντε IP restriction και στο panel port.

Η αλλαγή port μειώνει το bot noise, αλλά πραγματική ασφάλεια είναι το IP restriction, strong authentication και log παρακολούθηση.

4. Ανοίξτε τα web ports με ασφάλεια

Στους περισσότερους web servers, χρειάζονται μόνο τα ports 80 και 443. Το 443 (HTTPS) πρέπει να είναι το κύριο port – το 80 μόνο για redirect σε HTTPS. Website χωρίς SSL χάνει σε εμπιστοσύνη και SEO. Εδώ προτείνεται Hostragons πιστοποιητικά SSL για ασφαλή εγκατάσταση HTTPS.

Ανοίγοντας web ports, προσέξτε τα real IPs. Αν χρησιμοποιείτε CDN ή reverse proxy, επιτρέψτε traffic μόνο από τα IP ranges του CDN – όχι όλο το internet. Έτσι ακόμα κι αν ο επιτιθέμενος γνωρίζει το IP του server, δεν μπορεί να προσπελάσει το web service άμεσα.

5. Κλείστε database και εσωτερικά services προς το internet

MySQL, MariaDB, PostgreSQL, Redis, Elasticsearch, MongoDB – αν είναι ανοιχτά στο internet, αποτελούν σοβαρό κίνδυνο. Προβλήματα όπως open Redis, unsecured Elasticsearch ή ανοιχτό MongoDB έχουν οδηγήσει σε μαζικά data leaks. Αυτές οι υπηρεσίες πρέπει να ακούν μόνο σε localhost ή private network.

Σε WordPress που τρέχει στον ίδιο server, η database αρκεί να ακούει σε 127.0.0.1. Αν έχετε ξεχωριστό app και DB server, επιτρέψτε μόνο το IP του app server. Ποτέ μην αφήνετε ports 3306 ή 5432 προσβάσιμα από όλο το internet – είναι συχνό target για bots.

6. Αποτρέψτε brute force με Fail2ban

Το Fail2ban παρακολουθεί logs και μπλοκάρει IPs με επαναλαμβανόμενα failed logins. Μπορεί να προστατέψει SSH, nginx, Apache, Postfix, Dovecot, login σε WordPress και panels. Ένα απλό παράδειγμα: IP που κάνει 5 fail SSH logins σε 10 λεπτά, μπλοκάρεται για μία ώρα.

Προσέξτε μην γίνετε πολύ επιθετικοί στο config – λάθος log patterns μπορεί να μπλοκάρουν κανονικούς χρήστες. Ξεκινήστε με μέτρια bantime, παρακολουθήστε τα logs και αυξήστε το strictness σταδιακά.

7. Εφαρμόστε rate limits και limits συνδέσεων

Για DDoS και bots, το OS level rate limiting βοηθά. Αν ένα IP κάνει υπερβολικά πολλές συνδέσεις/sec, εφαρμόστε limit. Στο web server, το nginx έχει limit_req και limit_conn modules, το Apache mod_evasive. Στην εφαρμογή, βάλτε limits σε login, search, cart, payment και API endpoints.

Παράδειγμα: Στο login, επιτρέψτε max 10 προσπάθειες ανά λεπτό/ανά IP. Στο search endpoint, 2-5 requests/sec. Σε API, ορίστε limits σε tokens, IP και behavior analysis. Έτσι, ο επιτιθέμενος δεν μπορεί να παρακάμψει τα limits απλώς αλλάζοντας IP.

Παράδειγμα ασφαλούς εγκατάστασης UFW

Σε Ubuntu/Debian web server, η διαδικασία: ελέγξτε τα services, δώστε άδεια SSH στο admin IP, ανοίξτε 80/443, κάντε default deny στα incoming, επαληθεύστε το status. Αν δεν μπορείτε να περιορίσετε SSH σε σταθερό IP, δώστε προσωρινή άδεια σε όλους και αργότερα περάστε σε VPN ή static IP.

Παράδειγμα: το admin IP είναι 203.0.113.10. Επιτρέψτε SSH μόνο σε αυτό. Web traffic σε 80/443 ελεύθερο για όλους. Database, Redis, panel και test ports κλειστά προς internet. Η δομή αυτή είναι ιδανική για μικρό/μεσαίο εταιρικό website. Για σωστό domain/DNS setup, δείτε Hostragons έρευνα τομέα και καταχώρηση.

firewalld και η λογική των zones

Σε AlmaLinux, Rocky Linux και RHEL, το firewalld είναι standard. Δουλεύει με zones: public για internet, trusted για private networks, drop για unwanted traffic. Σημαντικό: runtime rules εφαρμόζονται άμεσα αλλά χάνονται στο reboot, permanent rules μένουν αλλά ίσως χρειάζεται reload.

Σε enterprise περιβάλλοντα, οι service-based definitions απλοποιούν τη διαχείριση. Μπορείτε να ανοίξετε http/https στο public zone, SSH μόνο σε συγκεκριμένα source IPs. Αν έχετε management, backup και user traffic σε διαφορετικά interfaces, το zone structure βελτιώνει ασφάλεια και αναγνωσιμότητα.

CDN, WAF και DDoS προστασία σε επίπεδο provider

Το τοπικό firewall αποφασίζει αφού τα πακέτα φτάσουν στον server. Σε μεγάλα DDoS, ο στόχος είναι να φιλτραριστεί η κίνηση πριν φτάσει. CDN, WAF και provider-level DDoS protection είναι κρίσιμα. Το CDN σερβίρει static assets από edge locations, το WAF φιλτράρει malicious requests στο application layer, το provider DDoS protection απορροφά/καθαρίζει network attacks.

Ιδανικά, τα DNS records περνούν από CDN, το real server IP παραμένει κρυφό, το firewall επιτρέπει μόνο CDN IP ranges σε 80/443. Τα admin ports μένουν πίσω από VPN ή static IP. Έτσι μειώνεται η πιθανότητα direct attack και φιλτράρετε bot traffic πριν το application. Για συνδυασμό web ασφάλειας και performance δείτε Οδηγοί επιτάχυνσης και ασφάλειας ιστοσελίδας.

Ενισχύστε την εφαρμογή ενάντια σε bots

Το bot blocking δεν είναι μόνο IP ban. Τα σύγχρονα bots χρησιμοποιούν proxies, mobile networks, datacenter IPs και μεταβαλλόμενα user agents. Χρειάζεται behavioral approach: πολλαπλά logins από ένα IP, μαζικά 404 scans, wp-login.php/xmlrpc.php overload, διαφορετικό click pattern από ανθρώπους, ύποπτα headers.

• Βάλτε rate limits σε login και registration forms.
• Κλείστε/περιορίστε το XML-RPC όπου δεν χρειάζεται.
• Προστατέψτε το admin panel με διαφορετικό URL, IP restriction και MFA.
• Φιλτράρετε suspicious user-agent και referer στο WAF.
• Χρησιμοποιήστε CAPTCHA ή invisible bot checks με μέτρο.
• Στα API endpoints, εφαρμόστε keys, signatures, quotas και timestamps.

Η εμπειρία χρήστη είναι σημαντική – υπερβολικό CAPTCHA ή country block μπορεί να βλάψει πελάτες. Μετρήστε, δοκιμάστε και σκληρύνετε τα μέτρα σταδιακά.

Παρακολούθηση logs και alerts

Το να θεωρήσετε ότι η εγκατάσταση τελείωσε είναι συχνό λάθος. Το firewall είναι ζωντανό σύστημα και πρέπει να παρακολουθείται. Στο auth.log/secure βλέπετε SSH tries, στα nginx access logs ανώμαλη ένταση requests, στα error logs spikes σε 404/500, στα metrics CPU και connection count. Ένα απλό alert σώζει πολύτιμο χρόνο όταν ξεκινά επίθεση.

Ενδεικτικά thresholds: 100+ 404s από ίδιο IP σε 5 λεπτά, 20+ login attempts σε 1 λεπτό, CPU >90% για 10 λεπτά, connections x3 από το normal. Τα όρια διαφέρουν ανά site – το βασικό είναι να γνωρίζετε το κανονικό traffic profile.

Συχνά λάθη και πώς να τα αποφύγετε

• Ενεργοποίηση firewall χωρίς SSH exception: Μπορεί να χάσετε remote πρόσβαση. Δοκιμάστε πάντα με δεύτερο session.
• Ξεχνώντας το IPv6: Ένα service μπορεί να είναι κλειστό σε IPv4 αλλά ανοιχτό σε IPv6.
• Database ανοιχτή στο internet: Ports όπως 3306, 5432, 6379, 9200 είναι targets για bots.
• Χρήση CDN αλλά αφήνοντας το real IP ανοιχτό: Ο επιτιθέμενος μπορεί να παρακάμψει το CDN και να επιτεθεί απευθείας στον server.
• Αλλαγή rules χωρίς documentation: Σε emergency, δύσκολο να κατανοήσετε τι κάνει κάθε κανόνας.
• Χωρίς εναλλακτικό access plan: Μια λάθος rule χωρίς console access παρατείνει το downtime.

Παράδειγμα πρακτικής πολιτικής firewall

Για μικρό εταιρικό website: default incoming traffic κλειστό, 443 ανοιχτό για όλους, 80 μόνο για HTTPS redirect, SSH μόνο από VPN/static admin IP, database μόνο σε localhost/private network, CDN active – 80/443 μόνο από CDN IPs, Fail2ban να παρακολουθεί SSH/web login, logs να καταγράφονται σε central monitoring.

Σε μεσαίο e-shop: extra allowlist στα payment callback IPs, admin panel πίσω από VPN, API με user-based quota, WAF με SQL injection/XSS rules, country/ASN-based temporary filters. Το policy πρέπει να είναι γραπτό – έτσι σε επίθεση εφαρμόζεται το σχέδιο αντί να αυτοσχεδιάζετε, μειώνοντας downtime.

Testing: Δουλεύουν οι κανόνες πραγματικά;

Μετά το setup, κάντε testing. Port scan από εξωτερικό network, επιβεβαίωση ότι SSH δουλεύει μόνο από επιτρεπτό IP, web site προσβάσιμο μόνο μέσω HTTPS, database port κλειστό προς internet. Με CDN, δοκιμάστε direct HTTP στο real IP – πρέπει να απορρίπτεται.

Αποφύγετε aggressive scans που βλάπτουν το production. Σκοπός είναι το ασφαλές validation. Μετά από κάθε αλλαγή, κάντε export ή σημειώστε το rule set – έτσι μπορείτε να επαναφέρετε το προηγούμενο configuration αν χρειαστεί.

Σχέδιο συντήρησης και ενημερώσεων

Η ασφάλεια server δεν είναι one-off – απαιτεί τακτική συντήρηση. Νέα services ίσως χρειάζονται ports – ελέγξτε τα permissions. Αφαιρώντας services, σβήστε τα αντίστοιχα rules. Εφαρμόστε security updates εγκαίρως και ελέγξτε τα logs περιοδικά. Τουλάχιστον κάθε μήνα κάντε port scan, κάθε τρίμηνο review στο rule set.

Το backup plan είναι κομμάτι της ασφάλειας. DDoS μπορεί να κόψει την πρόσβαση, ransomware ή unauthorized access μπορεί να προκαλέσει data loss. Hosting, SSL, domain management και backup πρέπει να σχεδιάζονται μαζί. Σχετικά άρθρα: Σημεία προσοχής κατά την επιλογή ασφαλούς hosting και Πώς να γίνει η εγκατάσταση πιστοποιητικού SSL.

Συμπεράσματα

Το firewall δεν κάνει τον server "αόρατο" σε DDoS και bots, αλλά μειώνει σημαντικά την επιφάνεια επίθεσης, ελαττώνει τον κίνδυνο unauthorized access και επιτρέπει ελεγχόμενη αντίδραση σε incidents. Το καλύτερο αποτέλεσμα έρχεται με συνδυασμό: provider-level DDoS protection, CDN/WAF, strict port policy, SSH restriction, Fail2ban, rate limiting και τακτική παρακολούθηση logs.

Αν ξεκινάτε νέο project, σχεδιάστε την firewall policy από την αρχή – είναι ευκολότερο απ’ το να διορθώνετε αργότερα. Στο Hostragons, αξιολογώντας server, hosting, domain και SSL, σκεφτείτε την ασφάλεια συνολικά για πιο ανθεκτικό web περιβάλλον. Ξεκινήστε με ένα απλό checklist: κλείστε τα ανοιχτά ports, περιορίστε SSH, κάντε HTTPS υποχρεωτικό και παρακολουθείτε τα logs.

Συχνές Ερωτήσεις

Το server firewall μπορεί να σταματήσει εντελώς το DDoS;

Όχι. Το τοπικό firewall μειώνει μικρές/πρωτόκολλο-based επιθέσεις, αλλά για μεγάλα DDoS απαιτείται προστασία σε επίπεδο provider, CDN και WAF.

Ποια ports πρέπει να είναι ανοιχτά σε web server;

Συνήθως μόνο 80 και 443. Το SSH port πρέπει να επιτρέπεται μόνο στα admin IPs. Database και εσωτερικά services να είναι κλειστά προς το internet.

UFW ή firewalld;

UFW είναι πιο εύκολο σε Ubuntu/Debian. Firewalld είναι το standard σε AlmaLinux, Rocky Linux και RHEL. Για advanced/ειδικές ανάγκες, nftables.

Μπορώ να μπλοκάρω bots μόνο με IP block;

Όχι πάντα. Τα σύγχρονα bots αλλάζουν IP, χρησιμοποιούν proxies. Χρειάζονται rate limits, WAF rules, behavioral analysis, CAPTCHA και application quotas.

Ποιος είναι ο μεγαλύτερος κίνδυνος κατά τη ρύθμιση firewall;

Να χάσετε το SSH access λόγω λάθους κανόνα. Πρώτα δώστε SSH exception, δοκιμάστε με δεύτερο session και βεβαιωθείτε ότι υπάρχει console access από τον provider.