Palomuuri web-palvelimelle: DDoS- ja bottisuojauksen perusteet

Palomuurin asennus palvelimelle tarkoittaa, että jätetään auki vain välttämättömät portit ja estetään kaikki tarpeettomat yhteydet; tämä luo ensimmäisen puolustuskerroksen DDoS-hyökkäyksiä, brute force -yrityksiä ja haitallista bottiliikennettä vastaan. Käytännössä tavoitteena on rajoittaa SSH-yhteyksiä, avata web-palvelut kontrolloidusti, asettaa epäilyttävät pyynnöt rajoituksiin, seurata lokitapahtumia sekä mahdollisuuksien mukaan suodattaa liikennettä jo ennen palvelimelle saapumista esimerkiksi CDN/WAF-ratkaisuilla.

Heti kun web-palvelin avataan verkkoon, se joutuu muutamassa minuutissa porttiskannauksen, SSH-kokeilujen, haavoittuvuuksia etsivien bottien ja väärennettyjen käyttäjäagenttien kohteeksi. Erityisesti WordPress, verkkokauppa, hallintapaneeli, API tai pelipalvelinympäristöissä palomuuri ei ole vain tekninen valinta – se on jatkuvuuden kannalta välttämätön. Tässä oppaassa rakennamme askel askeleelta palomuurin Linux-palvelimelle: käymme läpi UFW:n, firewalld:n, nftablesin, Fail2banin, web-sovelluspalomuurin sekä DDoS-vaimennuksen käytännön yhdistelmän.

Tärkeä tosiasia heti alkuun: paikallinen palomuuri ei yksin pysäytä massiivista DDoS-hyökkäystä. Jos hyökkäys on 20 Gbps, 80 Gbps tai vielä suurempi, se tukkii datakeskuksen tai verkon ennen kuin paketit ehtivät palvelimen sääntöihin. Oikea lähestymistapa on kerroksellinen: palveluntarjoajan DDoS-suojaus, CDN/WAF, käyttöjärjestelmän palomuuri, sovellustason rajoitukset ja säännöllinen lokien analysointi toimivat yhdessä. Sopivaa palvelininfraa valitessa kannattaa tutustua Hostragons VPS- ja VDS-palvelinratkaisut -sivuun, ja web-sivujen turvallista hostingia varten Hostragons verkkohostingpaketit -osioon.

Mihin palvelimen palomuuri auttaa?

Palomuuri suodattaa verkkoliikennettä IP-osoitteen, portin, protokollan, yhteyden tilan ja joskus pakettien ominaisuuksien perusteella. Yksinkertainen esimerkki: verkkosivulle jätetään auki portit 80 ja 443, mutta tietokantaportti 3306 ei saa olla avoinna internetiin. SSH-yhteydelle portti 22 kannattaa avata vain omasta toimisto-IP:stä, ei kaikille.

Palomuurin tehtävä ei ole poistaa hyökkäyksiä kuin taikaiskusta, vaan pienentää hyökkäyspinta-alaa. Mitä pienempi pinta-ala, sitä vähemmän hyökkääjällä on vaihtoehtoja. Esimerkiksi uudella Linux-palvelimella voi olla SSH, hallintapaneeli, sähköposti, tietokanta, monitorointiagentti ja testipalveluja auki yhtä aikaa – kaikki tuovat oman riskinsä. Hyvin konfiguroitu palomuuri noudattaa periaatetta: "oletuksena estä, anna lupa vain tarpeelliselle".

DDoS- ja bottiliikenne: miten tunnistaa?

Miksi DDoS-hyökkäykset ovat erityisiä?

DDoS (Distributed Denial of Service) on hyökkäys, jossa valtava määrä liikennettä eri lähteistä pyrkii tekemään palvelusta käyttökelvottoman. Joskus se tukkii kaistan, joskus kuluttaa palvelimen CPU- ja RAM-resursseja, joskus taas käynnistää kalliita sovellustoimintoja. Esimerkiksi pieni sovelluspalvelin voi kaatua, jos se saa 50 000 HTTP-pyyntöä sekunnissa – vaikka kaista ei olisi täynnä, PHP-FPM, Node.js tai tietokantayhteydet eivät enää riitä.

