Fórumok
lastb | awk '/ssh/ {printf("%s\t%s\t%s\n", $1, $2, $3);}' | sort -u
aja ssh:notty 95.181.188.200
brr ssh:notty 129.211.185.246
cfz ssh:notty 111.231.62.191
cgf ssh:notty 201.48.192.60
ckq ssh:notty 114.207.139.203
fsp ssh:notty 120.48.12.77
hye ssh:notty 111.231.62.191
jgr ssh:notty 106.52.105.178
job ssh:notty 106.53.114.90
jxf ssh:notty 165.227.52.184
ktg ssh:notty 165.227.52.184
lhsm ssh:notty 118.25.182.118
llw ssh:notty 116.177.20.50
lzc ssh:notty 180.76.249.74
mgh ssh:notty 106.12.73.198
mho ssh:notty 61.32.6.30
mmp ssh:notty 81.71.147.245
mrlh ssh:notty 167.172.133.221
mrph ssh:notty 106.75.214.72
mrtx ssh:notty 165.22.14.228
mzx ssh:notty 203.195.144.114
oab ssh:notty 51.81.34.189
pth ssh:notty 165.22.14.228
qcz ssh:notty 95.181.188.200
qkm ssh:notty 209.141.34.47
qwz ssh:notty 103.232.120.109
qxy ssh:notty 203.195.144.114
root ssh:notty 102.164.108.43
root ssh:notty 103.207.11.6
root ssh:notty 106.13.182.41
root ssh:notty 106.38.158.131
root ssh:notty 106.53.92.254
root ssh:notty 106.55.4.113
root ssh:notty 110.45.155.101
root ssh:notty 111.74.11.82
root ssh:notty 118.70.170.120
root ssh:notty 118.89.241.214
root ssh:notty 119.28.88.198
root ssh:notty 122.152.220.161
root ssh:notty 124.152.118.131
root ssh:notty 125.99.72.27
root ssh:notty 128.199.141.33
root ssh:notty 128.199.99.204
root ssh:notty 14.225.27.88
root ssh:notty 149.129.39.164
root ssh:notty 157.230.122.80
root ssh:notty 159.203.82.179
root ssh:notty 159.89.82.134
root ssh:notty 165.84.180.12
root ssh:notty 167.172.138.176
root ssh:notty 167.99.224.27
root ssh:notty 178.128.248.121
root ssh:notty 188.187.108.131
root ssh:notty 200.159.91.130
root ssh:notty 202.61.135.122
root ssh:notty 203.189.253.170
root ssh:notty 218.89.222.16
root ssh:notty 36.112.172.125
root ssh:notty 43.226.69.103
root ssh:notty 45.55.189.252
root ssh:notty 51.68.44.154
root ssh:notty 58.87.72.225
root ssh:notty 59.111.89.240
root ssh:notty 66.249.155.245
root ssh:notty 91.126.18.130
root ssh:notty 95.181.131.153
smcx ssh:notty 61.32.6.30
stzz ssh:notty 165.232.65.66
xfo ssh:notty 118.24.158.42
xxf ssh:notty 106.53.249.98
xxw ssh:notty 51.81.34.189
yhp ssh:notty 119.45.60.204
zxl ssh:notty 129.211.91.213
zzzy ssh:notty 64.227.96.133
Ez egyetlen nap. Nem szerver. Desktop gép.
Hozzászólások
Gondolom, megfertőztek egy rakás gépet, és zombi csordák automatikusan szimatolnak törhető gépek után a világ minden tájáról.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Pár napja teszt notimon teszteltem. PPPoE -n kapott publikus -t, 1 perc alatt 2 helyről léptek be rá ssh-n. :D
Pár éve ehhez 5-10 perc kellett. sok éve meg 1-2 nap.
Fedora 33, Thinkpad x280
Nem vagyok tőle boldog. Szokták támadni a gépet, de ez most 1000/nap fölött van már. Egy másik gépen 1800/nap úgy, hogy a gép csak néhány órát volt bekapcsolva, valamint az ssh nem a 22-es porton van egyik gépen sem. Korábbi támadások megálltak néhány tíz, néhány száznál egy hét alatt. Mi a fene van most?
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Nincsen semmi, csak a szokasos :D A sok gigabites net, eros gep/telefon stb. Pár hónapja olvastam, hogy egy erős geppel 10GbE-n vagy valami ilyesmi pár pers alatt végig lehet scannelni az egész ipv4 tartományt :D
ipv6-on ez még jóval tovább tart :D
Fedora 33, Thinkpad x280
Nálunk az egyik családtag "WD TV Media Player-t" + my cloud-t teljesen le kellett tiltani. A gigabites neten és belső hálón, akkora forgalmat csinált, hogy az összes többi gép IP-t sem kapott a dhcp-től.
"ha valakire rá kiabálunk, hogy rendszergazda akkor az is - szerződés, fizetés csak az átkos időkben kellett"
és 100 éve még boszorkányt is égettek
ohh, ugyan. Webszerver, honeypot: kb masodpercenként 80-100 csatlakozas ssh-ra, orankent kb 1500 uj ip cimmel gazdagodik a tuzfal
// Happy debugging, suckers
#define true (rand() > 10)
Hízlalod vele a tűzfalad? Ha jól sejtem, a fail2ban való erre.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
honeypot és az ebből jövő eredményt elosztottan kezelem (több szerverre is felkerül az adott ip cím)
// Happy debugging, suckers
#define true (rand() > 10)
Van arra valami szabály, táblázat, hogy magyarországi szolgáltatók - az összes lehetséges - milyen IP-tartományból oszt címeket? Mert ha igen, csinálnék egy allow list-et, aztán mindenki más már a router-ről lepattanna, országon belülről meg be tudnék ssh-zni a gépre. Akkor is támadható maradnék, csak jelentősen megcsappanna ezek száma.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Port knocking?
A geoip kifejezésre guglizz
pl.: https://www-public.imtbs-tsp.eu/~maigron/RIR_Stats/RIPE_Allocations/All…
iptables geoip modulja pont erre jó
Az erre alkalmas geoip adatbázis régebben a maxmind-től ingyen leszedhető volt, valamit azóta tekertek a dolgon.
összerakás után kb. ennyi az egész:
iptables -A INPUT -m geoip --source-country HU -j ACCEPT
https://db-ip.com/db/download/ip-to-country-lite
Túl lassú...
Nálam az ipset vált be
https://linoxide.com/linux-how-to/block-ips-country-ipset/
https://mattwilcox.net/web-development/unexpected-ddos-blocking-china-w…
Hivatásos pitiáner
neut @
en is ezt az ipdeny-t allitottam be nemreg a gepen, de ha nembizol benne, a geoiprol le lehet tolteni country databaset csv-bol, azt feldolgozva lehet etetnei az ipset/iptables-t
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
epp arra jartam, catoltam a scriptet, ha valakit erdekel:
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
És? Nem backbone előtti tűzfalba kell... kutyát nem érdekli, ha a lánc végén van valami ami nyolc microseccel tovább tart.
Nekem nem volt mindig pontos, a magyar IP-re néha más EU-s országot mondott.
Ja, előfordul.
Pl. Digi-nél is néha.
Konkrétan Digi-m van. :-)
5220 line-t nem akarok beilleszteni..
Látom, téged is megkínáltak rendesen. :(
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Egyik gépemen 5600 volt a napi próbálkozás. (Van fail2ban)
En nem hasznalom az ssh-t default porton. Persze ez nem vedelem, de atlag bot nem nagyon scannel alternativ portokra.
Ezen felul a pam_google_authenticator-t hasznalom ami tud rate limit-et is.
WireGuard mogott pedig nem ker OTP-t.
Ezen felul ezeket huzom be a routerembe:
http://feeds.dshield.org/block.txt
http://www.spamhaus.org/drop/drop.lasso
https://lists.blocklist.de/lists/all.txt
https://api.abuseipdb.com/api/v2/blacklist (ide reg kell)
Foglalkoznom kell vele, eléggé frusztráló. Ez eddig nem így volt.
3140 sikertelen próbálkozás az utolsó sikeres óta. Az az utolsó sikeres tegnap este általam volt, azóta alig néhány órát volt bekapcsolva a gépem.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
ha keves iprol van sok probalkozas, akkor gyorsban megteszi a fail2ban. aztan amikor raersz akkor lehet egyeb tiltasokat tenni ahogy itt ajanlottak
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Elmúlt két óra. Ez alatt:
Nagyon gyorsan foglalkoznom kell ezzel érdemben.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Most még rövidebb idő alatt 5060. Iziben csinálok egy új OpenWrt/LEDE image-et, benne valamilyen megoldással. Elegem lett.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
A mandinert is le DDoS-olták, le kellett vágni a netről.
> Sol omnibus lucet.
Ja, le bizony. Az L7 támadást még csak-csak meg lehetett fogni, viszonylag egyszerűen szűrhető volt a HTTP kérések mintázata alapján (bár ezt is variálták, több ezer IP címről egyébként, amik folyamatosan bővültek), de volt ott L3-L4 is relatíve nagy sávszéllel (60 Gbps), amitől a szolgáltató megfeküdt, és jobb híján blackhole-ra tette a mandiner IP-t. Kifogyhatatlan tűzerőnek tűnt, vagy 10 órán keresztül nem szűnt meg.
Cloudflare (es hasonlok) cdn-eknek ez piskota.
Apropó, melyik portot támadták?
Nekem szép tiszta a logfile. (Az sshd a nem_mondom_meg_melyik porton fut.)
> Sol omnibus lucet.
Nem szívesen mondom, ha nem baj. De nem a 22-t, onnan eltettem az ssh-t.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Nem 22. A többi nem publikus, úgyhogy nem haragszom (-:.
> Sol omnibus lucet.
Konyorgom van meg egyaltalan valaki igy 2020 vegen aki olyan naiv hogy default porton futtat ssh-t?
Fel kell rakni valahova 5000 fole es a probalkozasok 99.9%-a azonnal megszunik.
Raadasul ha valaki igy is megtalalja az eros figyelmezteto jel hogy valoszinuleg celzottan szkennelik a gepet, ergo lehet ra rakni sokkal szigorubb fail2ban-t, ertsd: ha itt is raprobal valaki akkor minden porton ban legalabb 1-2 hetre.
ezt mar parszor letargyaltuk: egy jol beallitott ssh serverhez kepest max a kisebb logfajl az elony
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Szerintem ez egy olyan elony, ami miatt mar megeri!
Ha a jovoben talalnak valami exploitalhato hibat az openssh-ban, akkor baj van :/ Ha default porton csung, garantaltan meg fognak probalni bejonni, hiaba van fail2ban, kulcsos login ...
Ha mar non-default porton csucsul akkor atlag bot nem fogja megtalalni. Persze ez kicsit ilyen security by obscurity-szeru, ezert ezen felul mindenkepp meg kell gatolni, hogy egyaltalan be tudjanak csatlakozni.
Mar itt is leirtak ... pl. lehet csak egy jump hostot engedelyezni, vpn, port knocking stb...
Ha lesz olan 0day, amivel be tudnak jönni SSH-n, akkor azt valószínűleg nem a kínai botnet fogja szőnyegbombázásra használni., úgyhogy a port változtatás imho nem sok vizet zavarna már. :)
azert ha a fel vilag ki van zarva a ssh-bol, akkor a kinai botnet nemfog jonni (max csak a magyar). de addig is _nyerhetsz_ idot, hogy kezeld a problemat. bar allitolag ez csak fals szubjektiv biztonsagerzetet ad... :)
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Miből gondolod, hogy a kínai botnetnek nincsenek magyarországi eszközei? Nincs eladva kismillió kínai IP kamera, router, AP, okos-ez-az, ugye? Amelyekben ha nincs is kínai állami backdoor, akkor is az eredeti több éves szoftver fut, sokszor default név és jelszó kombinációval. Na, ezekről fogod kapni a valódi támadást, szóval nyilván nyerhetsz egy szekérderéknyi időt, bármennyi legyen is az.
Tudod, az a baj ezzel a mentalitással, hogy ténylegesen befoltoztál az ezerlyukú szitádon egy-két igen apró lyukat és teljesen megnyugodtál, hogy nyerhetsz időt, ha jön a liszt. Holott a valóság az, hogy vélhetően észre se veszed, hogy megtörtek, csak ha valami nagyon elbaszott rootkit elkezd feltűnően kripto-bányászni. Hamis biztonságérzet, nem győzöm elégszer hangsúlyozni.
Van grafikonod és riasztási küszöböd például arról, hogy mennyi SSH request jön? Ha nincs, akkor honnan tudod, hogy merről fúj a szél és mekkorák a hullámok? Véletlenül épp ránézel és beszarsz, hogy több ezres számot látsz?
https://iotguru.cloud
ezt a hamis biztonsagerzet dolgot nem tudom honnan szivod. en tisztaban vagyok vele hogy csomo minden torheto igy-ugy. de szerintem minden dolog ami csokkenti a bejutas P valoszinuseget, azt erdemes megtenni. attol hogy megvan ez-az, meg nem dolok hatra hogy "kesz vagyok".
de ha te ugy gondolod hogy a default porton vilag szamara elerheto kulcsos ssh eleg, lelkeld rajta. mas meg ugy gondolja hogy ez nem eleg. nyilvan ez mellett meg kell alert/monitor rendszer ami a loginolasokat figyeli, stbstb.
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Én azt nem tudom, hogy mit szívsz, ha például a port áthelyezésével úgy tudod, hogy objektív szempontból nagyobb biztonságba kerülsz.
Aha, más úgy érzi, hogy nem elég.
És van ilyen?
https://iotguru.cloud
Mint mondtam en azt gondolom, hogy nem szabad nyiva hagyni siman WAN fele SSH portot. De ha van ra lehetoseg, akkor mindent elteroen az ismert configtol kell csinalni, hisz akkor egy potencialis tamadonak extra munkat adunk.
Nem a default porton van. A port továbbításom valami ilyesmi:
Értelemszerűen a port, a hostnév és az IP-cím más. Ha jól látom, ez lett belőle:
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Nálam a default porton van. Igaz, a bejutáshoz kettő próbálkozásból ki kell találni egy 4096 bites RSA kulcsot, és egy 6 karakteres TOTP-t. Egyszer tévedni emberi dolog, a másodiknál jön a fail2ban.
Problem? :)
Egyébként annak örülök, hogy többnyire root login-nal próbálkoznak. A PermitRootLogin no miatt. :)
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Ne gondold, hogy ott ül a gép előtt a próbálja kitalálgatni a userneveket, meg hátha van root. Például nmap sciptek automatizálva tolnak végig egy rakat gyakran használt usernevet.
Furcsák ezek a "gyakran használt" user nevek. Végül is a logokban sokszor látom :-D
pl: hye, nmw, oyex, hfsy, hfjg, oqm, qle, fck, cmz, gge, zgqz, rjj, ke, xwe
Ezek a random 3-4 betűsek mostanában lettek divatosak, korábban sokkal inkább tapasztaltam életszerű neveket: guest, postgres, php, admin, meg egy csomó olyan név, ami logikusnak tűnik ebben a szakmában login névnek.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Azt tudja valaki, hogy az xt_geoip_build parancsa egyes leírások szerint miért hoz létre LE és BE alkönyvtárakat? Érzésre a little endian és big endian a tippem. Azért kérdezem, mert Fedorán ez a perl script országonkénti bontásban az aktuális könyvtárba behányta az eredményt, de gyanítom, hogy itt ez little endian. Vajon a mips_24kc az mi? Aztán mi van, ha az LE és BE mégsem ezt jelenti? Már csak azért is, mert mindenféle doksiban azt látom, hogy mindkét könyvtár tartalmát felteszik a router-re.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Válasz magamnak: a mips_24kc nagy indiános, így vélhetően a Fedorára x86_64-re gyártott bináris IP-tartományok nem lesznek jók, hiszen az Intel kis indiános. :(
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Belenéztem a bináris file-ba. Érdekes, mert ránézésre big endian-osnak néz ki:
Ez ebből lett:
Ennek az LE változata vajon ez?
00 a8 3a 02 | ff ab 3a 02 | 00 c4 3b 02 | ff c7 3b 02
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
A hálózati címek mindig BE. Ez a host architektúrától független.
https://linux.die.net/man/3/ntohl
Köszönöm. Akkor itt a második step végét tudod nekem értelmezni?
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Arra gondolsz, hogy miért van BE és LE is? Nem ismerem a geoip modult, tehát csak tipp: azért, hogy mind2 formátumot használni lehessen, de ne kelljen menet közben konvertálgatni.
Ja, hogy így gyorsítanak a kernel modul futásán? Hol így, hol úgy kell, és egyszerűbb duplikáltan tárolni, mint pakolászni a memóriában? Nem tudom, mert szerintem a file elérés nagyságrendekkel lassabb, ha meg az elején RAM-ba húzza, akkor azzal a lendülettel előállíthatná az LE-t is, ha valamiért annyira ügyetlenül írták meg, hogy kell neki ez is, az is.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Csak az egyik kell, de azt mindkét formátumból be tudja olvasni. Nem tárolja duplán a ram-ban.
Vagy egy etikus hacker hallgató elbaszta az ip címet valamelyik oktató hálózaton. :)
Nem vagyok ennyire naiv. :)
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Közben ránéztem a router logjára. Azt is próbálják felnyomni. :(
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Ugy tapasztalom, hogy mennek mindenre, ami ki van engedve a netre.
Nekem bevált, ha sokjegyű számos portra tettem az ssh-t és minden, nem magyar ip címről drop a kapcsolat.
Az eddigi tapasztalat alapján nem Mo-i ip címekről próbálkoznak.
A tűzfal szabályom:
Ahol xxxx értelemszerűen a használt ssh port.
Rebootkor egy script segítségével jön létre a lista, esetleg nem árthat mondjuk ezt az ip listát hetente lekérni.
A script semmi érdekes, ennyi csak a lényege:
Most vagyok bajban, mert hiányosak az iptables ismereteim. Lehetne a /etc/firewall.user file-ban egy szabály. Például:
Értelemszerűen a portok mások, de ezt egyelőre hagyjuk. Eleve -A vagy -I? Meg aztán a példában az 5432-es port forwardolódna a desktop gép felé, míg az 5433 lenne a routerre ssh-zás. Nagyobb gondom, hogy hogyan tudom mindezt tesztelni?
Vagy inverz feltétellel DROP szabály kellene? Nem világos, hogy az OpenWrt-ben megadott többi szabály ezzel logikai ÉS vagy VAGY kapcsolatban lesz, szekvenciális-e a végrehajtás, kilép-e a kernel valamelyik target-nél, vagy hogyan van ez. Mert semmire sem megyek a szabállyal, ha egy másik felülírja azt.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
-I a chain elejére, -I chain n a chain n. helyére, -A a chain végére szúrja be a rule-t.
Szekvenciális. Tesztelni online portscanner-rel.
> Meg aztán a példában az 5432-es port forwardolódna a desktop gép felé, míg az 5433 lenne a routerre ssh-zás
Én létrehoznék egy chain-t, amiben a geoip invertáltja drop, és azt -j az input-ból és a forward-ból.
Bocs, nem ellenségeskedés, de a kérdéseid alapján elég hiányosak az iptables ismereteid ahhoz, hogy egy router tűzfalát konfigold.
Otthoni szappantartón OpenWrt/LEDE daily snapshot, nyugalom, nem céges üzemeltetés. :) A -A-ra és -I-re még emlékeztem, de nem teljesen tiszta az egész. Már nem az append és insert, hanem úgy általában az, hogyan burjánzik át egy csomag a filter szabályokon. Ha a szabály sorában teljesül a feltétel, akkor gondolom, a -j target, és ott kilép, ha nem, akkor jön a következő szabály.
Meg aztán amit forward-olni fog, arra az input szabályok alkalmazva lesznek? Ja, most látom, ezt megválaszoltad. Köszönöm.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
eloszor a port alapjan a vizsgalat menjen egy kulon chainbe. majd abban a chainben lehet a magyart acceptelni, a chain vegen meg egy feltetel nelkuli DROP. elotte akar loggolhatsz is, eseleg ebbe a chainbe felvehetsz egyedi whitellist ipket is.
ahogy fenn is irtak, szepen lepked a szabalyokon, es ahol drop/accept/reject/queue/stb -t talal, vegrehajtja, es megall. vannak specialis szabalyok ami utan tortenik valami es folytatodik a lepkedes (return, log)
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Ahogy nézem a szabályokat és próbálkozom, egyre többet értek belőle. Úgyis kifaragom! :)
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Nézem Fedorán a man page-et, meg sem emlékezik olyanról, hogy az ipset-nek lenne -F, -N, -A kapcsolója. Gondolom, a -A az add, a -F talán a flush, a -N pedig a create akar lenni. Bár azt nem tudom, hogyan lehet valamit flush-ölni, ami még nem is létezik. Azt a nethash-t sem értem a for előtti sorban. A többi világos.
Ez a megoldás jobb, mint az iptables geoip modulja? Arra értelemszerűen tudok programot írni, hogy a cím/mask_length párosból kezdőcím,végcím kettőst csináljon, tehát ezt az adatbázist is fel tudom használni a geoip modulhoz.
Most sajnos fontos egyéb elfoglaltságom van, nem tudok vele foglalkozni, de meg fogom csinálni az adatbázis automatikus frissítését a routerben.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Az ipset-nek valoban nincsenek ilyen kapcsoloi, ne keverd, amiket irsz, az iptables kapcsoloi.
Ezt voiper írta, nem én:
Ezek szerint valami ilyesmi lenne:
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Igen, igy.
Közben olvasom, hogy az a nethash is rossz, hash:net kell oda, vagy ki kell találni, hogyan tudja memóriában hatékonyan tárolni ezt, s aszerint lehet neki megmondani, hogy mi legyen. Egyébként ez Kadlecsik Józsi munkája? Mármint az ipset.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Bocs, jogos, ennyire nem voltam alapos, igen, az kell. Attol fuggoen, hogy a setet mivel akarod feltolteni, kell ezt a parametert meghatarozni.
Ugy tudom az ove. Nagyon hasznos joszag, szeretem.
nekem ez volt az v1 scriptem:
igy nemkell 28ezerszer meghivni az ipset-et loopban. a v2 script mar valtott geoip-re.
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Ja, hát aki elolvassa, hogy van restore. :) Mi miatt dobtad az ipset-et és váltottál geoip-re? Mert OpenWrt-ben van mindkettő, s egyelőre nem döntöttem el, melyik mellett maradjak.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
locsemege nem akartalak félrevezetni, nekem ez működött. Igaz, hogy nem openwrt alapon néztem, ez egy debian.
Lehet, hogy az iptables-re kompatibilitási okokból meghagyták ezeket a kapcsolókat, hogy a rendszergazdáknak ne kelljen újat tanulniuk, így aztán egy pillanatig sem kételkedem benne. :)
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Teljesen megháborodott a világ a vélhetően fertőzött zombi csordáival. Az utóbbi órákban 8137 betörési kísérletet tapasztaltam, viszont úgy néz ki, sikerült kifaragnom a megfelelő tűzfal szabályt, így vége a játszadozásnak. 22:08-kor volt az utolsó támadási kísérlet, akkor tettem aktívvá a szabályt. Azért azt is tesztelni kell, hogy engem beenged-e.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
hmm, eljatszadoztam ezzel a ipdeny listaval, es osszehasonlitottam a geoip country (lite) db-vel.
talaltam eleg sok ipt, amit a geoip ch-nak mond, de a ipdeny-n nincs benne a cn.zone-ban
pl: 3.5.236.0/22
de talaltam olyat is amire azt mondja hogy nem cn, a cn.zone-ban meg benne van.
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Mivel nekem az otthoni gép elérhetősége kell, elég volt ennyi:
Elég, ha országon belülről be tudok ssh-zni a router-emre és a gépemre. Majd még az adatbázis frissítését kell megoldanom, de egyelőre jó ez. Lehet, hogy a konverzióra írok egy nyúlfaroknyi C kódot, bár ahhoz jó eséllyel fel kell tennem a gépemre az OpenWrt SDK-ját.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Többnyire root, néha root1, root2, rootftp, dmin - így, 'a' nélkül - login nevekkel próbálkoztak. Már béke van. :)
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Azon túl, hogy idegbajt kapsz, mi bajod van a dologgal?
Ha nem tudnak bejutni, akkor teljesen felesleges ennyire izgulni és bármit tenni; ha hajózni mész a tengerre, akkor fújni fog a szél, ez ilyen.
Ha pedig be tudnak jutni, akkor meg egy jól irányzott próbálkozás is elég, kezelhetsz listákat, tűzfalszabályokat, bármit, attól még ugyanúgy veszélyben vagy, hamis a biztonságérzeted.
https://iotguru.cloud
Megtalálták a portot, ezért próbálkoznak. Nyilván van kulcs hozzá, hiszen én például legálisan bejutok. Tehát nem lehetetlen bejutni, csak nehéz. Ha DROP a policy, nem pedig REJECT, akkor úgy tűnik, mintha nem is létezne ott a port, mintha ki lenne kapcsolva mögötte a gép. Azon túl, hogy a router-en szűrök, a gépig el sem jut a kérés, le fognak szokni a belépési kísérletekről, hiszen látszólag nincs ott semmi. Nem hamis biztonságérzet. Tegnap néhány óra alatt volt emlékeim szerint 8137 betörési kísérlet, azóta, hogy ezeket filterezem, egy sem.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
És vajon mekkora eséllyel találják el a kulcsot, ha amúgy kötött név-jelszó kombinációkkal próbálkoznak?
Miért, hány százalékról hány százalékra csökkentetted így a bejutási esélyeket? Ezek a cold call próbálkozások nulla kockázattal pattannak le, egy célzott támadás meg úgy hasít át a "védelmeden", hogy észre se veszed.
Ezek nem betörési kísérletek voltak, mert esélyük se volt bejutni. Semmit nem akadályoztál meg.
https://iotguru.cloud
Túl sok időm megy a lelked ápolására. kötekszel közéleti kérdésekben, szakmai kérdésekben egyaránt, miközben az ég egy adta világon semmit nem adsz hozzá teszem azt műszaki tartalom tekintetében egy alapvetően műszaki fórumon. És bizony, ez így nem frankó. Részemről távolságtartóan viselkedem, nem látom értelmét az efféle csevegésnek. Keress mást, akibe beleköthetsz. Az ugyanis egy emberi játszma, amikor úgy vetsz fel valamit, hogy meg kellene indokolnom, mit miért teszek. Miért kellene? Különösképp neked miért? Sem a műszaki sem pedig a közéleti, politikai gondolkodásomat és döntéseimet nem fogom hozzád szabni. Ebben a topicban láthatsz példát arra, milyen az érdemi kooperáció. Tanulj belőle!
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Teljesen valid műszaki kérdéseket tettem fel a témával kapcsolatban, de tudod, felőlem küzdhetsz a szélmalmokkal...
Ha én mindössze azzal támadlak, hogy külföldi IP címekről kitartóan próbálok bejutni nálad nem létező viszonylag kevés tételből álló username:password kombinációkkal és tiltod a külföldi IP címeket, akkor ezzel egyáltalán nem növelted a rendszered biztonságát. Ha nem tiltod ezeket, hagyod megtörténni, azzal nem csökkentetted a rendszered biztonságát. Teljesen feleslegesen vagy ideges olyan dolgok miatt, amelyek kockázatmentesek.
Vedd úgy, hogy ha valaki idetéved és elolvassa a sok kooperációs "megoldást", akkor azért tudja meg azt is, hogy ezek nem fokozzák a biztonságot.
https://iotguru.cloud
Zöldséget beszélsz. Ha volt néhány ezer támadás alig néhány óra alatt, most pedig nulla, akkor csökken a feltörés valószínűsége. Ha teszem azt, eddig 1e-10 volt annak valószínűsége, hogy feltörik a gépet, s most 1e-14 lett ez, akkor nőtt a biztonság.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Szerinted mitől változna a feltörés valószínűsége, ha egyszer vagy ha tíz milliószor próbálok bejutni az aaa:111 kombinációval? Ha van ilyen, akkor elsőre bejutok, ha nincs, akkor tízmilliószor próbálva se jutok be, te meg közben komplett idegösszeomlást kapsz, hogy fel akarnak törni.
Az a tévedésed, hogy ezek nem támadások, mert ezeknek nem növekszik a bejutási kockázata a kérésekkel arányosan, mert ugyanazt a pár száz elemű kombinációt próbálják. Ha lett volna ilyen nálad, már feltörtek volna. Ha nincs ilyen felhasználóneved és jelszód, pláne csak kulcs alapján enged be az SSH, akkor nem tudnak feltörni, bármennyszer is próbálnak bejönni ugyanazokkal a kombinációkkal. Egy közepesen erős jelszóval a brutal force évekbe kerül, észrevennéd, hogy létező felhasználónévvel próbálkoznak.
Mitől nőtt volna? Nem próbálkoznak szisztematikusan, nem is támadnak célzottan.
https://iotguru.cloud
Amit írsz, az is egy feltételezésen alapul, mint ahogyan az is, hogy én azt a modellt vettem alapul, hogy olykor nagy jelszó adatbázisik kerülnek forgalomba, s azzal próbálkoznak, vagy random jelszavakkal.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Te egy kicsit túldimenzionálod ezt a helyzetet... egyrészt, mégis, mi a lófasznak próbálkoznának egy random otthoni IP tartomány random helyre tett SSH portján egy több milliós adatbázissal... hátha ugyanaz az SSH user:pass, mint amit egy megtört pornóoldalon használtál? Semmi haszna nincs. Itt ismert (=gyári default) vagy gyenge (például admin:admin) user:pass párokkal próbálnak "megtörni" különféle hálózati eszközöket: router-t, AP-t, nyomtatót, kamerát, egyebet.
Ha erős jelszavad van, amit nem használsz máshol és/vagy kulccsal engedsz csak belépést akkor védve vagy. Ha gyenge jelszavad van vagy máshol is használod, akkor meg nem vagy védve ezzel a módszerrel. Színtiszta hamis biztonságérzet.
https://iotguru.cloud
Ezzel vitatkoznek. Anno mikor a mikrotik exploit elszabadult, csunya dolgokat muveltek az otthoni cuccokkal. Ezen felul itt-ott penzt is tudtak lopni.
Parszor szedtem szet ilyen binarist, es az elso par ezer portot scannelik ... meg eleve a a konnyu predara utaznak.
Az "infected" eszkozok scannelnek, igy full automata, nem faj nekik ha vegigtolnak egy rockyou-t :)
Es, atomtamadasellenisvedez? Ahogy irtam fentebb is, egy esetleges openssh hiba eseten nem ved. Ezt nem szabad elfelejteni: https://github.com/g0tmi1k/debian-ssh
En Gyuri bacsi modjara, blokkolnam :D
Jumphost, port-knocking (mondjuk http keresre), VPN stb...
Oszt? Ezt nem lehet megtenni ezek szerint egy magyarországi botnetből? Vagy elkonfigurált GeoIP szűrő által mégis átengedett forgalomból?
Oszt? Bárhova teszed, megtalálják hamar, nem erőforrásigényes egy teljes portscan és ugyanott vagy.
Ahogy egy csomó egyéb szoftverhiba ellen se véd, az se, ha kreatívan próbálsz védekezni, aztán nyugodtan hátra dőlsz, hogy 0 "támadás" jön. Biztonság vagy biztonságérzet.
Azért mennek más portra is a 22/tcp porton kívül, mert kurva sok a balfasz, aki áttette máshova és hátradőlt megelégedve, hogy védve van.
Azért van distributed próbálkozás, mert kurva sok a balfasz, aki rátett valami szűrést a bejövő forgalomra és hátradőlt megelégedve, hogy védve van.
Holott annyi történt, hogy jelentősen növekedett a szubjektív biztonságérzete, de a biztonsága semmivel se lett jobb.
Frissen tartás, értelmes konfiguráció, mint olyan? A támadással arányos védekezés, mint olyan?
https://iotguru.cloud
Oszt, nem igazan Franko ez a stilus!
Olvasd el megegyszer kerlek amit irtam! Behoztal meg 10 masik szempontot, pedig en csak ketto kijelenteseddel kapcsolatban irtam le a gondolataimat.
A security by obscurity nem tilos, csak nem elegseges -> Az, hogy az SSH service nem a default porton csucsul az egy jo dolog, de nem elegseges.
Igy erdemes meg extra lepeseket is tenni a risk csokkentese erdekeben.
Csak sok hostra idoigenyes, ezert nem is maxoljak ki. Az emlitett "balfaszokra" utaznak. De ez igazabol mind1.
De lehet. En nem mondtam, hogy nem.
Szerintem ez alap. Ismeretlen hibara viszont nehez updatet talalni. Ezen felul egy 0-day eseten ido kell mig kapsz frissiteseket.
Te most az eppen aktualis threat-re szukitetted le ezt az aranyt, ami szvsz. hiba.
Ha alapbol zarva van a akarmilyen service port es mondjuk valami kulso sajat/berelt VPN service cimerol engeded be kizarolag a kapcsolatot haza, az ugy jelentosen lecsokkenti a risk-et. Vagy barmi mas megoldas is jo (pl. par dollaros VPS jumphostnak), csak ne tudjanak kozvetlenul kapcsolatot nyitni a service fele.
Ugyhogy firewall ruleokban mindig Gyuri bacsinak van igaza! En blokkolnam!
Ha nem vagy vulnerable és amúgy is megtalálják, akkor minek is?
Egészen pontosan milyen kockázatot csökkentesz ilyenkor? Biztonságot vagy biztonságérzetet?
Hány olyan 0day SSH sebezhetőség volt, ahol támadható voltál és az védett meg, hogy nem default porton volt az SSH?
Nem, én továbbra is azt mondom, hogy a GeoIP alapú tiltás és a port mozgatása nem fokozza a biztonságot. Csak a biztonságérzetet növeli, hamis képet ad a rendszer biztonságáról.
Plusz üzemeltetési kockázat, minden egyes felesleges rule...
https://iotguru.cloud
Te miert zarod be a lakas ajtodat? egy profinak nem akadaly a zar, akkor meg minek is? :)
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Pont olyan ajtóm és záram van, ami arányos védekezés. Amiről itt most szó van, az nagyjából az, hogy a lábtörlő alól valamelyik virágcserépbe teszed a kulcsot...
Úgy indulnak, hogy full port scan? Igen. Megtalálják az SSH-t, ha nem a 22-es portra teszed? Meg. Mennyi haszna van akkor, hogy nem a 22-es porton van? Semmi.
Ha ettől jobban alszol, csináld. Csak ne terjeszd, hogy biztonságosabb.
https://iotguru.cloud
Csendben jegyzem meg, a DROP miatt most ott sem látják, ahol amúgy van.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Maximum külhonból nem látják, hogy ott van... :)
https://iotguru.cloud
Ez így igaz. Különben én sem látnám. :)
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Nem pontos az analógia. Helyesen úgy lenne, hogy átírod a házszámot a kapun, hátha amiatt nem jön be a betörő. :D
Ha visszaolvasod, nekem ezzel a kijelenteseddel van szakmai gondom:
Tobb multbeli esemeny is alatamasztja, hogy ez nem eleg.
Ezt a non-default port dolgot te hoztad be ... Azt irtam, hogy ez mind1, ne erre hegyezzuk ki.
Nincs mit megtalaljanak. A service port legyen filterezve, kiveve 1-2 cimnek legyen kizarolag engedelye csatlakozni. Ezen felul mindig azt kell feltetelezni, hogy vulnerable vagy.
Azt kell feltetelezned, hogy korhazba kerulsz es fizikailag keptelen vagy updatelni es pont akkor jon ki egy 0-day. Jon valaki es letitkositja a csaladi fotoidat majd penzt ker erte. Ok? :D
Hol irtam olyat, hogy ez barmilyen kockazatot csokkentene? Tegyuk fel feltorik a VPN szervert es hozzafernek a privat halozathoz. *Lehet* nem talalja meg az ssh service-t a 65000-es porton a tamado.
Analizaltam mar par botot, en azt lattam, hogy 10-bol 1-2 csinal csak full scan-t, igy a szamossagat legalabb csokkentheted, ami jo.
Ezutan meg kellene neki egy kulcs vagy valami vulnerability is. Sok sikert.
Hany olyan eset volt, hogy eluthetett volna valami de te tovabb setaltal es nem is vetted eszre, hogy mi tortent?
Mar nem emlekszem pontosan, de volt talan egy Redhat? ssh update, amiben egy trojan volt, illetve a debian randomizacios fuckup. Ha default porton csung garantaltan megtalalnak, amugy meg lehet nem, fuck knows.
Hany eltitkolt exploit szaladt ki innen-onnan az utobbi 10 evben? :D Ezen felul megbizol egy distroban, aki ilyen-olyen patchet alkalmaz forditas+csomagolas elott. Nyilvan a lancban mindenki crypto-ban jartas szakember...
Igen, ebben igazad van. De EN, hol is kerdojeleztem ezt meg? Epp azt irtam, hogy az security by obscurity-nak minosul es nem elegseges.
Akkor te nem blokkollnad?
Viszont a GeoIP szűrés és a port áthelyezése sem.
Nem én hoztam be, ezek a megoldási javaslatok születtek arra, hogy ne kerüljön kiírásra, hogy x failed login volt n órája. Az ellen valóban jó, hogy az x/n ne legyen egy viszonylag nagy szám, de a biztonságot nem növeli.
Mi lenne, ha támadást analizálnál és nem pár botot?
Na, akkor most görgess vissza oda, ahonnan indult ez az egész szál.
Nem.
https://iotguru.cloud
Persze, ugy ahogy az amit te irsz sem es ultimately semmi sem oldja ezt meg tokeletesen.
Egy valodi szakmai erv arra, hogy ne mogasd a portot 1023 fole az lenne, hogy egy sima user is tud listen-elni rajta. Igy ha megall a process indithat a helyen barki amit akar. De most egy otthoni halozatrol van szo, ha mar van shell access akkor mar mind1.
Az a baj, hogy nehez igy. Osszemosod az eszreveteleimet mas kijelenteseivel. En nem locsemege-nek irtam, hanem neked.
Picit ugy erzem, altalaban tamadasnak veszik amit irok, de eppen a tudasomat osztom meg, ahogy te is.
I do this for a living ... :P
Maradjunk annyiban, hogy en blokkolnam! :D
Minden biztonság arányosságra törekszik. Aránytalan biztonságnak nincs sok értelme.
Én mindössze annyit írtam, hogy a szálban felhozott megoldási javaslatok nem fokozzák a biztonságot, csak a biztonságérzetet. És úgy látom, hogy ennek a biztonságérzetnek célszáma a "There were X failed login attempts since last N hours." üzenetben az X/N minimalizálása. Semmi több.
Akkor nyiss egy új szálat a témában.
Ha hajózni mész a tengerre, akkor fújni fog a szél és hullámok lesznek. Ha kinyitsz egy portot a nagyvilág felé, akkor próbálgatni fogják. Ez a természete ezeknek a világoknak. Ha kinyitsz egy VPN portot, akkor azt fogják próbálgatni, mindegy, milyen portot nyitsz ki, próbálgatni fogják. Ha ettől ideges leszel ("eléggé frusztráló", "nagyon gyorsan foglalkoznom kell ezzel érdemben", satöbbi), akkor nem való neked a portnyitás, maradj a szárazföldön.
És tudod: fogadni merek egy láda sörbe amúgy, hogy a kérdező nem szokta és nem is tudja detektálni azt, hogy bejutottak-e, vagy már fut-e kártevő a gépén. De ma már nyugodtan aludt, mert az X/N kellően alacsony volt.
https://iotguru.cloud
A zero-trust model alkotoinak is ird ezt le pls. Valami papirt is publikalj a temaban, hogy hogyan lehet ezt az aranyt pontosan megallapitani!
Ja, hogy akkor arra amit szakmailag kifogasolok a TE irasodban, nyissak egy teljesen fuggetlen uj szalat? Micsodaaaa?
Meg ezzel is egyet tudnek erteni, csak ha tobb reteged van, akkor egynel tobb dolgot kell baszogatnia, ami tobb ido, nagyobb nehezseg. Ez nem csak a biztonsag erzetet noveli.
Ha ugy indulsz neki egy vitanak, hogy azt feltetelezed, hogy a masik fel tuti ostoba, akkor konnyen megutheted a bokad.
Á, szóval te a világ összes katonaságánál is erősebb és megbízhatóbb magánhadsereggel véded a cuccaidat? Ha nem, akkor most köpj fel és állj alá.
Pontosan sehogy, de a hasztalan, ám látványos, sőt, látványosan statisztikázható dolgok ezen nem igazán segítenek.
Az én írásomban mit is kifogásoltál? Továbbra is annyit állítok, hogy a GeoIP szűrés és a port áthelyezése hamis biztonságérzetet ad, a biztonságot nem befolyásolja.
Növeli a biztonságot? Kitiltod az IP-k felét és már dupláztad a biztonságot?
1, Ha a szokásos "tamádások" jönnek, mint ebben a témában is látható, azok ártalmatlanok, engedheted mind, nem fognak bejutni, nem növeltél biztonságot.
2, Ha véletlenül elosztott brutal force vagy DDoS támadás jön, azt amúgy is észreveszed, mert kiemelkedő forgalom lesz és nem befolyásolja az, hogy mennyi IP-t tiltasz, nem növeltél biztonságot.
3, Ha elosztott 0day exploit támadás jön, akkor elég egy, ami betalál, nem növeltél biztonságot.
-
Olyan ez, mint SMTP-n anno a greylisting, egy darabig fasza volt, mert lehetett szopatni a spammert, aztán megtanulták és azóta semmi haszna, szinte mindenki ki is kapcsolta. Pont ilyen az SSH port máshova mozgatása és a különféle IP listák alapján való tűzfalazás és a fail2ban, egy darabig fasza volt, mert lehetett szopatni a botokat, aztán megtanulták és azóta semmi haszna, átmennek rajta, mint meleg kés a vajon.
Ha valami hasznos védelmet akarsz, akkor ne ezek legyenek, mert ezek nem védenek és ne vetődj árnyékokra, mert hamis biztonságérzetet ad mindössze.
Ja, hogyne. De azért érdekelne, hogy futtat-e valamilyen rendszerességgel offline checksum ellenőrzéseket és keres-e gyakori kártevőket. Vagy ott tart még, hogy ez Linux, erre nem kell víruskereső.
https://iotguru.cloud
Felkelteted az érdeklődésemet. Te hogyan csinálod?
Arányos védelemmel: automatikusan települő security update; riasztásokkal egybekötött monitoring; arányos tűzfalazás, rendszeres időnként offline checksum és ilyesmi. Léggömbhámozással, security by obscurity és egyéb látszattevékenységekkel nem foglalkozok, nem fogok attól jobban aludni, hogy óránként csak 50 és nem 5000 request jön az SSH-ra, mert nem kockázat, ha papírgalacsinnal dobálják a várfalat.
https://iotguru.cloud
az csak egy szubjektiv biztonsag erzet, hogy majd a monitoring rendszer szolni fog ha bejutottak :)
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Sehol nem írtam, hogy a monitoring rendszer csak akkor szól, ha bejutottak. Azt írtam, hogy szól, ha valóban támadnak olyan módon, aminek a legvégén valódi esély van a bejutásra. Amíg egyszer nem próbálják meg azt a felhasználónevet, ami létezik, addig minek forgolódjak álmatlanul attól, hogy ebből óránként mennyi volt? Akkor vagyok igen-igen kicsi veszélyben, ha azzal a felhasználónévvel akarnak belépni jelszavakat próbálva, ami létezik, de csak kulccsal lehet bejönni, mert valahonnan kiszivárgott és ki kell nyomozni, hogy hol volt szivárgás. A valódi veszély az lenne, ha lenne kulcsuk is...
Ezt amúgy te észreveszed, hogy van kulcsuk és elsőre bejönnek? Mert a többi, amit művelsz, az közönséges survivorship bias, ott pakolod a páncélt a repülőre, ahol amúgy védett a találatok ellen és nem azt nézed, hogy hol védtelen.
https://iotguru.cloud
aha, es azzal az ssh 0dayel mi lesz ahol egybol bash-t kap a tamado? nincs usernev, nincs kulcs, nincs logbejegyzes sem... jo hat ilyen a Franko vilagban nem letezik, nem is kell ellene vedekezni :)
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Megtalálja máshol az SSH-t? Meg. Lesz magyarországi botnet, ahonnan elosztva próbálkozik? Lesz. Bejut a kurvára védettnek gondolt gépedre? Be.
Válaszolj kérlek őszintén: nálad automatikusan települnek a security frissítések? Mert nálam jelenleg maximum 5 percig lesz védtelen rendszer, nálad ez maximum mennyi idő?
https://iotguru.cloud
unattended-upgrades
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Igen, tudom, hogy van ilyen, a feltett kérdésre válaszolj, őszintén.
https://iotguru.cloud
valaszoltam, a fenti csomag vegzi, bar nem tudom mi koze van ehhez egy 0day-hez :/
de mind1 hagyjuk. istenhivokkel nincs mar kedvem vitatkozni :)
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Akkor újra: a kérdés az volt, hogy nálad ez mindenhol fut-e. Mivel kerülöd az egyenes választ, gondolom nem fut, az van, mint Ar0n esetén, hogy "korhazba kerulsz es fizikailag keptelen vagy updatelni", de persze két tűzfal közé tenni kell egy harmadikat és az SSH-t szarrá kell tűzfalani, mert attól aztán kurva nagy biztonság lesz.
A 0day-hez annyi köze van, hogy szinte azonnal felkerül a javítás a rendszeredre, akkor is, ha nem tudsz róla, hogy kiderült és jött rá patch... vagy pedig alszol nyugodtan, a rendszereid meg lyukasak, mert a "változás rossz", főleg, ha automatikus.
A nem közismert, javítás nélküli 0day-hez meg annyi köze van, hogy azt nem a te gépeden fogják demonstrálni és ha igen, akkor bizony lófaszt nem véd az, amiről úgy gondolod, hogy csökkenti a feltörés esélyeit...
Ezt magaddal beszéld meg, mert kettőnk közül te hiszel abban, hogy nagyobb biztonságban attól, hogy nem a default porton van az SSH és egy országra szűkíted bejövő kéréseket. Én meg tudom, hogy ezekkel nem leszek nagyobb biztonságban, felesleges pótcselekedet, színtiszta survivorship bias. Ha már csinálsz valamit, akkor olyat tegyél, amitől növekszik a biztonságod, a biztonságérzetedet hiába növeled, attól még simán feltörnek egy 0day sebezhetőséggel mondjuk egy magyarországi IP kameráról indítva a támadást, mert az ellen nem véd.
https://iotguru.cloud
"Semmi haszna nincs."
"Ha erős jelszavad van, amit nem használsz máshol és/vagy kulccsal engedsz csak belépést akkor védve vagy."
"Plusz üzemeltetési kockázat, minden egyes felesleges rule..."
"A támadással arányos védekezés"
Ezt mindet.
Te amugy igy latod amiket irok? "Nincs mit megtalaljanak. A service port legyen filterezve, kiveve 1-2 cimnek legyen kizarolag engedelye csatlakozni."
Ki az aki bant teged, hogy itt vezeted le a feszultseget? :)
Ha erős jelszavad van, akkor üzemszerű körülmények között (nem üzemszerűt lásd lejjebb) még közepesen gyenge jelszó esetén is minimum évekig tartó brutal force alatt vagy törhető, ha nincs jelszavad, hanem csak kulcsod van, akkor pláne. És persze ehhez ki kell találni a felhasználónevet is, ami létezik az adott rendszeren és ez azért nem triviális, ha nem "admin" vagy "user" az a felhasználónév. Ezekre tudsz tenni metrikát, igen alacsony riasztási küszöbbel, hogy elkezdték próbálgatni valamelyik felhasználót, tehát információ szivárgás van vagy volt, aminek ki kell deríteni a forrását.
Kurvára értelmetlen azon pörögni, hogy olyan felhasználókkal próbálnak belépni, amelyek nálad nem léteznek és olyan metódussal próbálnak, amivel amúgy sem engeded be.
Egyszer zárod ki magad tűzfalszabállyal, amikor fontos lenne belépned, akkor rájössz, hogy miért üzemeltetési kockázat. Beállítod, hogy csak magyarországi IP engedjen be, aztán kapsz egy olyan IP-t a UPC hálózaton, ami osztrák (megtörtént eset), aztán próbálsz onnan olyan helyre tovább menni, ahonnan be tudsz lépni. Másrészt, ha statikus az IP adatbázisod van, akkor elmászik alatta a világ, egyre többször szaladhatsz bele problémákba; ha dinamikus, akkor vagy kézimunka, ami üzemeltetési kockázat vagy automatizálod, akkor meg máshonnan húzol be üzemeltetési kockázatot. Ha meg elbaszod az automatikát, mert nincs rá out-of-the-box megoldás (nem véletlenül), akkor bizony könnyedén kicsukod magad.
Az ellen védekezz, ami veszélyes, annyira, amennyire veszélyes és kockázatos.
A témaindító "támadás" annyi, mintha papírgalacsinnal dobálnák a várfaladat, azt röhögjed ki, ne számolgasd nyüszítve, hogy mennyi papírgalacsin per óra épp a "támadás" mennyisége, teljesen ártalmatlan az egész.
Ha feszegetik valamelyik kaput vagy próbálgatnak jelszavakat, mert tudják a felhasználónevet, akkor erre legyen alacsony küszöbű riasztás és nézd meg, hogy vajon honnan szivároghatott ki egy felhasználónév. Nekem eddig még nem tudták kitalálni, hogy mi a felhasználónév, nemhogy jelszóval próbálkoztak volna, amivel amúgy nem jutnak be...
Ha jön biztonsági javítás, mert kiderül, hogy a szennyvízcsatornán keresztül fel lehet mászni a várba és belülről kinyitni a kaput, akkor legyen automatikus eljárásrended arra, hogy a lehető legkevesebb időn belül felmenjen a security fix, humán interakció nélkül.
Ha kiderül egy 0day sebezhetőség és nincs rá azonnal security fix (ez ritka), akkor is minimum tudjál róla, hogy van 0day sebezhetőség és legyen rá workaround terved, amivel védeni tudod magad. Nem általánosságban, hogy hátha nem jönnek be, ha felezem az IP címeket, hanem tényleges és működő workaround, amivel ténylegesen megvéded magad.
Ha van 0day sebezhetőség és nem derült még ki, akkor van esélye, de igen-igen kicsi, hogy rajtad kezdik kihasználni, mert egy nem javított és ismeretlen 0day sebezhetőségnek komoly ára van a feketepiacon, nem fogják jelentéktelen gépeken ellőni, ahol felmerül, hogy mi van, ha "korhazba kerulsz es fizikailag keptelen vagy updatelni", hanem olyan célpontokon fogják használni, ahol van bőven anyagi haszna is. Ez ellen nem véd az, ami megoldásokat itt látunk, mert humán intelligencia fog támadni, kombinált sebezhetőségekkel, social engineering és egyéb dolgokkal; amikor már botokkal nyomják tömegesen, akkor már napokkal, hetekkel, hónapokkal a security fix után vagyunk.
És persze nézni kell azt, hogy bejutottak-e, mert a sikeres támadást pont nem fogod észrevenni se a tűzfal, se a monitoring, se a többi dolog nem jelzi, főleg, ha ügyesen csinálják. Linkeltem az előbb, ez az SSH hekkelés tipikus survivorship bias, szanaszét lőhetik az SSH logot, nem lesz belőle egyáltalán bajod, viszont mivel sok találat van, egyszerűen pszichológiai okokból akarsz ezzel foglalkozni.
Az itt olvasott hülyeségek bántanak, amelyek megoldásként születtek a feldobott problémára.
https://iotguru.cloud
Koszonom, mostmar akkor ertem! A "brutal force" az!
Szeritnem az is baj, ha tarolnom kell vagy ha felporgetik a lemezeimet feleslegesen.
Te csinald igy! En meg majd szomoruan hasznalom a kis kulso par dollaros jumphostomat meg a kulso VPN-emet, hogy elerjem az otthoni SSH-t. Rettegek majd, mert az otthoni halozatom uzemeltetesi kockazatai magasak a 2 darab allow rule miatt. Szomoru leszek mert szerinted hulyeseg.
Nem, a brutal force nem veszélyes. Az a veszélyes, hogy kiszivárgott egy használt felhasználónév, ez egy indikátor, hogy valahol adatszivárgás van a rendszerben, valaki valahol bejutott vagy valaki valahova olyan dolgot publikált, amiben benne van.
Logrotate, mint olyan? A monitoring real-time feldolgozza, utána eldobható a konkrét log, nincs benne hasznos dolog.
Hajrá. De azért ez kissé messzebb van attól, hogy zárjuk ki a fél világot és tegyük máshova az SSH portot, mert az majd megvéd.
https://iotguru.cloud
Jaj, csak errol irtam neked mar egy fel regenyt :)
Hajra "brutal force"!
ez olyan mint a lotto nyeres: aki nem vesz (=probalkozik sshn) szelvenyt, nem nyerhet (=sikeres belepes). nyilvan meg egy csomo mindennek kell egyeznie, pl eltalalni a megfelelo szamokat (=eltalalni a megfelelo u/p). amugy nem feltetlenul rossz az ha a felesleges problakozokat (=zajt) kiszurjuk, lehet koncentaralni a maradek probalkozora.
de amugy igaza van locsemegenek, minden valaszod olyan mintha az lenne az egyeduli es megdonthetetlen igazsag a vilagon, mindenki mas meg egyszeruen hulye. :/
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Bocsánat, de nem, ez olyan, mintha csak öt számot játszanál meg a hatoslottón és várnád, hogy mikor nyersz.
Ha továbbra is naplózod, csak máshol is, akkor kettő helyen kell nézned, hogy mi a helyzet. Ha meg nem naplózod, akkor nem tudod, hogy mi történik, azt hiszed, hogy biztonságban vagy.
És akkor jönnek az olyan önszopatások, mint amikor kapsz véletlenül egy külföldi GeoIP címet és faszán ki is csuktad magad.
Alapvetően az a baj, hogy a biztonság az objektív dolog, a biztonságérzet meg szubjektív dolog. Nincsen semmi baj azzal, hogy ha valaki túlaggódja a dolgokat, akár azzal se, ha paranoiás és ide hallom hogy szinte nyüszít, mert támadják, aztán csinál egy értelemetlen dolgot és megnyugszik, csak tegyük oda, hogy nem az objektív biztonságot fokozta ezzel, hanem a szubjektív biztonságérzetét.
Értem, hogy most már nyugodtan alszik, tök jó dolog, de ne írjuk le, hogy biztonságosabb lett ezzel a rendszere, mert az egyszerűen nem igaz.
https://iotguru.cloud
a biztonsagot en nem egy bites szamkent kezelem hanem egy allapotot a 0 es a vegtelen kozott valahol. minden olyan dolog ami megtilt/bezar/stb valamit, az odebb loki az allapotot a vegtelen fele, van ami nagyot valtoztat, van ami kisebbet. minel tobb minden van, annal tavolabb van az inserucre 0-tol.
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Oké, én megpróbálok hozzád bejutni kizárólag `T29ZbvvG` felhasználónévvel és `AZx5APnT` jelszóval. Mennyit mozdul el a biztonságod a skálán, ha ezt tiltod egy rajtad kívülálló IP lista alapján?
https://iotguru.cloud
most valtoztathatok jelszot, mert kitalaltad! :D
de latod a mozgas szubjektiv ertek: szerinted 0, szerintem meg picit. hogy pontosan mennyit, nemtudom. de az biztos hogy tavolabb kerultunk a 0-tol mint ahol voltunk.
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
De akkor egyből bejutottam volna, se fail2ban, se GeoIP, se portáthelyezés nem védett volna meg, nemde?
Neked a biztonságérzés van a skáládon, az a szubjektív.
https://iotguru.cloud
jo hat a megdonthetetlen igazsagokon nem tudok valtoztatni. de nincs baj. ha te ugy gondolod hogy eleg az sshkulcs, akkor ne is csinalj tobbet. en meg csinalok ezt-azt. akik meg olvassak a szalat, eldontik hogy eleg-e a Frako's security, vagy ok is csinalnak-e meg tovabbi "fals" biztonsagi dolgokat :)
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Hajrá, tedd azt, amitől jobban alszol.
https://iotguru.cloud
Attól tartok, a probléma az, hogy kedves @locsemege kolega fél a lebukástól, hogy még ennyi év informatikai és/vagy Linux hókuszpókusz után sem volt szándékában kikommentezni a "PasswordAuthentication" sort az sshd_configjában...
Vagy, ami még nagyobb gáz lenne, ha kiderülne, hogy a "prohibit-password"-ot viszont sikerült eltüntetnie a "PermitRootLogin" mellől.
De, hogy ennél is (technikailag) relevánsabb legyen eme hozzászólásom, kérdezem:
Mit fog csinálni a kedves kolega akkor, amikor egy hazai botnet cuppan rá a portjára kopogtatni??
(Mert feltörhető/lejárt támogatású/távolkeleti IP-kamerák penetrációjának tekintetében igencsak rosszul állunk e téren.) vagy
Mit fog csinálni, ha egyszer külföldre viszi útja, és rájön, hogy szar dolog az embernek maga alatt vágni a fát??
Mert, ha mondjuk egy TV szolgáltató vagy, és valamelyest korlátozni szeretnéd, az adás nézhetőségét a világ egyes tájairól, akkor megértem, hogy van értelme a GEOIP-féle bohóckodásnak, vagy ha egy nagyobb szolgáltató vagy, és mindenképpen szükség van a passwordauth-os ügyfelek kiszolgálására, akkor a fail2ban ssh-ra reszelésének, de azt, hogy a 4-5 biten kifejezhető darabszámú (ráadásul otthoni) felhasználók szintjén miért nem lehet áttérni az ssh, kulcsos használatára, azt nem tudom megérteni!...
Abban, viszont maximálisan igazat adok @_Franko_ kolegának, hogy, ha évek múltán, tfh. egy leendő rendszergazda tanonc ránéz erre a topikra, akkor értelmes, és valódi megoldást is lásson, ne csak hamis biztonságérzetet adó félmegoldást.
Éppen ezért a pikánsabb megjegyzéseimet is idebiggyesztem:
Vajon megéri-e a perfomancia-veszteség a SOHO routeren, (fogadjunk, hogy TP-Link), amit az iptables GEOIP modulja okoz számára?
(Mert itt sincsen ingyen a húsleves)
De mondok jobbat is:
Tedd odébb legalább 10 bitnyivel azt a fránya ssh-portot, és meglátod, hogy újabb hónapokra békén hagynak.
(saját tapasztalat)
Nem hagynak békén, ugyanúgy megtalálják, mintha a default helyen lenne. Ráadásul a kérdező már áthelyezte és úgy "támadják".
https://iotguru.cloud
Mostmar csak leirom, hatha idegesit! Poenbol tegnap inditottam egy-egy ssh-t 2 public IP-n 22/65000 porton.
Itt a stat:
22: 12236 db failed attempts
65000: 0 db
Vedelem? Nem. Hasznos, jobb igy? Igen.
de azert majd majd vigyazz az alvassal, mert ez igy nemjo!!!44 :D
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Hatradolni nem fogok ... meg alvas kozben sem! Igerem!
22-re kiajanlottam egy endlessh-t, nezegessek csak. :)
Hát akkor itt az ultimate silver bullet, csak át kell tenni a 65000 portra mindenkinek és problem solved örökre. Halleluja.
https://iotguru.cloud
Nem! 65535 fölé, és azt soha nem fogják támadni. ;)
Vegre! Erted mar.
Hogyne, mindent értek.
https://iotguru.cloud
vagy 0 alá, a -22-re :D
Nem állítottam, hogy örökre békén hagynak, csak azt, hogy egy ideig.
(Ha az az idő, tfh. másra nem, de legalább arra jó, hogy higgadtan átgondolja az ember a dolgokat.)
Az nekem is feltűnt, hogy az utóbbi hónapokban nagyságrendekkel jobban felszaporodtak az ilyen jellegű próbálkozások.
Ugyanakkor az, azért még mindig igaz, hogy egy DROP policy-s tűzfalon, a teljes tartomány végigszkennelése relatíve hosszú idő, ezért még most is él az a hagyomány, hogy a 10K alattiakat szeretik tesztelni.
És ezt az én statisztikám is alátámasztja:
(elmúlt 2 hónap, nyilvános ip)
3-4K közötti ssh port: 40.384 sikertelen
30-40K közötti ssh port: 94 sikertelen
A fenti GEOIP-re egy (nem állítom, hogy sokkal jobb) alternatíva:
A fail2ban-nal átmenetileg letiltod magát a megcélzott usert, és nem csak a támadó 1db címét.
Ez a nagyon sok forrású botnet ellen egy relatíve "olcsó" védelem, de kétségtelen, a támadás alatt, a valódi user is kiesést fog tapasztalni.
Ami viszont mostanában engem idegesít, azok a célzott adathalász támadások.
Amikor az egész webmail,honlap,stb felületét lemásolják, majd elküldenek az ismert (mondjuk honlapon kintlévő) címekre egy helpdesk levelet, a hamis linkkel, az egyszeri kolega meg, (nem ellenőrizvén a böngésző címsorát) azt hiszi, hogy jó helyen jár, és belép.
(És sajnos egyre javul a magyarságuk is, talán a google translate fejlődésének köszönhetően?)
Korábban ilyenek mifelénk, (talán érdektelenség végett) nem voltak, és ez ellen a GEOIP, meg a fail2ban sem véd...
vpn
+1 a vpn használatra.
Z
Szijártó Zoltán
Aki tud az alkot, aki nem tud az csak szövegel.
A VPN-t nem fogják "támadni"? Vagy annak nincs minden loginnál egy üzenete, hogy a "There were X failed login attempts since last N hours.", ezért nyugodtan hátra lehet dőlni?
https://iotguru.cloud
Tűzfal => VPN + token => Tűzfal => Port Knocking
- port scanner ip-k: 30 napra tilt
- aki ssh-zni / ftp-zni / winbox / stb. akar: 30 napra tilt
- ami nem adott 8 országból jön eldob
- ping eldob
- kintről minden zárt
- partnerek is csak VPN-en jöhetnek
Kkv szinten béke van, vagy csak azt hisszük! ;-]
Kinél még milyen tipp van ami bevált?
Köszi!
# RHE, CentOS (rip), NethServer, Fedora 33 (KDE)
Ahol lehet VPN, de kevés helyen építem ki csak ezért.
Inkább 1-2 VPN kapcsolat, aminek kijárata fix IP-s és ezen IP-ről engedélyezem az SSH-t a többi szervereken.
ICMP-t nem tiltjuk, max korlátozzuk, pl 5 ICMP csomag/sec
Nálunk kintről tiltott, bentről pedig korlátozott.
# RHE, CentOS (rip), NethServer, Fedora 33 (KDE)
A VPN-nel az a bajom, hogy léteznek vírusok, malware-k, nem kis számban, amik csak a VPN config fájlt keresgélik, a mit-sem-sejtő user kliens gépén.
2 faktoros auth.
Kulcs, amit épp kiolvashat az általad említett malware + jelszó, amit menet közben gépel be a user ÉS memóriában nem tárol le. Ilyet beállítás van openvpn-re.
Persze, ha keylogger fut a gépen, fertőzött a gép, rég megette a fene. Hálózatra tiszta gépet illik kapcsolni.
Tompítani vpn auth-tal összekötött ip szűréssel tudsz. Vagy tokennel emelni a biztonságon.
En most egy Yubikey-t hasznalok erre. Korabban sima smartcardot hasznaltam.
Ha olyan cimrol kapcsolodok amirol meg soha meg van egy 2 faktoros auth is.
Mi a tapasztalatod vele? Köszi!
# RHE, CentOS (rip), NethServer, Fedora 33 (KDE)
Egy yubikey nano-m van. Tulajdonkeppen ugyanolyan mint egy smartcard, a kulcsot az eszkoz generalja es tarolja a HSM moduljaban es azt remelhetoleg soha nem hagyja el.
Mar ~3 eve van meg, nem volt vele gond.
Volt valami minor security problema es kuldtek uj kulcsokat. Szvsz jo ceg.
Ezen felul van benne FIDO, ugyhogy webes cuccokhoz is hasznalom.
Mennyivel tartod biztonságosabbnak, jobbnak a Yubikey-t, mint pl a Google Authenticator appot?
Kb egy éve beszéltem egy ismerőssel, aki azt mondta, hogy teljesen áttértek a cégnél a szoftveres megoldásra. Meglepődtem, mert nagy cégről van szó, akiknél az egyik fő üzletág a biztonsági rendszerek.
Nehez megmondani, jo beallitassal es megfelelo oktatassal szerintem megkozelitheto. Sok emberre azert jo draga egy ilyen hardveres megoldas, valoszinuleg nem eri meg. Ki merem jelenteni, hogy tulzas is egy picit.
De egy harveres megoldas mondjuk tenyleg nehezen duplikalhato.
Btw, nekem amugy sokkal kenyelmesebb egy ilyet hasznalni mint minden ssh loginnal vacakolni valami app-al.
Nem egy kategória a kettő.
A google authenticator tudomásom szerint egy TOTP generátor.
Ehhez képest a Yubikey ezer másik dolgot is tud, pl. privát-publikus kulcspárt generálni, és azzal authetikálni.
Ez egyértelmű, de ha meg akarom védeni a postafiókomat, github fiókomat,... jelent-e plusz biztonságot?
Párszor nekifutottam, hogy veszek, de mindig elakadtam ott, hogy ha a kulcscsomómra teszem, akkor az egész kulcscsomót viszem a géphez, két gépet használok,... Ha nem teszem a kulcscsomómra, kb soha nem lesz nálam. A telefon mindig nálam van.
Vagy a leggyakrabban használt gép be van állítva megbízható gépnek, és csak az idegen helyen való bejelentkezéshez van használva?
Tényleg érdekel, hogy milyen pluszt ad a gyakorlatban. Hogy érdemes használni.
Igen, nagyon sok hardveres vedelem van benne arra, hogy ne lehessen duplikalni, kiolvasni belole az informaciot.
Ez altalaban rad van bizva. Ha elmented a gepet akkor igen, ennyi.
Van benne TRNG. Nekem a kulcsomat is ez generalta es soha nem hagyja el a belsejet, olyan mint egy smartcard.
Minden software megoldas, igazabol csak egy hack :)
Tehát azért biztonságosabb, mert a telefonomat feltörhetik távolról, a hardveres megoldást fizikailag is meg kell szerezni?
A szoftveres megoldásokat nevezhetjük simán hacknek, de a szoftveres megoldásokkal könnyebb alkalmazkodni az aktuális körülményekhez.
Amikor regisztralod a authenticatort altalaban beolvasol egy QR kodot. Ha az megvan barkinek akkor ugyanazt az OTP-t tudja generalni. Masik, hogy megbizolt egy 3rd partyban.
Ez igy van. Igy mindig fel kell merni, hogy mit vedunk, mekkora a kockazat es jonnek meg az anyagiak is.
Barcsak mindenhol lenne lehetoseg softveres OTP hasznalatara.
Pont azért szoktam rákérdezni, hogy kapjak személyes véleményeket, tapasztalatokat, hogy könnyebb legyen a kockázatokat meghatározni.
Az U2F funkcioja miatt valoszinuleg nem erdemes ilyet venni.
Ha lehet hinni a leírásoknak, a WireGuard VPN rejtőzködő üzemmódban figyel UDP-n: nem válaszol olyan kérésre, ami nem megfelelő kulccsal érkezik. Elvileg így nem lehet észrevenni szkenneléssel. Eleve nincs egy meghatározott port, én 50000 fölé szoktam állítani.
Ez igy van, en ki is probaltam ezt regen!
Nálam is sok próbálkozás van a magas porton elérhető ssh-n, és még attól is több a port szkennelés az otthoni routeren. Tényleg nagyon megugrott az utóbbi időben.
Nem csak a közvetlen támadások (gagyi próbálkozások) miatt teszem el magasabb portra az ssh-t, ..., hanem hogy egyszerűen feketelistához tudjam adni a próbálkozó IP-ket. Ma port szkennelésre, ssh törésre használják a botnetet, holnap már nem érdekel mire, mert tűzfalon tiltva vannak. Tudom, hogy nem az ilyen "védelmektől" alszik nyugodtan az ember, változnak az IP-k,... de egy kis plusz, amit könnyen be tudok állítani az otthoni routeren.
Ha már így szóba került, hogy több támadás éri az otthoni eszközöket, érdekel, hogy van-e olyan, aki átnézte a saját rendszerét, hogy minden rendben van-e? Esetleg módosított-e valamit?
Igen. Nem.
https://iotguru.cloud
Ummm, azt hiszem en nyeretem :)
# lastb | awk '/ssh/ {printf("%s\t%s\t%s\n", $1, $2, $3);}' | sort -u | wc -l
499113
#
Ez egy dev szerver ami lehet, hogy itt ott dodgy egy kicsit - a prod parjanal csak 3-4k ilyen probalkozas van.
Szép!
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE