Önkéntest keresek: Debian 9 frissítéshez VPS-en, extrákkal

Debian GNU/Linux

Na helló!

Van egy VPS-en futó Debian 9-em, ami elég kritikus feladatokat lát el. Tomact8-ban fut egy GeoServer, ami egy állami cég felé szolgáltat adatokat.

Szívem szerint nem nyúlnék hozzá, mert teszi a dolgát frankón, de sajnos folyamatos támadás alatt van, ezért b.ssza a szolgáltató csőrét. Volt olyan is, hogy annyi kérés érkezett a gépre, hogy lekapcsolták a hálózatról. Most kb. percenként van egy bejelentkezési kísérlet:

Jan 27 16:00:48 isrv sshd[17950]: Connection closed by 92.118.39.56 port 52990 [preauth]
Jan 27 16:01:01 isrv CRON[17989]: pam_unix(cron:session): session opened for user tomcat8 by (uid=0)
Jan 27 16:01:01 isrv CRON[17987]: pam_unix(cron:session): session opened for user tomcat8 by (uid=0)
Jan 27 16:01:01 isrv CRON[17988]: pam_unix(cron:session): session opened for user tomcat8 by (uid=0)
Jan 27 16:01:01 isrv CRON[17987]: pam_unix(cron:session): session closed for user tomcat8
Jan 27 16:01:01 isrv CRON[17988]: pam_unix(cron:session): session closed for user tomcat8
Jan 27 16:01:01 isrv CRON[17989]: pam_unix(cron:session): session closed for user tomcat8
Jan 27 16:01:05 isrv sshd[17999]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=38.248.14.48  user=root
Jan 27 16:01:07 isrv sshd[17999]: Failed password for root from 38.248.14.48 port 48476 ssh2
Jan 27 16:01:07 isrv sshd[17999]: Connection closed by 38.248.14.48 port 48476 [preauth]
Jan 27 16:02:01 isrv CRON[18110]: pam_unix(cron:session): session opened for user tomcat8 by (uid=0)
Jan 27 16:02:01 isrv CRON[18112]: pam_unix(cron:session): session opened for user tomcat8 by (uid=0)
Jan 27 16:02:01 isrv CRON[18111]: pam_unix(cron:session): session opened for user tomcat8 by (uid=0)
Jan 27 16:02:01 isrv CRON[18110]: pam_unix(cron:session): session closed for user tomcat8
Jan 27 16:02:01 isrv CRON[18111]: pam_unix(cron:session): session closed for user tomcat8
Jan 27 16:02:01 isrv CRON[18112]: pam_unix(cron:session): session closed for user tomcat8
Jan 27 16:02:42 isrv sshd[18327]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=38.248.14.48  user=root
Jan 27 16:02:44 isrv sshd[18327]: Failed password for root from 38.248.14.48 port 35984 ssh2
Jan 27 16:02:44 isrv sshd[18332]: Invalid user vodafone from 93.152.230.160 port 16439
Jan 27 16:02:44 isrv sshd[18332]: input_userauth_request: invalid user vodafone [preauth]
Jan 27 16:02:44 isrv sshd[18332]: pam_unix(sshd:auth): check pass; user unknown
Jan 27 16:02:44 isrv sshd[18332]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=93.152.230.160

A telepítést, beállítást még én csináltam sok évvel ezelőtt, viszont a frissítésnek nem állnék neki, erősen tartok tőle, hogy megborulna az egész tomcatestől, geoserverestől. 

Nem tudom, hogy egy frissebb Debian valóban megoldaná-e a problémát, de a szolgáltató ezt javasolta.

A lényeg, hogy úgy kellene megoldani, hogy a frissítés után is minden ugyanúgy menjen, hogy előtte, a geoserver ugyanúgy, ugyanazokat az adatokat szolgáltassa, mint eddig. Pár óra kiesés belefér.

  • az IP nem módosítható marad
  • nem ragaszkodom a Debian 9-hez, pont az a lényeg, hogy valami újabb, karbantarthatóbb, hosszabb távon frissített legyen
  • valószínűnek tartom, hogy ezzel együtt a tomcat-et, java-t, geoservert, meg mindent frissíteni kellene
# neofetch
       _,met$$$$$gg.                                                                               r
    ,g$$$$$$$$$$$$$$$P.       ---------
  ,g$$P"     """Y$$.".        OS: Debian GNU/Linux 9.13 (stretch) x86_64
 ,$$P'              `$$$.     Model: KVM RHEL 7.6.0 PC (i440FX + PIIX, 1996)