Ovatko botit aina haitallisia?

Eivät. Googlebot, Bingbot ja jotkut seurantabotit ovat hyödyllisiä. Mutta haitalliset botit etsivät hallintapaneeleja, avoimia hakemistoja, lähettävät spamia lomakkeisiin, kopioivat sisältöä, käyttävät XML-RPC:tä väärin, luovat vääriä rekisteröintejä ja yrittävät kirjautumisia. Botteja hallittaessa ideana ei ole estää kaikkia, vaan erotella hyvästä ja pahasta. Merkittäviä signaaleja ovat korkea virheprosentti, runsaat pyynnöt lyhyessä ajassa, epäilyttävät user-agentit ja outo URL-rakenne.

Ennen asennusta: tarkistuslista

Palomuurisääntöjen kirjoittamisen suurin riski on lukittautua ulos omasta palvelimesta. Siksi on hyvä valmistautua ennen muutoksia. Tässä listassa on tuotantoympäristön turvallinen aloitus:

• Älä sulje aktiivista SSH-istuntoa; testaa muutokset toisella terminaalilla.
• Varmista, että palveluntarjoaja tarjoaa konsoli-, VNC- tai palautusyhteyden.
• Listaa avoimet portit: tarkista ss -tulpn tai netstat -tulpn tulokset.
• Kirjaa portit, joita käyttävät web, mail, DNS, tietokanta, hallintapaneeli sekä monitorointi.
• Jos käytät IPv6:ta, suunnittele myös IPv6-palomuuri.
• Ensin asetetaan säännöt, jotka sallivat liikenteen; vasta sitten estosäännöt.
• Varmista, että sääntösetti on pysyvä; se ei saa kadota palvelimen uudelleenkäynnistyksessä.

Esimerkiksi pelkkää web-sivua hostaavassa palvelimessa portit 80, 443 ja rajattu SSH ovat yleensä ainoa tarve. Jos mailia ei käytetä, portit 25, 465, 587, 993 voi sulkea. Jos tietokanta on vain paikallisessa käytössä, portit 3306 tai 5432 pidetään kiinni ulospäin.

Mikä palomuurityökalu sopii sinulle?

Linuxissa on useita työkaluja, jotka hallinnoivat samaa kernelin suodatusta eri käyttöliittymillä. UFW on helppo aloittelijalle. firewalld on suosittu Red Hat -pohjaisissa järjestelmissä. nftables tarjoaa modernin ja monipuolisen ratkaisun vaativiin tarpeisiin. Alla oleva taulukko helpottaa valintaa:

Palomuurin asennus: vaihe vaiheelta

1. Selvitä avoimet portit ja palvelut

Ensimmäinen askel on selvittää, mikä on auki. ss -tulpn näyttää, mitkä palvelut kuuntelevat millä porteilla. Jos nginx kuuntelee 0.0.0.0:80 ja 0.0.0.0:443, web-liikenne on avoinna kaikilta. Jos MariaDB kuuntelee 0.0.0.0:3306, se on riski; useimmilla sivuilla tietokanta toimii 127.0.0.1:llä.

Käytännön sääntö: palvelut, joita ei tarvitse avata internetiin, eivät saa kuunnella 0.0.0.0:lla. Palvelun konfiguraatio kannattaa korjata ensin, sitten palomuuri. Jos palomuuri menee pois päältä, palvelu ei silti ole avoin ulospäin.

2. Aseta oletuspolitiikka kiinni

