Öööö, szerintem ne nekem De nagyjából kifejtetted kicsit részletesebben, amire én is utaltam a kérdezőnek.

@bambano: +1, igazából attól függ, mire kell. Ilyen alap logikai izolációkra, hogy semmi durva teljesítményelvárás, csak ül 1-2 buta szerver démon a maga kis elzárt homokozójában, néha kiszolgálva 1-2 kérést, még 2 fizikai mag is bőőőven oké. De újabb i3-ak 4 fizikaival pláne, igen.

De Frawly-nak is igaza van, csak lehet, félreértett engem (vagy én fogalmaztam nemjól), eszem ágában nem volt i3-azni szerverbe, de kérdés, mit tekintünk szervernek. A home lab, vagy egy fejlesztő kezében egy sima laptop is lehet "szerver" arra a pár órára, míg beröffenti a dolgokat, mert miért ne lehetne. (Legalábbis nálam ez tipikusan ilyen kis szerver / nagy szerver kategória, ma már bármi lehet szerver, egy Raspberry Pi is.. meg ugye környezet függő, DEV-nek jó lehet, PROD-nak nyilváááán SOHA)

Még mindig a fejlesztéshez vissza, mert pont ebben vagyok én is mostanság: HAProxy-s pacemaker-es loadbalancer-es felállást meg minden ilyen "ökörséget" kicsiben tökéletesen el lehet játszani Virtualboxokban is egy Windows host-on, én így csináltam pár éve, igaz gamer laptop volt 4 maggal, de 1 szálat kapott minden és miután beboot-oltak a VM-ek, idle-ben ott üldögéltek kb. az idő 99%-ában, viszont konfigolgatni, demózni, próbálgatni ezt-azt nagyon hasznos volt a kis mini-lab. A 8G RAM elég sokmindenre, egy Debian "standard" installer iso pedig desktop nélkül 1 vCPU-val és 512 RAM-al elég jól tud hasítani, valami 80 MB az alap RAM igénye az első friss telepítés után, de mindjárt lepróbálom egy netinst-en.

[ Szerkesztve ]

POKE 16017,44 ..... SYS 2077

Ok, akkor vedd úgy, hogy nem neked szólt. Csak amiatt írtam, mert az i3-as procit feszegetted szerveres környezetben.

Hát feszegettem szerver célra, a környezet laptop volt mindvégig. Nem írta meg a kérdező, milyen CPU végül. Vt-d nélkül sok esély nincs, vt-d-vel is csak szolídban, kicsiben (i5 és fentebb az ő esetében, új vasaknál már az i3 is 4-magos + vt-d-s).

Na közben meg is van a Deb10 testing friss install egy 1 magos 512 RAM-os VM-be.
root@debian:~# free -h
total used free shared buff/cache available
Mem: 482Mi 56Mi 350Mi 0.0Ki 75Mi 413Mi
Swap: 509Mi 0B 509Mi

Lehet ezzel bohóckodni sokat Kérdés, mit akar virtualizálni. 8G fizikai RAM-al még egy 4G-s W10-et is tud, igaz, mire bejön, elmehet vacsizni közben

Mindig a "mire" a kérdés.

[ Szerkesztve ]

POKE 16017,44 ..... SYS 2077

Ja, hobbivirtualizációra, OS-eket tesztelni, meg minimális OS-eket építeni jó az 512 MB RAM egy prociszállal. De ezzel komoly dolgot nem tudsz kezdeni, én VM-nek is minimum 4 GB RAM-ot és min. 2 prociszálat adnék, az is abszolút minimum. Ilyen 1 vCPU meg 512 MB RAM-nál abszolút felejtősek azok a dolgok, amivel dobálózni szoktál, ZFS RAID, meg MySQL InnoDB és társai.

Szerintem két külön példát hozott fel.

Második gen i5 van a gépben és gyakorlatilag ms office-t használnék vm-ben, de már próbáltam. Minden gyorsítással bekapcsolva is lassú volt, ezért döntöttem a dualboot mellett.

Ezt itt és most azonnal megvétóznám, egyrészt így tanultam ki magam is a zfs-t anno, mielőtt élesben elcsesznék valamit, (nem, nem kell alá tenger memória, a közhiedelemmel ellentétben), másrészt 1 szem vCPU-val és 1-2G RAM-al simán lehet php-zni, node.js-ezni és megannyi akár architekturális, akár backend és middleware fejlesztést és szimulációt csinálni. 8G RAM mellett ne mondd már, hogy nem tud az ember lecsípni némi RAM-ot és valami hasznosat alkotni, mert most azonnal magamhoz nyúlok és neeem akart megfulladni semmi, hogy nincs alatta 100 CPU mag..