',$$P       ,ggs.     `$$b:   Kernel: 4.9.0-19-amd64
`d$$'     ,$P"'   .    $$$    Uptime: 9 hours, 28 minutes
 $$P      d$'     ,    $$P    Packages: 528
 $$:      $$.   -    ,d$$'    Shell: bash 4.4.12
 $$;      Y$b._   _,d$P'      Terminal: mc
 Y$$.    `.`"Y$$$$P"'         CPU: QEMU Virtual version 2.5+ (2) @ 2.8GHz
 `$$b      "-.__              GPU: Cirrus Logic GD 5446
  `Y$$                        Memory: 3247MB / 3955MB
   `Y$$.                      ​
     `$$b.                    ████████████████████████
       `Y$$b.                 ​
          `"Y$b._
              `"""
# java -cp catalina.jar org.apache.catalina.util.ServerInfo
Server version: Apache Tomcat/8.5.54 (Debian)
Server built:   Sep 22 2021 19:46:16 UTC
Server number:  8.5.54.0
OS Name:        Linux
OS Version:     4.9.0-19-amd64
Architecture:   amd64
JVM Version:    1.8.0_332-8u332-ga-1~deb9u1-b09
JVM Vendor:     Oracle Corporation

GeoServer Version
2.18.2
Git Revision
4f27a36677fe1c75d115bde8365a8f2e2dfe5efa
Build Date
18-Jan-2021 15:47
GeoTools Version
24.2 (rev c181af0627b27f4410982a361063dbddd1f61f7d)
GeoWebCache Version
1.18.2 (rev 1.18.x/5aa98cd64d29d06df7970e609ae2435fe3369c35)

Szóval olyan önkénest keresek, aki kellően profi ezekben a dolgokban, és szívesen vállalná a feladatot. Nem kérem ingyen.

Ha nem tudod mi az a debian, tomcat, geoserver, akkor ez nem a te feladatod.

Árajánlatokat privátban kérek.

  • 2135 megtekintés

( ggallo | 2026. 01. 27., k – 16:33 )

Ezt egy tesztkörnyezetben kell elsőre kipróbálni, mert koránt sem biztos, hogy triviális lesz a régi tomcat-et futtatni újabb Debian-on, az applikáció meg nem biztos (valószínű nem), hogy működik újabb tomcat környezetben.

Egyébként (szerintem) a támadások számát nem fogja csökkenteni a frissítés. Azt kell megnézni inkább, hogy azoknak a portoknak tényleg nyitva kell-e lenniük, amin keresztül a próbálkozások érkeznek.
SSH esetén pedig beállítod,hogy csak kulcsos hitelesítést fogadjon el (jelszavasat senkitől sem), a root pedig semmi módon ne tudjon SSH-n hitelesíteni (kulccsal se), és máris drasztikusan lecsökkentetted a sikeres támadás esélyét ezen a porton.

A másik meg az, hogy minden gépre ami a világon publikus címen fut, folyamatosan megy minden nyitott portra a próbálkozás, ez azért nem egyedi eset...

Pontosan ezek az aggályok merültek fel bennem is. Nincs se időm, se kapacitásom, se kellő szakértelmem hozzá, így valószínűleg csak elb.sznám. 

Úgy gondolom kellene egy mentés, amit vissza lehet tölteni ha valami mégsem sikerülne.

Na mindus, most felraktam a fail2ban-t (nem röhög, ez sem volt).

[Falu.Me]==>[-][□][X]

Gondolom a szolgáltató csak látja, hogy EOL státuszú verziók, ezért reflexből adta a frissítés választ.

 

Tomcat 8, ha jól tudom még JEE7. Önmagában nem lehet feljebb lépni az alkalmazás (geoserver) frissítése nélkül, ami ezek alapján szintén öreg. Nem írta a kérdező a geoserver verzióját, de gyanús, hogy az is ősöreg, így valószínűleg nem triviális az adatok migrálása. (Ide kellene valaki, aki jobban ismeri azt, én csak ugatom a geoservert.)

 

Én első körben megpróbálnám a meta adatok szivárgását csökkenteni, illetve a próbálkozáshoz használt szolgáltatási kéréseket (ssh login) lassítani. Ez utóbbit már valószínűleg megtetted az f2b-vel. Még állítgasd be, hogy a ssh és a tomcat ne hirdesse a verziószámokat és az ssh-t dobd át egy másik porta  a jelenlegiről (tűnjön úgy a támadó trekkerén, hogy érdemi változás történt). Ha szerencséd van 1-2 hét alatt ez csökkentheti a próbálkozások számát (kevésbé tűnsz zsíros célpontnak).

 

Meg természetesen ssh-n tiltsd teljesen a jelszó alapú belépést. (Bár ezt írta más is. Illetve gyakorlatban én azt látom, hogy nem nagyon ellenőrzik a botok a visszatérési hibákat, sokszor ész nélkül ütik tovább szótárral a csak cert alapú bejelentkezést lehetővé tevő gépeket is.)

 

ED: Természetesen hosszú távon meg kell oldani a verzió váltást, de az távolról sem lesz triviális (tomcat verzió ugrás).

Zavard össze a világot: mosolyogj hétfőn.

( gabrielakos v | 2026. 01. 27., k – 16:56 )

define "minden ugyanúgy".

mert ha pl ip-t lehet módosítani akkor biztos h felraknám egy új vps-re és ha leteszteltem és minden frankó akkor átírnám a dns-t, vagy átirányítanám a revproxy-t, vagy ahogy éppen meg van csinálva.

ha muszáj debian 9-en maradni (bár nem hiszem mert a tomcat 8 elfut újabbon is) akkor dockerbe raknám.

a nagyobb támadási felület amúgy a tomcat 8 és nem a debian 9.

tomcat 8 frissítését meg vagy elbírja az alatta futó app vagy nem, de ez fejlesztői/tesztelői feladat nem ops.

( Dolphy | 2026. 01. 27., k – 17:15 )

Hasonlo projektet csinalok Debian 6-tal. 

Nem probaljuk meg migralni a PHP 5.3-es weboldalakat, hanem futtatunk egy Debian 6-ot Dockerben az abban levo LAMP stack-kel egyutt. 

Ubuntu Server 24.04

Ez egy nagyon jo kerdes, meg nincs kesz a cucc, eppen dolgozunk rajta, szoval sok a nyitott dolog.

Egyelore ez jarhatonak tunik, igy egy az egyben at lehet hozni az oldalakat, ugyanaz az Apache, ugyanaz a MySQL, PMA, stb. Bar valoszinuleg igy az attack surface is nagyobb, viszont mivel ezek intranet oldalak, lesz VPN vagy IP-re szures. A "regi" Apache nincs kilogatva a netre, TLS-sel csinal reverse proxy-t az "uj" Apache.

( YleGreg | 2026. 01. 27., k – 17:42 )

Kell, hogy az SSH a szabvány porton figyeljen? Mert ha nem, akkor rakd át egy random portra és máris jobb a helyzet. Esetleg port knocking, hogy ne derítsék fel az új portot.

Ha az upgrade rizikója magas, akkor úgy érdemes csinálni, hogy mellé raksz egy másik gépet, (opcionális másik hálózaton, hogy az élessel megegyező IP címe lehessen) majd az új gépen beállítasz mindent, és addig reszeled, amíg jó nem lesz. Aztán csere, és a külvilág már csak az olyan apróságokból fogja észrevenni a cserét, mint az SSH host key változás (ha be nem rakod a régit, persze).

De én előtte elbújtatnám azt a nyavalyás SSH -t, kivéve ha üzemszerűen használnia kell egy olyan kliensnek, aminek nem tudod megmondani, hogy mostantól a hol keresse nálad az sshd -t.

Form follows function.

SSH-t random portra es rate limitelni a firewall-on.

A random port nem feltétlen nyerő ötlet. Magaddal kibabrálsz, mert dokumentálni kell, hogy az adott rendszeren ma épp melyik az SSH portja, a túloldalt viszont csak minimálisan lassítja. Elég egy elosztott portscan és tadaaam.

A security fixek telepitese automatikus legyen es menjen rola e-mail.

A security fixek automata telepítése előzetes tesztelés nélkül elég bátor. Meg ugye vannak olyan fixek, aminél erősen ajánlott a service újraindítása vagy akár egy reboot is.

En szeretem, hogy nincs telefosva a log a rengeteg probalkozassal a 22-es porton. Osszesen van 3-4 szerverem, meg tudom jegyezni hogy melyikre mit allitottam be, amugy pedig ott az .ssh/config

A security fixek automata telepítése előzetes tesztelés nélkül elég bátor. Meg ugye vannak olyan fixek, aminél erősen ajánlott a service újraindítása vagy akár egy reboot is.

Soha nem volt meg ebbol bajom Ubuntu Server 16.x+ ota, pedig volt mar par update. Az erintett service-ek is indulnak ujra maguktol automatikusan, ha frissult a csomagjuk. Reboot is megy valamikor ejjel ha volt kernel frissites. Most igy hirtelen nem is tudom, hogy mit-hogyan-hol tudnek elozetesen tesztelni, ha kijon pl. egy uj openssh csomag.

Főleg amikor a security szkennerek (censys, shodan, threatbook, etc) a barátaink és egy api hivásból kiderül, hogy hol figyel az ssh. :)

Nálunk be van egy ipről engedve az ssh, az összes többi megy egy dropbear (always fail) honeypotnak és az összes login attempt szépen megy az abuseipdb-re ajcsiba kap egy óra kitiltást, nekem pont az a bajom, hogy nem próbálják elegen (naponta max egy két reportot szül, van olyan nap amikor egyet sem)

( NevemTeve | 2026. 01. 27., k – 18:33 )

Nyilván én vagyok figyelmetlen, de nem hiszem, hogy a tomcat verzió miatt jönnek a root-próbálkozások ssh-n.

A Tomcat8 nem.fog az OS-verzióval összeakadni, csak legyen hozzá jó kis OpenJdk8-latest, és mendegél.

( denton | 2026. 01. 27., k – 20:17 )

fail2ban ezt tuti simán megoldaná, a fenti logban kapásból 2x is szerepel ugyanaz az ip.

ssh más portra is sokat tud segíteni.

Én ssh-t már nem szoktam kirakni a netre, hanem openvpn szerveren keresztül lehet csak elérni a gépeket belső hálózatról.

Én nagyon régi 10-15 éves Fedora gépen futó 5.2-es és 5.3-as php-s rendszereket dockerizáltam. Nem 2 perc volt, főleg mert az 5.2-t forrásból kellett összerakni.

Csak a szoftveres részeket tettem dockerbe, a linux környezet meg mehetett frissre. Ehhez viszont jól kell ismerni a szoftvert is. Anélkül ilyen módosításokat el se szabad kezdeni.

Ha kritikus rendszerről van szó, akkor nem szabadna spórolni a szakértelmen mert csak szopó lesz belőle. Főleg ha önkénteseket keresel akik felelősségvállalás nélkül állnak neki bárminek is.

Nem azt gondolnám, hogy elvi hiba van bármelyikben, inkább az implementációtól félnék.

Nem nézegetem napi szinten az exploitokat. Viszont az openSSH az openBSD-ből jön, ahol NAGYON odafigyelnek a security-ra, és a legtöbb linux rendszeren eleve be is van kapcsolva. Azt gondolom hogy ekkora install base ad egyfajta bizalmat.

Ezzen szemben az openVPN köztudottan egy spagetti, és több kritikus sebezhetőséget is felfedeztek már benne.

Ettől függetlenül használom én is.

( denton | 2026. 01. 27., k – 20:18 )

Jah és ssh csak kulccsal kéne menjen, nem jelszóval.

( kassaiviktor | 2026. 01. 27., k – 23:12 )

sokan írják, hogy 22-esről más portra tegyük az ssh-t. hát ez security through obscurity. hamis biztonságérzetet ad.

jó megoldás a jelszavas belépés tiltása, jó fail2ban szabályok, esetleg vpn mögé tenni

4 és fél éve csak vim-et használok. elsősorban azért, mert még nem jöttem rá, hogy kell kilépni belőle.

Senki nem mondta, hogy önmagában elég más portra rakni. Azonban segít, mert csökkenti a próbálkozások számát. Alapból port knocking -ot állítanék be, az sem jelenti azt, hogy mögötte lehet root belépés toor jelszóval, de azért mégis nyugodtabban alszol, ha tudod, hogy már az ajtó is el van rejtve.

Form follows function.

semmilyen biztonságérzetet nem ad, nem arra való. 
egyszerűen csak csökkenti a feleslegesen próbálkozók miatt előálló logfile méretét.

a vpn mögé tétel valóban jobb megoldás.

én pl. hetznernél a non-standard ssh portot is firewall mögé tettem és ha hozzá szeretnék férni akkor először ki kell kapcsolnom a hetzner által elérakott firewallt

( Sanya v | 2026. 01. 28., sze – 01:59 )

failtoban nem játszik? nálam 2 próba 2 perc alatt bannolja az illetőt örökre. 

Nem baromság, mert pár tiltás után feladják a támadást.

Ha belépni próbálnak, akkor egy jó védelem, mert nincs értelme olyan rendszert toszogatni ami úgyis tilt pár alkalom után. Nem éri meg.

Ha ddosolni akarnák, akkor mondhatnánk, hogy ip tiltva és "van másik", de valójában ott is jó védelem, mert túl gyakran kellene ip címet váltania, nem éri meg. Ha meg egyszerre x darab ip-vel próbálkozik, akkor egyszerre lesz kitiltva mind és kész.

Ergó, a fail2ban teljesen jó.

Szerintem soha nem is léteztek ilyen támadásik fix ip címről, hisz emberöltő óta lehet tűzfallal tiltani egy fix ip-t.

szerintem arra az esetre gondolt, ha a internet szolgaltatodnal levo masik elofizeto feltort geperol probalkozik, te kitiltod, aztan egyszer egyik ip valtas soran megkapod te ugyanazt azt ip, es nem tudsz belepni. 

de ha jol emlekszem a mobilnetnel is kozos ipket hasznalnak, ott is konnyu kitiltani magad. 

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Nem szokás fail2ban-nál örökre tiltani. Ha valaki gépe zombisodott, akkor meg is érdemli.

Annak az esélye, hogy pont én fogom azt az ip-t megkapni pont abban a pillanatban amikor el akarom érni a szerveremet, olyan csekély, olyan minimális, hogy nem kell számolni vele.

Tegyük hozzá, hogy ezek a támadások 99%-ban nem ugyanabból az országbóé fognak érkezni ahol hosztolod a szervert, hanem megfoghatatlan országokból, Kína, Oroszország, India, stb.

Tehát kár aggódni.

Pedig véd. Kitiltódnak az ip-k és leáll a támadás és nem is próbálkoznak újra.

Ugyan nem konkrét ddos, hanem terhelős bot toszogatás ellen használtam. Valszeg AI tanításra csesztetnek, emiatt gyakran behalt meg belassult az oldal adatbázis meg egyebek terhelése miatt. Utána rendbejött, mivel a botok feladták, vagy elosztották a terhelést.

A cél-t definiálni kell amúgy. Ha az a cél, hogy mondjuk fél percre sikerüljön "kitömni a vonalat", akkor igen elérte. De ha a cél az, hogy órákra, napokra lehalljon a szolgáltatás, akkor nem, mert gyakorlatilag hamar kinullázódnak a támadó ip-k.

Van ddos védelem sok szolgáltatónál is, nyilván nem fail2ban -al, de gyanírom, hogy ott is hasonló a megoldás, azaz nem előre kitilt minden ip-t (max esetleg valami blacklist alapján orosz, kínai cuccokat), hanem ha beindul a támadás, akkor felismeri a mintát és védekezik.

Az ilyen támadók esetében 99%-ban működik az, hogy ha tapasztalják az aktív védelmet, akkor leállnak és nem is próbálkoznak.

Van az az eset amikor minden erőt bevetve jön a háború ennek ellenére is, de ahhoz itt mind kicsik vagyunk, hogy érintsen minket.

Bocs, Franko stílusában írok picit: Könyörgöm, a faszságot ne terjesszük már! Erősen félreérthető egy laikus számára, amiket írsz.

Mit csinál a fail2ban és rokonai?
Ha egy adott IP címről elegendően sok nem kívánt forgalom (mintaillesztés) jön L7 szinten, akkor azt képes L3 szinten blokkolni. Ennél nem tud többet a fail2ban és társai.
Eredmény: Képes hatékonyan csökkenteni a logfájlok méretét tűzfal, sőt, alkalmazás log szinten is. Így meg lehet takarítani CPU-t, memóriát, lemezterületet. A mentés mérete és időigénye is csökkenhet a kisebb tárterület miatt.
Ha a mintaillesztés esélytelen, akkor a fail2ban és társai nem segítenek semmit. Egy jó DDOS-nál el lehet érni, hogy nehéz / lehetetlen a valódi forgalmat elkülöníteni a botoktól, túlterhelőktől.
Geoip alapján is lehet blokkolni. De azt a sima L3 tűzfalak is tudják.

Mit nem tud a fail2ban?

  • Nem véd, ha egy adott IP címről nem éri el a limitet a nem kívánt forgalom. Pl: 2 kérés / nap. Sima DOS esete.
  • Túl sok IP-ről jön a nem kívánt forgalom, így per IP alapon nem éri el a küszöböt. Ez a klasszikus DDOS esete.
  • Ha olyan nem kívánt forgalom jut el a szerveredre, amire még nincs tiltó szabályod, akkor mire megírod a szabályt, a támadás már véget is ért.
  • Kitömik a vonalat és a csomagok már el se tudnak jutni a szerveredig. Rosszabb esetben a szolgáltatód vonalait is kitömik. Ez is DOS / DDOS esetén lép fel.
  • Nem IDS / IPS / WAF. Nem tud hálózati analízist végezni.

mert gyakorlatilag hamar kinullázódnak a támadó ip-k.

Fogd meg a söröm! 🤣 Ha kellően sok IP-ről jön az áldás (legalább 50-100e IP cím), akkor nem nullázódnak ki azok olyan gyorsan.
Van, hogy nem is a támadó tömi ki a vonalat, hanem a támadott szerver válaszüzenetei. Ha a támadó 100 byte-jára a támadott szerver 1 megabájtot ad vissza és leír a logba mondjuk n*1 kbyte-ot, akkor nagyon kevés kliens leülteti támadott szerver KIMENŐ SÁVSZÉLESSÉGÉT. n= az érintett szerverek száma, 3 rétegű architektúrában adatbázis-, alkalmazás- és webszerver.

hanem ha beindul a támadás

Ez se igaz így. Lehet olyan támadást csinálni, hogy minimális csomagszám mellett, nem is túl sok kliensről tönkre vágják a szolgáltatásod - például elcrasheltetik az alkalmazásod. Igen, ehhez jó adag mázli is kell támadó oldalról. Voltak ilyen CVE-k is.

Az ilyen támadók esetében 99%-ban működik az, hogy ha tapasztalják az aktív védelmet, akkor leállnak és nem is próbálkoznak.

Tévhit. Ha a Tier 1-ben ül a szervered és lehal emiatt a Tier 1, akkor a támadás nem szűnik meg, ha a magasabb Tier szintű szolgáltatók nem avatkoznak közbe. Még a BGP hirdetés se megy körbe, ha nem tud átmenni a Tier 1 és 2 között.
A támadások sokszor automatizáltan történnek. Ne úgy képzeld el, hogy VérPistike ül a gép előtt és nyomogatja a gombokat.

Van az az eset amikor minden erőt bevetve jön a háború ennek ellenére is, de ahhoz itt mind kicsik vagyunk, hogy érintsen minket.

Írhatom, mert már nem sért NDA-t: volt dolgom az Anonymous csoporttal kb. 15 évvel ezelőtt. Egy kicsi, de országosan ismert és olvasott weboldalt támadtak. Elég gyorsan (pár óra) alatt kezelve lett a probléma az NNI (mostani rövidítése KR NNI) által.
Szóval a kicsiket is támadják. Nem véletlenül lett piaca a Cloudflare-nek is.

Amúgy meg 2026. van. A szerver hardening manapság már alapkövetelmény. Ennek része a fail2ban is, csak nem egyedüli része.

Szépen összefoglaltad helyettem is. Köszi.

Amúgy meg 2026. van. A szerver hardening manapság már alapkövetelmény. Ennek része a fail2ban is, csak nem egyedüli része.

Szoktam emlegetni, hogy én szeretem a sajtokat, különösen a svájci sajtokat. És olyankor a kollegák már tudják, hogy a "swiss cheese model"-re gondolok.

A fail2ban-t ssh-ra használni alapvetően "szegénység" szerintem.

Ha a publikusan kiajánlott (webes) szolgáltatásodat próbálják meg "törögetni" na arra jó lehet, de akkor is inkább tüneti kezelés mint a probléma valódi megoldása.

A ddos támadásról meg az elleni védekezésről láthatóan fogalmad sincs. A sima dos-ról se nagyon.

( petik | 2026. 01. 28., sze – 09:16 )

Ha egy állami cég felé szolgáltatsz adatokat, és nem az egész világ felé, akkor vagy állíts be egy tűzfalszabályt, hogy csak a cég publikus IP-jéről (subnetjéből)  lehessen elérni, ne az egész világból, ha esetleg megoldható, akkor pedig építsetek ki egy IPSec-et az ő és a Te tűzfalad közé, és a forgalmat csak tunnelen belülről fogadd el! Így nem kell verziózni, meg szívni alkalmazás oldalon, illetve az IPSec-kel az is megoldható, ha esetleg az ő IP címük dinamikus (azt írtad, hogy a Tied fix). 
De lehet, hogy félreértem a problémát. 

( GaLbi | 2026. 01. 28., sze – 12:13 )

Szerintem ebben az esetben nem járható út a frissítés, mert nagyon nehéz lesz lekezelni a függőségeket. Ilyen esetben én mindig azt javaslom, hogy fel kell húzni egy teszt környezetet a legfrisseb Debian/Ubuntu/stb. rendszerrel és azon kell tesztelni az applikációt és ha szükséges akkor javítani a szolgáltatás alatt futó alkalmazást. Ha működik már minden az új rendszeren, akkor lehet gondolkodni azon, hogy hogyan történjen meg a váltás a régi és az új rendszer között. Igen, ez a leglassúbb és (leg)drágább megoldás, de így el lehet érni azt, hogy minden up-to-date legyen és innen kezdve rendszeresen lehet (kell) frissíteni. (és ez az a folyamat, amit senki nem akar megfinanszírozni, mert mindenki úgy gondolkodik, hogyha elkészült egy alkalmazás, az örök időre úgy kell működjön.)
Sok helyen egyébként azt csinálják, hogy az alap operációs rendszer feltelepítik, és utána a Tomcat-t nem a disztribúcióban található csomagból telepítik fel, hanem kézzel felrakják más forrásból. Így külön van választva az, hogy mit frissítesz és mit nem, mehet a disztribúció folyamatos frissítése, de nem fog változni a Tomcat alatta.

Mint ahogy előttem sokan leírták, védd a saját rendszeredet és a szolgáltatásokat, és korlátozd, hogy honnan ki tudja elérni. 

Nagyon nagyon egyet értek és én is ebbe az irányba mennék, mert túl sok lehetne a buktató! Ráadásul így több lehetőséget is ki lehet próbálni az upgrade-re!  A posztoló pedig sokat tanulhatna belőle! 

Én az IP-re terveznék egy load balancert, amivel lehetőség biztosítható mondjuk a "béta" tesztelésre (az új verziót upgrade után) és az esetleges hibák még javíthatóak úgy, hogy az eredeti rendszer ott van és teszi a dolgát.

A Loadbalancer elé mindképp tennék tűzfalat (de inkább az IDS/IPS funkció lenne a lényeg),  ahol akár megelőző jelleggel lehetne forgalmat analizálni és a szervert védeni a sok illegális kéréstől, ha a fail2ban már kevés. Így maga a szolgáltatás is védettebb lenne, mert a gyanús kérések el se jutnának a szerverig.

Sajnos a Tomcat alatt futtatott alkalmazást nem ismerem, de én szeretek ilyen dolgokkal foglalkozni. Csak ennek az ára más dimenzió, mint a két sör mondjuk 😁

Szóval a frissítés mellett az alábbi dolgokon gondolkodnék még el (ha már az ember úgyis neki fog esni és akkor már igyekezzen jól csinálni) :

  • alkalmazás körüli infrastruktúra optimalizálás ideértve akár az alatta lévő vas (vagy VPS) cseréjétől a fenti tűzfal és terheléselosztó beiktatásáig.
  • os-tomcat-alkalmazás függőségek. Meg kell nézni annak lehetőségét,  hogy lehet-e a régi verzióról több lépcsőben frissíteni mindent vagy csak egy lépésben lehet migrálni, ami rengeteg plusz idő és munka az előre nem dokumentált lépések miatt. A Dockerben futtatás sztem. csak elfedi a valódi problémát és csak a valódi megoldás elodázására jó egy ideig.
  • skálázhatóságot beletervezni, még akkor is ha most ez nem valós igény. 

Remélem nem gondolom túl a dolgot és sikerült pár hasznos dolgot is leírni. Mint írtam szeretem az ilyen jellegű kihívásokat, és szívesen segítek, ha van megfelelő ellentételezés. 

( gemnon v | 2026. 01. 28., sze – 13:12 )

A szolgáltatót miért zavarná, hogy folyamatosan támadás alatt van? Az ember azt gondolná, hogy csak az zavarja, ha folyamatosan támad. :) (Magyarországon leginkább az sem...)

( chx | 2026. 01. 28., sze – 20:19 )

Amúgy a TC8 publikusan elérhető a netről? Van előtte esetleg revproxy, ilyesmi? (Az EOL miatt kérdem, csak érdekel.)

echo crash > /dev/kmem

( lmarton | 2026. 01. 28., sze – 22:30 )

Opcio 1:

Indits egy masik friss VPS-t statikus IP cimmel.  Annak az elereset ha mindekeppen kell tedd random portra, zart le csak egy IP cimre, tillsd a passord es root auth-ot, vedd meg ahogy tudod. Allits be egy wireguard-servert rajta - nem default porton. Az alap megvedendo gepen pakolj fel egy wireguard kliens peer-t ami az elozo VPS-re kapcsolodik. Mindket gepnek lesz egy wireguard IP-ja. egymas kozott tudnak mukodni. Ha az uj VPS-rol at tudsz urgani a wireguard csatornan a megvedendore lodd ki az SSh-t rajta a publikus IP-rol. A gepen csak az egyetelen allami IP-rol erkezo IP-rol forgalom kerul elfogadasra a tomcat portra. A gep kiefel kezdemenyez ismert cimre wireguard-ot. 

Opcio 2:
Tegy ra tailscale vagy valami mas 0trust dolgot...

Opcio 3. A gepen csak Wireguard cliensel lehet bemenni veletlen porton rendszeresen frissitett kulcsokkal. Ha be akarsz lepni elobb kiepitesz egy wireguard session-t a gepre.

Bonus:
  Mentsd el a tomcat cuccot. Tegyel fel valami ujabb OS-t. Vedd meg rendesen - Csak VPN, tailscale stb kacsolat - nincs ssh rajta. Indits a gepen egy kontenerbe egy debian 9-re huzott tomcat-et - ha kell epits ujra egy hasonlo docker-imaget debian 9 alapra+ugyanaz a tomcat... Indits ez az egeszet rootless podman-bol. A tomcat adatoktol keszits rendszeresen menteseket az alap OS-bol a docker container-bol elerhetetlen helyre.

Sok otletem van meg :) 

( derWRK | 2026. 01. 30., p – 23:54 )

Végülis az most nem derült ki, hogy ki használja az ssh-t és honnan? Már egy ipset -> csak Mo. is sokat javítana akár. Azon lesz mondjuk a legnehezebb változtatni, hogy "folyamatos támadás alatt van" ( mint mindenki ), és ez zavarja a szolgáltatót... a legtöbb ilyen dictionary attacker már olyan headless botnet, ami nemigen áll le, hiába kap connection refusedot, szóval a csomagszámláló ugyanúgy pörög majd a szolgáltató switchén... a teszt upgradet meg könnyű megoldani, ki lehet indulni a legutóbbi full rendszermentésből, ami ugye van?

( kallaics | 2026. 01. 31., szo – 11:23 )

A kérésed nehezen beárazható, az alapján amit látunk itt belőle. 

OS upgrade: Debian 9 -> Debian 13 (4 verzió)

Java upgrade: Java 8 -> Java 21 ( inkább 25, ha támogatja már a Geoserver)

Tomcat upgrade: 8.5.54.0 -> 11.0.x (3 major upgrade)

GeoServer upgrade(+ a pluginok): 2.18 -> 2.28.2 (ez 10 minor  verzió upgrade)

Ez több hónapos munka és biztos, hogy le kell klónozni a mostani VPS-t és azon upgradelni. Az upgradeken felül érdemes lenne változtatásokat bevezetni a biztonság terén. Ez opcionális ugyan, de egy ilyen szolgáltatás esetén számítani kell sok különböző lehetséges támadásra is. A paranoia szintjét célszerű egy normális szintben meghatározni és nyitva hagyni a lehetőséget a mozgásra ha szükséges. 

A bedugni egy Docker/Podman alá ideiglenes megoldás és csak a fennálló probléma elodázására jó. Már most sem egyszerű a frissítés, ha megnézed a fenti verzióvaltásokat. Illetve gondolnI kéne a jövőbena  frissítésekre, mentésekre és DR-re ha anhyire fontos ez a szolgáltatás.

Ez látatlanban is több milliós végösszeg lesz és hónapok, mert rengeteg tesztet is kellene futtatni verzió váltások után.

Ha úgy érzed ez anyagilag belefér, akkor üljünk le és pontosítsuk a technikai lehetőségeket, hogy jobban behatárolható legyen anyagilag.

bedugni egy Docker alá 

nagy ertemle van bedugni egy eol rendszerbe. ha a regi tomcatben/javaban/geoserverben hiba van, bennvannak a dockerben. megcsinalni rendesen hogy onnan ne tudnak kimaszni a hostra megint nem kis melo.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Én abban látom a problémát, ha a rendszer évek múlva frissítésre szorul és mondjuk arra már most gondolni kell, hogy az alap image már mondjuk nem elérhető. Természetesen ez csak egy probléma a jövőt illetően ennek ezer és más felmerülő kérdésével együtt. 

Szóval, ahogy írtad ez is problémás csak másképp.