Turvallisessa sääntösetissä oletuksena saapuva liikenne estetään, lähtevä sallitaan tarpeen mukaan. Näin uusi palvelu ei mene vahingossa auki nettiin. UFW:ssä Ubuntu-palvelimella: ensin annetaan lupa SSH:lle, sitten avataan portit 80 ja 443, asetetaan oletuspolitiikka deny ja aktivoidaan palomuuri.

Esimerkki: anna SSH-lupa hallinta-IP:lle, avaa HTTP/HTTPS, sulje muut portit, aktivoi palomuuri. Älä koskaan avaa palomuuria ennen SSH-lupaa – tämä on yleisin virhe etäpalvelimilla.

3. Rajoita SSH-yhteydet

SSH on yksi hyökkääjien suosikeista. Portti 22 auki koko internetille tuo tuhansia salasanayrityksiä päivässä. Paras tapa on sallia SSH vain tietyistä IP-osoitteista. Jos sinulla on kiinteä IP, avaa SSH vain toimisto- tai VPN-IP:stä. Jos ei, käytä avainpohjaista tunnistautumista ja sulje salasanakirjautuminen.

• Estä root-kirjautuminen SSH:lla.
• Käytä SSH-avainpohjaista tunnistautumista.
• Rajoita käyttäjiä AllowUsers- tai AllowGroups-säännöillä.
• Fail2ban estää automaattisesti epäonnistuneet yritykset.
• Jos käytät hallintapaneelia, rajoita myös sen portti IP:lle.

Portin vaihtaminen vähentää bottien hälyä, mutta ei yksin suojaa. Oikea suoja syntyy IP-rajoituksista, vahvasta tunnistautumisesta ja lokiseurannasta.

4. Avaa web-portit hallitusti

Useimmille web-palvelimille portit 80 ja 443 ovat välttämättömiä. Nykyisin 443 (HTTPS) on pääkanava, 80 vain HTTP->HTTPS-ohjaukseen. Ilman SSL:tä sivusto menettää käyttäjien luottamuksen ja hakukonesijoitukset. Tässä yhteydessä Hostragons SSL-sertifika on luonnollinen sisäinen linkki HTTPS-suositukseen.

Web-portteja avatessa tarkista, miten IP-liikenne kulkee. Jos käytät CDN:ää tai reverse proxyä, anna 80/443-portit auki vain CDN:n IP-väleille. Näin hyökkääjä ei pääse suoraan palvelimelle, vaikka tietäisi oikean IP:n.

5. Sulje tietokanta- ja sisäiset palvelut internetiltä

MySQL, MariaDB, PostgreSQL, Redis, Elasticsearch, MongoDB ja muut ovat riskejä, jos ne ovat avoinna nettiin. Redis ilman autentikointia, Elasticsearch ilman pääsyrajoja ja MongoDB avoimella hallintaportilla ovat aiheuttaneet datavuotoja. Palvelut kannattaa kuunnella vain localhostilta tai privaattiverkosta.

Esim. WordPressin tietokanta toimii riittävästi 127.0.0.1:llä. Jos sovellus ja tietokanta ovat eri palvelimilla, avaa portti vain sovelluspalvelimen privaatti-IP:lle. Älä jätä 3306 tai 5432 auki internetiin – botit skannaavat niitä jatkuvasti.

6. Fail2ban torjuu brute force -yritykset

Fail2ban valvoo lokitiedostoja ja estää IP:t, jotka tekevät toistuvia epäonnistuneita kirjautumisia. SSH, nginx, Apache, Postfix, Dovecot, WordPress login ja paneelipalvelut voidaan suojata jail-määrittelyillä. Esim. IP, joka epäonnistuu SSH:ssa 5 kertaa 10 minuutissa, estetään tunniksi.

Älä käytä liian aggressiivisia sääntöjä – väärin kirjoitettu lokipatterni voi estää oikeita käyttäjiä. Aloita maltillisilla arvoilla, seuraa lokit ja kiristä asteittain.

7. Rate limiting ja yhteysrajat