Szerintem kicsit bőkezűen osztod az erőforrásokat, vagy csak nagyon egy irányba akarsz lőni ágyúval verébre. Értem én a nagyszerveresdit, de azért van a lónak túloldala is (ezt leírtam) + nyilván ki milyen jól lovagol, e kettő között még rengeteg lehetőség és tudnod kellene, melyik fázisban vagy éppen.

De egy webshopot, egy társkeresőt (nem azt, de hasonlót, mindegy), egy mittomén milyen dolgot, sok-sok egyéb komoly pénzcsináló projektet simán összerakok egy ilyen laptopon, egyet meg konkrétan a haverommal közös cégünknek rakott össze egy külsős fejlesztőbrigád és az egész motyó elfutna ezen az említett laptopon lazán, legalábbis a mostani 30-40 user-el (ha felfutott, az egy más téma, de itt már nem is csak DEV, hanem egyenesen UAT-ról beszélek).

Egy BSS stack-et már nem rakunk össze ezen, az igaz. Meg számlázórendszert sem, meg SAP gigainterfészeket sem. De az azért pont a ló túloldala, meg az ágyúval griffmadár kategória, itt most verébről volt szó végig.

És de, pont az InnoDB HA a másik, amit itthon teszteltem ki és paramétereztem mikor hogyan szénné, 3 kis VM-ben, előtte meg próbálgattuk a cégben még anno három másik soványka VM-en szintén, úgy kellett sírni a kapacitásért... de az MSSQL a másik akkor, ne csak szerencsétlen MySQL legyen mindig, itt sincs semmi dráma 3 ekkora VM-en egy Always On-t összelökni. Nem egy nagy sztori az egész, sem erőforrásban, sem konfigolásban, de igen, 3 csöpp VM-ben is elindul és tesztelhető, így tettük mi is. Tudod, írtam is, hogy PROD-ra semmiképp, de előtte.. na .. feltételezem, tisztában vagy a szoftverfejlesztés főbb állomásaival és az egyes állomások erőforrás igényével, szerintem nem kéne csodálkoznod, hogy tesztelésről van szó, igen, fejlesztői teszt DEV-en, egy ilyen laptopon, lazán. Előző munkahelyemen egy pénzügyi startup-nál giga portál tesztelődött ugyanígy lokál laptopon 8G RAM-al és ment fel utána a nagyvasakra következő fázisba, végül állt élesbe felhőben és csattantak rá többszázezren. Nincs ebben semmi különös, pedig ott azért nem a snake-et írogatták.

No offense, csak ne dobálózz már olyanokkal, hogy én dobálózok, egyrészt nem dobálózás, másrészt direkt hozok ilyen példát, mert mindenki - lásd, még egy szakmabéli is - azt gondolja, ezek ilyen ördögtől való boszorkánykonyha "atyaúristen" elérhetetlen szupertechnológiák, amiket ne lehetne ledemózni 3 csoffadt kis VM-en. Dehogynem lehet, röhögve, nekünk powerpoint helyett élesben ment az főnökök előtt, hogy kirúgtuk az egyik lábát és néztük, mikor hogyan viselkedik melyik node, később ugyanez durvább teljesítmény teszt alatt, meg még több tucat egyéb..

Most mi is 150+ magos dedikált farmon futtatjuk a motyót elképesztő mennyiségű RAM-al, de ez már más tészta. És 3 fentebb említett szaros kis VM juttatott minket oda, hogy elkezdjük ezeket tisztességesen kitesztelni, megnyúzni, agyonhajtani, használni, meg az én hajnalba nyúló óráim itthon az akkor még csöpp konfigomon, nem a consulting cég jött csillióért megmondani nekünk a tutit. Ja bocs, de, de ők azt se tudták, mi ez még tavaly és hoztak egy olyan megoldást elsőre, ami ugyan HA-t adott, de konzisztenciát nem, meg még pár egyéb dolgot sem.

Ne dobálózzunk olyanokkal, hogy mit lehet és mit nem, mert csak kreativitás és odafigyelés kérdése és nagyon sokmindent lehet.

POKE 16017,44 ..... SYS 2077

Mindegy, .. Nem téma.. mindenki abban hisz, amiben akar. Téma lezárva, Office meg Wine alatt bugos, free cuccok gondolom nem játszanak, így dualboot marad. Egészségedre

POKE 16017,44 ..... SYS 2077

Ha ilyeneket tesztelsz akkor én ebben a sorrendben próbálnám a virtualizációs cuccokat:

1, ESXi
2, VMware workstation Linux alatt
3, Hyper-V (tudom eretnekség ebben a topicban, de erre a tesztelésre teljesen jó és elég kicsi az overhead-je)

Nekem egy ezer éves Lenovo T430s-em van és 2-3 VM simán elmegy VMware workstation-el.

[ Szerkesztve ]

| MCSE+M/S, MCITP, VCP6.5-DCV - ''Life can be hard, but Scooter is harder :)'

vmware ws cégeknek fizetős.
esxi tudomásom szerint nem ingyen van.
hyper-v... offtopic.

ha ilyesmit tesztelni kell, akkor nekem először a xen jut eszembe, másodiknak a kvm.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Nekem meg elsőnek a KVM. Xen csak akkor, ha nem akar valaki még host OS-t is telepíteni, meg konfigurálgatni. De teljesen jó a KVM, nem kell semmilyen extra virtualizációs szoftver, pláne nem fizetős. Ott a KVM a kernelben, azt lehet használni QEMU-ban, tökéletes kombináció ilyen tanulásra szánt VM-ekhez, még a VT-x, VT-d is támogatott benne, ha a gép is támogatja, akkor simán megy.

A Hyper-V-t kipróbáltam anno sima desktop Win10 Prof-on, 64 bitesen, 2. gen i7-es laptopon, hát, lomha, lassú fosch az egész, de a MS-tól nem is vártam mást. Akkora overheadje van, mint az állat (ThinkPad X220 i7-2620M + 16 GB RAM mellett próbáltam). Ezt max. az ellenségemnek ajánlanám. Ha Windowson akar valaki hobbi VM-ezni, akkor VirtualBox, ha az nem tűnik elég stabilnak a feladathoz, akkor VMware Workstation ingyenes verzió.

(#30106) Dißnäëß: de én pont azt mondom, hogy én nem fukarkodnék, ha már virtuális gép, főleg szerver (vagy nem szerver, de valami modern desktop OS), én alapból min. 4GB-ot adok neki RAM-nak, és min. 2 prociszálat. Ezeket emelem is, ha szükséges, mert nem fut kielégítő sebességgel. 1 szál, meg 1 GB RAM nevetséges, annyit max. ilyen retro Win9x-es virtuális gépnek adnék, esetleg WinNT4, Win2k-hoz, de már utóbbiakhoz is belőnék 2 szálat, mert tudják kezelni.

[ Szerkesztve ]

a xen nem fizetős és ott van a kernelben.
minden processzoron fut, azon is, amin a kvm nem.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Én úgy tudom, hogy dedup-hoz kell csak sok memória hozzá, ha azt kikapcsolod, akkor egész szolidan eszik. De még csak tanulom ezeket a fájlrendszereket. Esetleg tudnál írni valamit a tényleges memória használatáról a zfs-nek, btrfs-nek, ilyesmiknek pl ext4-hez képest?

Buliban hasznos! =]

Ezt nem tudtam, hogy az is ott van a kernelben. Akkor lehet kipróbálom azt is. Én eddig úgy tudtam, hogy a Xen-t külön fel kell telepíteni.

(#30112) inf3rno: ezt teljesen jól tudod. De ha már VM-ben próbálgat valaki, akkor valós szimulációként próbálkozzon, és maradjon a dedup, cow, tömörítés, mindenféle redundancia stb. bekapcsolva. Ahogy kikapcsolgatsz mindent, meg ilyen minimalista ideálkörnyezetben próbálkozol, az nem fogja visszaadni, amit majd a valóságban tapasztalsz.

Jó, de a kérdés nem ez volt. Én simán kikapcsolom a dedupot az itthoni gépen, hogy ne kelljen emiatt ramot vennem, az élesen meg úgyis lesz, ha szükség van rá. A kérdés, hogy mennyi az annyi? 2GB elég neki pl 1TB tárhelyen, vagy több kell, esetleg kevesebb?

Buliban hasznos! =]

Kis segítség kellene. Ez a fail2ban beállítás jó lehet így?

/etc/fail2ban/jail.local

[DEFAULT]
ignoreip = 127.0.0.1/8
bantime = 1800
findtime = 600
maxretry = 10

[ssh]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log

Jónak tűnik, de a legtisztább, ha leteszteled magadnak: megpróbálsz belépni rossz usernévvel/jelszóval 1 percen belül több, mint 10 alkalommal.

Tesztelési időszakra én a bantime-t visszavenném 1 percre

Lassú a mobilinterneted? 4G/LTE antennák, közvetlenül raktárról ---> http://bit.ly/LTE_Antennak