DDoS- ja bottiliikenteen torjuntaan auttaa yhteysrajoitus. Jos samasta IP:stä tulee liikaa uusia yhteyksiä sekunnissa, asetetaan raja. Nginxissä limit_req ja limit_conn, Apachessa mod_evasive. Sovelluksen puolella login-, haku-, ostoskori-, maksutapahtuma- ja API-pyynnöt kannattaa rajoittaa erikseen.

Esim. kirjautumissivulla 10 yritystä minuutissa/IP, haussa 2-5 pyyntöä sekunnissa/IP. API:ssa käyttäjäkohtainen token-raja, IP-raja ja käyttäytymisanalyysi – näin hyökkääjä ei voi ohittaa rajoja vain IP:tä vaihtamalla.

UFW:n turvallinen aloitus: esimerkki

Ubuntulla tai Debianilla voit aloittaa näin: tarkista palvelut, anna SSH-lupa hallinta-IP:lle, avaa portit 80/443, aseta saapuva liikenne kiinni oletuksena ja varmista UFW:n tila. Jos SSH-IP:tä ei voi rajoittaa heti, salli aluksi kaikilta ja siirry myöhemmin VPN- tai kiinteään IP:hen.

Esimerkki: 203.0.113.10 on hallinta-IP, SSH sallitaan vain sieltä, web kaikille portista 80/443, tietokanta, Redis, paneeli ja testit kiinni ulospäin. Tämä sopii monille pk-yritysten sivuille. Domain- ja DNS-puolen ohjauksessa Hostragons verkkotunnuksen tarkistus ja rekisteröinti on hyödyllinen sisäinen linkki.

firewalld ja zone-ajattelu

AlmaLinux, Rocky Linux ja RHEL käyttävät usein firewalld:ta, joka perustuu zoneihin. Public on nettiin avoin, trusted privaattiverkkoihin, drop pudottaa liikenteen hiljaa. Tärkeää on runtime vs permanent: runtime on heti voimassa, mutta katoaa restartissa; permanent on pysyvä, mutta vaatii reloadin.

firewalld:ssa palvelupohjaiset säännöt helpottavat työtä: http ja https public-zonessa, ssh vain tietyistä IP:stä. Jos hallintaverkko, varmistusverkko ja käyttäjäliikenne ovat eri rajapinnoilla, zone-rakenne tuo selkeyttä ja turvaa.

CDN, WAF ja palveluntarjoajan DDoS-suojaus

Paikallinen palomuuri toimii vasta kun paketit ovat jo palvelimella. Massiivisessa DDoS:ssa idea on suodattaa liikenne ennen palvelinta. CDN, WAF ja palveluntarjoajan DDoS-suojaus ovat siksi tärkeitä. CDN jakaa staattisen sisällön, WAF estää sovellustason hyökkäykset, tarjoaja imee tai suodattaa massiivisen liikenteen.

Parhaassa mallissa DNS ohjautuu CDN:n kautta, palvelimen oikea IP on piilossa, palomuuri sallii vain CDN:n IP-välit portille 80/443. Hallintaportit ovat auki vain VPN:llä tai kiinteällä IP:llä. Suora IP-hyökkäys on näin vaikeampi, botit pysäytetään ennen sovellusta. Web-turvallisuuteen ja suorituskykyyn liittyvissä sisällöissä verkkosivuston nopeuttaminen ja turvallisuusoppaat on hyödyllinen linkki.

Sovellustason bottisuojat

Bottien torjunta ei ole pelkkää IP-estolistaa. Modernit botit käyttävät proxyjä, mobiili- ja datakeskuksen IP:itä sekä vaihtuvia user-agenteja. Siksi tarvitaan käyttäytymispohjaista valvontaa. Lyhyessä ajassa suuri määrä kirjautumisyrityksiä, jatkuva 404-skannaus, wp-login.php/xmlrpc.php-ruuhka, outo klikkausrytmi ja epäilyttävät headerit ovat merkkejä.