Fail2ban-nak nincs értelme, de ha jobb érzésed van tőle, használd.

while (!sleep) sheep++;

Megindokolnád, hogy miért?

Lassú a mobilinterneted? 4G/LTE antennák, közvetlenül raktárról ---> http://bit.ly/LTE_Antennak

Mi ellen ad vedelmet?

while (!sleep) sheep++;

tévedés.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

+1
+bambano is megindokolhatná és akkor tanulhatnék valami újat!

- ha nincs jelszavas bejelentkezes, es a privkey nem kerult ki, akkor probalkozhatnak vegtelensegig az ssh-val, nem fognak bejonni
- ha gyenge a jelszo, es tenyleg be akarnak jonni, akkor be fognak jonni
- ha csak szokasos botnetes scan van, akkor kiprobalnak 30, 50, 100 jelszot, es utana mennek a fenebe (de egyebkent is tobb IP cimrol fognak jonni)

... cserebe +1 konfiguralando szolgaltatas, es rossz esetben pont akkor zarod ki magad, amikor nem kene

Tehat az az info kellene, h a fail2ban miert ad plusz biztonsagot, mi ellen ved. Mert szerintem nincs olyan realis tamadasi vektor, ami ellen a fail2ban hatekony. Cafoljatok meg.

[ Szerkesztve ]

while (!sleep) sheep++;

Mitol jobb, mintha nem lenne? Remelhetoleg nem 1234 a root password ssh-n keresztul, ha meg kulccsal kell bejonni, akkor meg az SSH se engedi be a botokat.

while (!sleep) sheep++;

nem hiszem, hogy indokolni kellene
minden plusz, amit a védelem kedvéért teszel, segít.
ráadásul a fail2ban nem csak ssh-hoz jó, hanem levelezéshez, web cuccokhoz, meg sok más mindenhez is.

kellően alacsonyra véve a limiteket, ad védelmet a próbálkozások ellen. pl. ha 3 rontott próbálkozás után repül az ip cím, de nem 5 percre, hanem mondjuk 8 órára, az segít.

értelemszerűen abból a nézőpontból, hogy kizárólag fail2ban-ra alapozni a védelmet, jogos lehet a kritika.

persze én, mint internet szolgáltató rendszergazdája, én csak a logjaim alapján tudok vitatkozni, mások érzelmeiről nincs objektív infóm.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Ird le legyszi, hogy a konkret esetben (ssh, pwd auth nelkul) milyen kockazatot csokkent.

[ Szerkesztve ]

while (!sleep) sheep++;

Figy, ezen ne vesszünk össze, mindenki olyan autót vesz és azt tesz vele, amit akar

POKE 16017,44 ..... SYS 2077

Köszi!

Én személy szerint engednék vagy 8 próbálkozást, hogy hátha elgépelném a jelszót. Volt rá példa.

ráadásul a fail2ban nem csak ssh-hoz jó, hanem levelezéshez, web cuccokhoz, meg sok más mindenhez is.

Itt a lényeg. Nálam pl. a WordPress logint védi meg igen csak hatékonyan a próbálkozók ellen, akik ráadásul ezzel feleslegesen terhelnék a szerver erőforrásait.

Lassú a mobilinterneted? 4G/LTE antennák, közvetlenül raktárról ---> http://bit.ly/LTE_Antennak

Így van, csak dedup, amit ritkán ajánlanak hogy használva legyen, totál felhasználásfüggő. Legalábbis ZFS fronton a "földi halandó" ne dedup-al kezdje. Egy médiafájlokat tartalmazó fájlrendszeren, ahol - feltehetően - nincs két egyforma fájl, se alatta lévő blokk, meg úgy semmi sem, teljesen felesleges és memóriafaló. Compression szintén nagyon függ sokmindentől, be is lehet kapcsolva (úgysem tömörít pl. már eleve tömörített fájlokat, lásd megint a híres média fájlok, FLAC-ok, mkv-k, stb), de nálam pl. a fontos fájlokat és vegyesbazár mindenfélémet tartalmazó mirror-on be van kapcsolva, míg a nagy médiafájlokat tartalmazó raidz-men kikapcsoltam már kreáláskor (ez kihatással van nem csak a puszta tényre, hogy tömörítve van-e adat, hanem arra is, hogy a blokkméretek fixek, vagy változóak). ZFS fine tune-ról külön könyvet lehetne írni, ezt sokan mondják és én is így látom.. nagyon mélyvíz és nagyon eltérően viselkedő megoldás ahhoz, hogy csak úgy általánosan egy skatulyába téve kijelentsünk róla dolgokat úgy, mint egy ext4-ről mondjuk. De a generalizálással mindig is gondja van az emberiségnek, törekszik mindenki az egyszerű dolgokra, na a ZFS nem az De öröm az ürömben, hogy default beállításban is egész vállalhatóan műxik és amire létre lett hozva, az adat integritás garantálása, arra hibátlan. (1 lemeznél tudja jelezni a hibát, 2 vagy több esetén egy raid felállásban már korrigálni is). Az említett COW is fura így megemlítve, ugyanis a zfs alapból cow-s, ez a default másik jellemzője (ezért is SSD barát, ZOL TRIM támogatás hiánya ellenére - de már dolgoznak azon is). Meg nem csak fájlrendszer, hanem logikai kötetkezelő is egyben, kicsit LVM szagú.

Dedup nélkül a zfs nem eszik sokat, csak valamivel többet, az ARC miatt (is), de az pl. paraméterezhető, ha a default beállítás nem tetszik, viszont dedup nyilvántartó táblák komplett kiesnek a képletből, default install és használat, pool/dataset creation esetén sincs bekapcsolva, jobbnak látta mindenki ezt off-ban tartani, enterprise felhasználásban egy (vagy több) dedikált storage admin ember már feltehetően még nálunk is jobban tudják, mit csinálnak és miért, ha szakértői a ZFS-nek és bekacsolhatják a dedup-ot.

ZFS-ről csinált egy marhajó összefoglalót stopperos fórumtárs, [link] , aminek már megírtam egy 2., gyakorlati részét jómagam, majd hamarosan publikálom talán. Lesz benne kicsiben is, VM-ben elpróbált játékok, meg a saját nagyobb példám is. Valamikor..

Nálam itthon 24 terányi diszk van különféle konstellációkban ZFS-re befogva, eddig nagyon elégedett vagyok vele. Nemsokára jönnek a cache drive-ok is, két enterprise grade SSD személyében, szóval egy egész pattogós házi storage motyó áll össze, de most sem panaszkodom. Talán idén át tudom a mostani workstation PC-met konvertálni egy igazi komoly storage vassá, egy új rack házikóban, ez még a jövő zenéje.

Az ARC mérete általában a rendelkezésre álló RAM /2 -ig mehet max, nálam most reggel óta van bekapcsolva a gép és 32G RAM-ból 5.76G foglalt, ebből a linux szerint 1.5G a buffer/cache és mérete a ZFS-ről történő olvasás és ráírás ellenére nem látszik változni perpillanat.

POKE 16017,44 ..... SYS 2077

Még annyit, hogy nagyon figyelmesen olvasd el stopperos összefoglalóját, amit linkeltem előzőben. Arany Lesz benne érintve memória is, struktúra is, minden ilyesmi.

Nem ez lesz az első 1-2 pool-od ma megkreálva, ami életed legjobban agyonoptimalizáltja lesz de nem elméleti fizika azért.

POKE 16017,44 ..... SYS 2077

Hát ha van root login meg jelszó az már régen rossz...

Buliban hasznos! =]

Okés, köszi!

Buliban hasznos! =]

Sziasztok
Szeretném módosítani az urllib2.pyo-t. Meg is történt,de írás védelem miatt nem tudom visszamásolni. Ebben szeretnék segítséget kérni. Köszönöm
mount -o remount,rw /usr/lib/python2.7
cp -R /storage/downloads/urllib2.pyo /usr/lib/python2.7/urllib2.pyo
mount -o remount,rw /usr/lib/python2.7
mount: can’t find /usr/lib/python2.7 in /proc/mounts

Coreelec 9.2.2 rendszer egy X96 MAX Plus Amlogic S905x3 Android 9.0 4GB/64GB DUAL Gig LAN set top box-ra van telepítve.

Tanulok mindig. Okulok - Szerelek. --> nrg_52 Ez csak az aláírásom. Nem mindig sikerülhet az életben amit szeretnél. De ha közel vagy hozzá már fél siker. Nekem egy célom volt a család. És megkaptam. Ezen felül már csak grátisz az élet.

Nem a fájlt kell mountolni hanem az adott csatolási directoryt. Ha külön /usr van akkor azt.

Jester

"alapból úgyis zárva az SSH (példánál maradva) és port knocking-al, kopogtatva lehet kinyittatni azt ideiglenesen a host-al, az adott beérkezônek"

Nem teljesen világos, hogy ez alatt mit értettél. Ha csak ideiglenesen van nyitva a port, miután bezáródik, nem fog működni az SSH, mert megszakad a kapcsolat. Vagy valamit nagyon nem értek a hálózati kommunikációból.