• Käytä rate limitingia login- ja rekisteröintilomakkeissa.
• Sulje tai rajoita turha XML-RPC-yhteys.
• Hallintapaneeli kannattaa suojata eri URL:llä, IP-rajoituksilla ja monivaiheisella tunnistautumisella.
• Filtteröi epäilyttävät user-agentit ja refererit WAF-tasolla.
• Käytä CAPTCHAa tai näkymätöntä bottitunnistusta lomakkeissa tasapainoisesti.
• API:ssa avain, signaali, quota ja aikaleima – näin botti ei voi kiertää rajoja.

Käytettävyys on tärkeää: liian aggressiivinen CAPTCHA, estot tai väärät maa-blokit haittaavat oikeita asiakkaita. Mittaa, testaa ja kiristä asteittain.

Lokien valvonta ja hälytykset

Asennuksen päättymistä ei kannata ajatella lopullisena. Palomuuri on elävä järjestelmä ja vaatii seurantaa. auth.logissa/secure:ssa näkyvät SSH-yritykset, nginx access-logissa poikkeava pyyntömäärä, error-logissa 404/500-piikit, järjestelmämetrikoissa CPU ja yhteysmäärät – kaikki ovat tärkeitä. Yksinkertainen hälytys voi säästää minuutteja hyökkäystilanteessa.

Alkuun voit käyttää esim. seuraavia rajoja: 5 minuutissa yli 100 kpl 404-pyyntöjä/IP, 1 minuutissa yli 20 login-yritystä, CPU yli 90 % 10 minuuttia, yhteyksien määrä kolminkertainen normaalista. Rajat vaihtelevat palvelukohtaisesti – tärkeintä on tuntea oma normaali liikenne.

Yleisimmät virheet ja niiden välttäminen

• Palomuurin aktivointi ilman SSH-lupaa: Etäpalvelimelle pääsy voi katketa. Testaa aina toisella istunnolla.
• IPv6 unohtaminen: IPv4:n ollessa kiinni palvelu voi silti olla auki IPv6:lla.
• Tietokanta avoinna internetiin: Portit 3306, 5432, 6379, 9200 ovat bottien vakiokohteita.
• CDN käytössä, mutta oikea IP auki: Hyökkääjä voi ohittaa CDN:n ja iskeä suoraan palvelimelle.
• Sääntöjen muuttaminen ilman dokumentaatiota: Hätätilanteessa on vaikea tietää, mitä mikäkin sääntö tekee.
• Varmistuksen puuttuminen: Väärän säännön takia, jos konsoliyhteyttä ei ole, katkos pitkittyy.

Käytännön palomuuripolitiikan esimerkki

Pienen yrityksen web-sivulle sopiva tiivistetty politiikka: saapuva liikenne kiinni oletuksena, 443 auki kaikille, 80 vain HTTPS-ohjaukseen, SSH vain VPN:ltä/kiinteältä IP:ltä, tietokanta localhostilla/privaattiverkossa, CDN käytössä 80/443 vain CDN-IP:lle, Fail2ban valvoo SSH & login-yrityksiä, lokit lähetetään keskitettyyn valvontaan.

Verkkokaupassa lisäksi maksu callback-IP:t sallitaan, hallintapaneeli VPN:n taakse, API:lle käyttäjäkohtainen quota, WAF:lla SQL injection/XSS-säännöt, maa/ASN-pohjainen tilapäinen suodatus. Politiikka kannattaa kirjata; näin hyökkäystilanteessa ei tarvitse improvisoida, vaan noudattaa valmiita ohjeita – häiriöaika lyhenee.

Testaus: toimivatko säännöt oikeasti?

Palomuurin asennuksen jälkeen testaa: tee porttiskannaus eri verkosta, varmista että SSH toimii vain sallitulta IP:ltä, tarkista että web-sivu löytyy HTTPS:llä, varmista että tietokantaportti on kiinni ulospäin. Jos käytät CDN:ää, tee suora HTTP-pyyntö palvelimen IP:lle ja varmista että se estetään.