Ahogy nézem elképzelhető, hogy ez az iptables-es mókolás sem véd port scan ellen:: [link] Legalábbis azt írják, hogy úgy válaszol ezeknél a DROP-oknál a szerver, hogy azt mondja, hogy a szolgáltatás a port mögött éppen nem elérhető. Tehát annyi információ szivárogni fog, hogy melyik port mögött van szolgáltatás, de hozzáférni nem tudnak, ha nem ismerik a kopogási szekvenciát. Ebből viszont már tudnak következtetni arra, hogy kopogni kell, és vannak már botok arra, hogy brute force-al végigpróbálják. Arra jó, hogy még egy réteget beteszünk biztonsági szempontból az SSH fölé, de messze nem rejti el teljesen a szolgáltatásainkat és nem feltörhetetlen.

Tulképp ha a fenti igaz, és csak azokra a portokra tolunk port forwardot, amik a szekvencia részei, akkor baromi gyorsan fel lehet törni. Azt hiszem rászánom majd az időt, hogy demonstráljam. Egyelőre most vannak fontosabb dolgaim.

[ Szerkesztve ]

Buliban hasznos! =]

Sziasztok. Észrevettem az nginx esetében egy warn-t. Működés rendben, de valamiért az nginx -t command-ra az alábbi warn-t kapom:

$ sudo nginx -t
nginx: [warn] "ssl_stapling" ignored, issuer certificate not found for certificate "/etc/ssl/certs/nginx-selfsigned.crt"
nginx: [warn] "ssl_stapling" ignored, issuer certificate not found for certificate "/etc/ssl/certs/nginx-selfsigned.crt"
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Az nginx-selfsigned.crt megtalálható és benne van egy kulcs. Valami probléma van ezzel a kulccsal? Vagy ez csak arra utal, hogy saját magam által aláírt tanusítványt használok és ez a baja? Certbot esetén rendbejönne?

[ Szerkesztve ]

A második felvetésedre: hááát ez jó kérdés, iptables-ben (vagy még az elődjében, ipchains-ben) volt anno olyan target, hogy REJECT, talán ma is megvan még akármilyen okok miatt, na az viselkedik úgy, hogy elutasításkor visszajelez, hogy "ide nem jöhetsz be" , aminek puszta megtörténte miatt elárulva, hogy ott van gép, port, szolgáltatás, amit lehetne törni. Az akkoriban erre válaszul hozott DROP target már olyan végződtetés, hogy onnan semmi infó nem megy vissza a küldő fele, szóval mintha fekete lyuknak beszélne, DROP esetén nemigen tudja megállapítani, van-e ott valami vagy sem. Még TCP SYN dolgokkal bohóckodhat, de mindenre fel lehet készíteni egy gépet úgy megcsinálva, hogy távolról isten se mondja meg, hogy ott van valami az adott ip címen, hacsak nincs fizikai hozzáférése a network-höz.

Első felvetésed:
Ha csak ideiglenesen van nyitva a port, miután bezáródik, nem fog működni az SSH, mert megszakad a kapcsolat. Vagy valamit nagyon nem értek a hálózati kommunikációból.

Az, hogy egy port nyitva van-e, egy dolog. Arra is kihatásunk van, MIRE van nyitva. Egy nagyonegyszerű csecsemőbiztos példa most így fejből gyorsba, a teljesség igénye nélkül, csak az INPUT chain-re fókuszálva (pedig egy korrekt tűzfalban az OUTPUT is szűrve van, legalábbis akkor, ha magáról a tűzfal gép védelméről beszélünk.. ha a többiekéről, akkor meg a FORWARD mindkét iránya nat mangle és egyéb táblákban is, felhasználástól függően).

Tehát egy marha primitív kézi fal arra a host-ra, amit védeni akarunk, és egy SSH-t beengedünk. Illetve a mi saját kimenő csomagjaink visszatérő lábát is különben semmit nem lehet erről nagyon csinálni azon kívül, hogy egy buta SSH kiszolgáló.
iptables -X
iptables -F
iptables -P INPUT DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j ACCEPT

És akkor a vastaggal emeltet lehet (igazából erősen illik) cizellálni, hogy source-ot adunk neki, egy adott ip-t vagy ip régiót, satöbbi.

Kérdésedre a válasz a state-ekben rejlik, azaz a 22-es port knocking alatt csukva marad NEW csomagok számára, de természetesen ha egy másik host már sikeresen bekopogott oda és kapcsolódva van, őt egy RELATED,ESTABLISHED szabály beengedi, ami generalizáltan, minden protokollra és minden source/destination portra értelmezve van. (Ezért nem szoktam használni ebben a formában, csak szűkítve, de akkor hasznos).

Ha csak 22-es portra akarunk kétszintű definíciót, ami beengedi a már felépült SSH-k visszatérő lábait, de újakat nem enged be korlátlanul:
iptables -A INPUT -p tcp --dport 22 -m limit --limit 10/s -m state --state NEW -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m state --state RELATED,ESTABLISHED -j ACCEPT

Ez minden 22-es portra érkező ÚJ kérést úgy enged be, hogy csak másodpercenként 10-et enged ebből, a többit dobja. Minden új kérésre érvényes, de csak újakra. Az alatta levő sor pedig korlát nélkül enged minden 22-es portra beeső SSH csomagot, aminek van egy korábbi kimenő párja a táblákban már, így ha egyszer kapcsolódott valaki, egy SSH fájlátvitel sem okoz limit miatt gondot, bármennyi csomaggal korlátlanul kommunikálhat az sshd-vel.. szóval RELATED,ESTABLISHED lábakat nem szokás (vagy csak nagyon paranoid esetben) limit-el ellátni, burst-re is ügyelve de arra most nem térek ki.

A port knocking NEW-ra értendő, hiszen nem egy korábban kiment csomagra adott válaszcsomag az, ami érkezik és kopogna be, hanem új csomag, amolyan azonosítatlan, követés nélküli akarna bejönni. Őt csak számolni kell, mint kopogásszámot, de dobja is DROP-ra, míg a szekvencia nem teljesül, ergo nem lesz kimenő lába, mindig minden "kopogó" csomag NEW-nak minősül.

Ha ezen dimenzió mentén nézed, máris nem lehet azt mondani, hogy nyitva egy port vagy zárva: van, amire nyitva, van, amire limitáltan nyitva és van, amire zárva.

A limit egyébként hasznos, de érdemes a burst-öt is definiálni az elején, illetve tudni azt, hogy ha a szabályban definiált limitet pont egy hülye bot, vagy akármi lezabálja, Te sem jössz be már

Csináltam egyszer olyat, amikor egy hobbigépem törni akarták (még kezdő szöcske koromban, amikor 22-esre tettem ki SSH-t a nagy világhálóra), hogy láttam a logokban a millió jelszópróbálkozást, auth-ot, úristen mondom mivanitt, bruteforce indult ellenem és úgy döntöttem, teszek 22-es portra NEW próbálkozásokra egy 3/m limitet, azaz 3 próbálkozás / perc, utána csőváz mindenkinek.

1x tudtam belépni, utána kvázi örökre kizártam magam, mert a percenkénti 3-at elérte a próbálkozások száma a botok által, a fal zárt, én meg ugyanúgy kint maradtam egy putty zárás és újranyitás után

Szóval mindenre a limit sem megoldás, de mondjuk túlterhelések ellen egy egészséges mérték beállítása jó lehet, ami azon képzeletbeli határ felett van, ahányan akarnak oda jönni amúgy, botokkal együtt. Meg általában ezek a zombi gépek, botok, akármik többnyire 22-es porton kopognak, tehát ha a 22-est vagy az sshd-ban, vagy iptables-en keresztül nem 22-re rakod ki a publik interfészen, hanem valami tökmáson (1024 felett lehetőleg), az sokat segít. (Persze ne híres port legyen lehetőleg). SSH esetében úgy tudom kell induláskor a root jog, de egyébként ha most IRC szervert vagy akármi egyéb alkalmazást akarnál kitenni a netre, mindenképp 1024 fölé érdemes tenni, mert 1024-es alatti portokhoz root jog szükséges, azt meg nem akarjuk odaadni minden processznek (hacsak fel nem vesz utána nobody-t stb, de az megint más tészta). Azt vettem észre mindenesetre, hogy 22-ről ha elviszed SSH-t bármilyen módszerrel is, drasztikusan lecsökkennek az auth próbálkozások számai. Ez még nem jelent semmit, csak plussz háttérinfó, könnyítünk az sshd lelkén kicsit

Knocking esetén a NEW próbálkozások számát kell nézni, nem a RELATED,ESTABLISHED-eket, értelemszerűen. Utóbbiakból másodpercenként irdatlan sok jöhet és kell is bejönnie, lásd fájlátvitel, így a már felépült SSH kapcsolat nincs elkaszálva. NEW-val meg kopogjanak bátran, akinél teljesül, az eljut a szent grálhoz

POKE 16017,44 ..... SYS 2077