Älä tee liian aggressiivisia skannauksia tuotannossa – tavoitteena on turvallinen varmistus. Muista tallentaa sääntösetti joka muutoksen jälkeen. Jos jotain menee pieleen, paluu toimivaan konfiguraatioon on helpompaa.

Ylläpito ja päivitykset

Palomuurin asennus ei ole kertaluonteinen, vaan jatkuva ylläpitoprosessi. Uudet palvelut vaativat porttien tarkistuksen, vanhat palvelut poistettaessa säännöt pitää päivittää, päivitykset tulee asentaa ajoissa ja lokit tarkistaa säännöllisesti. Hyvä tapa: tee porttiskannaus vähintään kerran kuukaudessa, tarkista palomuurisäännöt kolmen kuukauden välein.

Varmuuskopiointi kuuluu tietoturvastrategiaan. DDoS voi katkaista yhteyden, mutta ransomware tai luvaton pääsy voi aiheuttaa datatappion. Turvallinen hosting, SSL, domainhallinta ja backupit kannattaa miettiä yhdessä. Tässä Huomioitavat asiat turvallista hostingia valittaessa ja Miten SSL-sertifika asennetaan? ovat luonnollisia jatkolinkkejä.

Yhteenveto

Palomuurin asennus ei tee palvelimesta täysin näkymätöntä DDoS- ja bottihyökkäyksille, mutta pienentää merkittävästi hyökkäyspinta-alaa, vähentää luvattoman pääsyn riskiä ja mahdollistaa hallitumman reagoinnin. Paras tulos syntyy, kun yhdistät palveluntarjoajan DDoS-suojauksen, CDN/WAF:n, tiukan porttipolitiikan, SSH-rajoituksen, Fail2banin, rate limitingin ja säännöllisen lokiseurannan.

Jos käynnistät uuden projektin, palomuuripolitiikan suunnittelu alussa on helpompaa kuin myöhemmin korjaaminen. Hostragonsilla voit arvioida palvelin-, hosting-, domain- ja SSL-tarpeet sekä rakentaa turvallisemman web-ympäristön. Aloita vaikka pienellä checklistillä: sulje avoimet portit, rajoita SSH, pakota HTTPS ja seuraa lokit.

Usein kysytyt kysymykset

Estääkö palomuuri DDoS-hyökkäykset kokonaan?

Ei. Paikallinen palomuuri vähentää pieniä ja protokollakohtaisia hyökkäyksiä, mutta laajoissa DDoS-hyökkäyksissä tarvitaan palveluntarjoajan DDoS-suojaus, CDN ja WAF.

Mitkä portit pitää olla auki web-palvelimella?

Tyypillisesti portit 80 ja 443 ovat auki. SSH-portti sallitaan vain hallinta-IP:ltä. Tietokanta- ja sisäisten palveluiden portit pidetään kiinni internetiin.

Käytänkö UFW:tä vai firewalld:ta?

Ubuntu/Debianilla UFW on helpoin aloittaa. AlmaLinux, Rocky Linux ja RHEL:ssa firewalld on yleinen. Edistyneisiin tarpeisiin ja erikoistapauksiin sopii nftables.

Voinko estää bottiliikenteen pelkällä IP-estolla?

Yleensä ei. Modernit botit vaihtavat IP:t ja käyttävät proxyjä. IP-eston lisäksi tarvitaan rate limitingia, WAF-sääntöjä, käyttäytymisanalyysiä, CAPTCHAa ja sovelluskohtaisia rajoja.

Mikä on suurin riski palomuuria asentaessa?

Väärä sääntö voi katkaista SSH-yhteyden. Siksi SSH-lupa pitää asettaa ensin, testata toisella istunnolla ja varmistaa konsoliyhteys palveluntarjoajalta.