Nálam ennyiből áll az SSH védelem:

- Default portszám megváltoztatva (50000 feletti)
- Portscan Protection
- root felhasználó nem tud belépni, azon kívül is csak egy, teljesen másik usernevű
- 50 karakteres jelszó (kisbetű, nagybetű, szám)
- Fail2ban + aki root-al próbálkozik, azonnal ki van tiltva egy hétre

Ha ezen valaki átjön, egészségére

Lassú a mobilinterneted? 4G/LTE antennák, közvetlenül raktárról ---> http://bit.ly/LTE_Antennak

Tegyuk fel, hogy en

- nem valtoztatom meg a portot
- nem hasznalok fail2ban-t
- nem hasznalok portscan protectiont
- csak kulccsal lehet bejonni

Ez milyen szempontbol kevesbe biztonsagos, mint a te felallasod?

(Production kornyezetben mondjuk nincs is publikus IP cime azon szervereknek, ahol a cuccok futnak.)

[ Szerkesztve ]

while (!sleep) sheep++;

"Ha csak ideiglenesen van nyitva a port, miután bezáródik, nem fog működni az SSH, mert megszakad a kapcsolat.": ha előbb accepteled az establishedet meg a relatedet, és utána dobálod el a synt, akkor nem záródik be.

"csak azokra a portokra tolunk port forwardot, amik a szekvencia részei, akkor baromi gyorsan fel lehet törni.": ez önmagában igaz, csak kopogtatást nem így csinálnak. a szekvencia részeit képző portokra nem kell forward, ugyanúgy dropolod, mint a többit, csak másik ipset-be jegyzed fel.

[ Szerkesztve ]

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Köszi! Igy már jóval világosabb. Erre a DROP témára rákérdeztem egy Q&A oldalon, hátha tudja valaki a választ. Ha nem, akkor majd kipróbálom az itthoni szerveren. Egyelőre most nem Linux van rajta, úgyhogy az iptables nem játszik, de szerintem van valami alternatíva, amivel meg lehet csinálni ugyanezt.

Buliban hasznos! =]

Ránézésre ez ennyit csinál, a többi meg körítés:

iptables port_scanners hash:ip family inet hashsize 32768 maxelem 65536 timeout 600
iptables scanned_ports hash:ip,port family inet hashsize 32768 maxelem 65536 timeout 60
iptables INPUT -m state --state INVALID -j DROP
iptables INPUT -m state --state NEW -m set ! --match-set scanned_ports src,dst -m hashlimit --hashlimit-above 1/hour --hashlimit-burst 5 --hashlimit-mode srcip --hashlimit-name portscan --hashlimit-htable-expire 10000 -j SET --add-set port_scanners src --exist
iptables INPUT -m state --state NEW -m set --match-set port_scanners src -j DROP
iptables INPUT -m state --state NEW -j SET --add-set scanned_ports src,dst

Azért én óvatosabb lennék a helyedben az ilyen scriptekkel, mert ezzel gyakorlatilag átadtad az irányítást a géped felett a script írójának [link] Aztán erősen bízol benne, hogy a következő release nem támadókódot tartalmaz.

Buliban hasznos! =]

Ezt én írtam Így nyilván megbízom abban, amit a saját gépeimen is futtatok.

Lassú a mobilinterneted? 4G/LTE antennák, közvetlenül raktárról ---> http://bit.ly/LTE_Antennak

Ja így világos.

Buliban hasznos! =]

Látom jó kis egészséges vita alakult ki REJECT és DROP körül az általad linkelt fórumon.
man iptables -ben a REJECT target írója Jozsef Kadlecsik, lehet elő tudnád ásni az arcot, ha utánajárnál. Nála lesz olyan infó, ami ÚGY VAN és 100% hihető, feltételezem (ha 1. a Netfilter csapat tagja, 2. ő írta a REJECT-et).

De amúgy meg azt is látom, hogy az iptables is kifutó lassan, itt az nftables helyette: [link]
Picit más szintaktika és logika, de többet tud + teljesítményben is jobb. Lehet érdemes lenne erre felülni, mielőtt túlzottan kitanulod az iptables-t. (Én meg ipchains-el szívtam anno sokat és iptables-ön tanultam. Nem kell egyik a másikhoz, most sem kell iptables mester lenni, hogy nftable guru legyél.. ha már kézzel írogatunk) .

POKE 16017,44 ..... SYS 2077

Ja ezt úgy érted, hogyha a routeren fut az iptables? Én úgy értettem, hogy a szerver gépen fut, és a router oda forwardolja, amivel dolgoznia kell.

Buliban hasznos! =]