sshd bombázás

én, békés csávó lévén, egyszerűen áttettem a sshd-t más portra.

Ami nálam bevált, 2.6-os kernelnél:

/sbin/modprobe ipt_recent (Mivel ez nem volt betöltve, ezért nem ment, sry, i'm lol.)

# $IPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -A INPUT -p TCP -s innenmehetekezerrel --syn --dport ssh -j ACCEPT
$IPT -A INPUT -p TCP --syn --dport ssh -m recent --update --seconds 600 --hitcount 3 -j DROP
$IPT -A INPUT -p TCP --syn --dport ssh -m recent --set -j ACCEPT

Nekem az első sor nem kell, mert máshol már megvan adva.
Ha átírod az sshd_config-ban a portot, akkor itt is írd át az ssh-t a portszámra, mert nekem ellenkező esetben nem működött (aszittem átveszi valahonnan a változást, de nem..).

Mivel a 2.4-es kernel nem ismeri az ipt_recentet, ne felejtsd el betölteni:

/sbin/modprobe ipt_limit

S mehet a másik:
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p TCP -s fehérlistázandó_IP_cím -m state --state NEW --dport ssh -j ACCEPT
iptables -A INPUT -p TCP --dport ssh -m limit --limit 3/min -m state --state NEW -j ACCEPT
iptables -A INPUT -p TCP -m state --state NEW --dport ssh -j DROP

Remélem tudtam kicsit segíteni neked is..
Ha nagyon egyértelmű dolgokat írtam sorry, de az iptables a halálom..

"de szeretném megtudni, hogy milyen script-el, vagy milyen programmal csinálják ezt.Bevallom azzak a szándékkal, hogy egy kicsit visszavágjak ;-o"

Szerintem ne akarj vagdalkozni, nem vagy Te olyan combos... Ambar mindenki ugy veri a sajat faxat a csalanba, ahugy akarja.

Valtoztass inkabb portot, vagy szurj ip-re.

"Illetve érdekelni, hogy a "rootkit" szó mit takar."

http://www.hup.hu/wiki/index.php/Rootkit

valoszinuleg az illeto admin azon az ip-n nem is tud rola, hogy tamadja a gepedet

en az adott ip abuse (vagy egyeb kontakt) email cimre irok egy mailt, hogy ez van, surgosen tegyen ellene. Plusz megy a logreszlet is.

Van persze olyan, hogy nem valaszolnak, de sokszor van olyan is, hogy megkoszonik, hogy szoltam :), es megszunik a tamadas

talan ez jo megoldas amellett, hogy atteszitek masik portra, mert igy majd mast fognak tamadni.

persze lehet sz*rni a masikra, de hosszutavon az biztos, hogy te is rosszul jarsz.

nem mondom, hogy aldozat, de eleg jo esely van ra...

en legalabbis tobb ilyennel talalkozom, mint amikor szandekosan akarjak torni a gepet.

T-Online Adatparkos haverom (is) tudna meselni, mekkora "tudassal" raknak ki szervereket a netre...

feltorik, aztan valami rootkitet dobnak ra, hogy a kezdo admin lehetoleg ne vegye eszre mondjuk a process list -ben, hogy ok ott garazdalkodnanak es maris lehet probalkozni egy masik geppel

Már megint az übertolerancia. Ha egyszer bombáz, mit érdekel engem, hogy büdös cracker vagy szerencsétlen áldozat, _hagyja_abba_. ("Klémor vót a kezibe, azt néztem, nem a képit! - Angus MacLeod, Hegylakó)
Amíg két-három ilyen fut be havonta, addig ok, kitiltja az ember IP alapján, de ha már napi 30-40 ilyen lesz, akkor már kissé unalmas lesz bogarászni a logokat meg túrni az iptables config-ját, persze lehet automatizálni, de a 2000. felvett iptables szabály után nézd meg az átviteli idődet.
Tehát le kell állítani, no de hogyan? Visszakeresni az ip-ből a láncban legalsó szolgáltatót, email neki, h. légyszi menj már oda és vágd már tarkón a kötsögöt a postakábellel, persze, de a 100-200. esetben unalmas.
RBL-szerűség max. úgy menne, hogy ha >N ember jelentette be az adott ip-t, akkor megy a blacklistre, viszont erre lássuk be, kicsi az esély, ha pedig N kicsi, akkor vissza lehet vele élni.
Mi marad? Hát az aktív védekezés, amit a kolléga is felvetett: elő az exploitgyűjteményt, aztán lássuk, beleszakad-e, ki mit kap, az övé.
Jobb tipp?
Kíváncsi volnék, hogy a sávszélesség, számítási kapacitás ill. tárterület hány százaléka van mostanság beáldozva amiatt, hogy a kis suttyó kötsögök meg a spammerek gátlástalanok, mert senki sem csap a kezükre a franciakulccsal?

ha a 22 rol masik portra atteszed az sshd -t es megszunik a tamadas, akkor szinte biztos, h feltort geppel van dolgod amin valami script vagy script kiddie probalkozik valami "cracker programmal", mert ha tenyleg a te geped akarja feltorni, mennyibol tartana megallapitani, hogy nem a 22-esen van, hanem mondjuk a 622-n?

aki fel akar torni egy gepet, valoszinuleg ismeri az nmap-ot...

A port-átrakás nem megoldás, mert a gépet használóknak elég nehéz lesz meggyőzni az útba eső tűzfalak rendszergazdáit, hogy "Te öreg, a 22-t kiengeded, de a szerver adminja átrakta az 55555-re, ugyan nyisd már ki azt is légyszi"... Ha meg van egy hivatalos "alternate ssh" port, az meg semmit sem ér, mert a scriptkiddie természetszerűleg bombázza azt is. Security by obscurity, hmmm...
Kiegészítés:
Nekem nincs nyitva a http-m, mert elegem lett a napi párszáz kbyte logból, hogy épp milyen iis-specifikus buf ovf-et próbál belém tolni a scriptkiddie/worm/cracker (innentől: a szennyedék), csak https-en figyelek, mert hál'Istennek mondhatom, hogy ez van, ezt kell szeretni, de ez sem engedhető meg mindenhol. Pl. egy céges hálóból, ahol tartalomszűrés van a http-n, én sem engedném ki a https-t...

Irtam ra kis perl scriptet, logot nezi, ha valaki rossz juzerrel akar bejonni, mar benne is talalja magat az iptables feneketlen bugyraiban.

Amugy engem olyan szempontbol erdekelne a fenti script, hogy megnezzem, connect utan mennyi byte-ot var mennyi ideig, hogy eldontse, foglalkozik-e vele vagy sem. Esetleg kiadnam neki a "lophaszt a seggedbe" stringet 1 betu / ora sebesseggel.

A már behirdetett DSA-k:
http://www.nl.debian.org/security/

[quote:13e3d39080="lukit"]Irtam ra kis perl scriptet, logot nezi, ha valaki rossz juzerrel akar bejonni, mar benne is talalja magat az iptables feneketlen bugyraiban.

Próbaképpen tegyél be 1-2 ezer kamu címet szűrésre, és nézd meg a teljesítményesést a sok szabály miatt.
[quote:13e3d39080="lukit"]Esetleg kiadnam neki a "lophaszt a seggedbe" stringet 1 betu / ora sebesseggel.

Nem javasolnám, mert amíg a kapcsolat él, addig nálad is leeszik egy portot, abból meg ugye véges sok van. Akkor már inkább droppold ahogy van, vagy ha bőviben vagy sávszélességnek, akkor -t MIRROR :).

[quote:b23f47705e="gsimon"]Már megint az übertolerancia. Ha egyszer bombáz, mit érdekel engem, hogy büdös cracker vagy szerencsétlen áldozat, _hagyja_abba_. ("Klémor vót a kezibe, azt néztem, nem a képit! - Angus MacLeod, Hegylakó)
Amíg két-három ilyen fut be havonta, addig ok, kitiltja az ember IP alapján, de ha már napi 30-40 ilyen lesz, akkor már kissé unalmas lesz bogarászni a logokat meg túrni az iptables config-ját, persze lehet automatizálni, de a 2000. felvett iptables szabály után nézd meg az átviteli idődet.

NEM ubertolerancia. A TE erdeked, hogy abbamaradjon a tamadas. Ha te kiszurod az IP-jet, attol mast meg tamad. Es ha mast feltor, az a mas teged is tamadhat, tehat tilthatod ki azt az ip-t is, vegul mar valoban 2000 soros lesz az a chain amin a feketelistas ip-k vannak...

Plusz, azt irtam, hogy portatrakas/kiszures MELLETT.

kit erdekel ha gyulnek a logban a bejegyzesek? olcso a vinyo :)

Amugy meg ha ennyire zavar, akkor tedd at masik portra.

A legjobb megoldas amit lattam az azt csinalta, hogy egy webes kepernyon kellett bejelentkezned, es ha sikerult, akkor 2 percre kinyotta az ssh portot annak az ip-nek amirol csatlakoztal. A 2 perc utani visszazarodas persze a mar letrehozott kapcsolatokat nem gyilkolta le.

Ja igen, ha sok idod van irhatsz levelet a szolgaltatonak, es akkor legalabb megvan az az erzesed, hogy naprol napra jobb lesz toled a vilag. :)

[quote:04b9c9bbcf="gsimon"]Nem javasolnám, mert amíg a kapcsolat él, addig nálad is leeszik egy portot, abból meg ugye véges sok van. Akkor már inkább droppold ahogy van, vagy ha bőviben vagy sávszélességnek, akkor -t MIRROR :).

Tarpit az igazi :D

A mirrorral van egy kis gond. A támadó az X gépről indítja Y ál ip-címmel a gépedre. Te megfordítod, így a te gépedről az Y gépre fog menni. Na most az lehet bármilyen gép, és végül téged fognak - jó esetben csak - elővenni miatta. Persze előbb rá kell jönni, hogy mirrorozod...

[quote:04b1cf7f0b="1g0R"]Sziasztok,

Biztos ti is tapasztaltátok, hogy folyamatosan bombázzák az sshd-t, úgy hogy szinte másodpercenként ua. az IP ről, különböző usernévvel probálkoznak bejönni.
Találtam egy megoldást a védelemre (bár biztos van más is,http://denyhosts.sourceforge.net/), de szeretném megtudni, hogy milyen script-el, vagy milyen programmal csinálják ezt.Bevallom azzak a szándékkal, hogy egy kicsit visszavágjak ;-o
Illetve érdekelni, hogy a "rootkit" szó mit takar.
Köszönöm a segíŧséget.

nalam egy crontab csinalja ugy hogy a pf ben egy tableba bevagja orankent az uj ipket ahonnan jon az atack
amugy nincsen semmi jelentosege nem tudjak igy megtorni a servert csak utalom a logban azt a 100sort latni

[quote:b9b97fd1a5="nug"]Amugy meg ha ennyire zavar, akkor tedd at masik portra.

Nomégegyszer, úgy látszik, nem jól írtam:
Admin vagyok egy gépen, vannak usereim, akik azt használni szeretnék, és pont annyira tetszene nekik, ha heti min. 3 alkalommal telefonon értesíteném őket, hogy "Pelikán elvtárs, ma a 51523-as portra ssh-zzon", mint amennyire én szeretném őket végigértesítgetni.
Egy service - egy port, mégpedig a default. Userek, használni akarják, és nem nmap-pal keresgélni, hogy vajh ma hol az ssh.
[quote:b9b97fd1a5="nug"]
A legjobb megoldas amit lattam az azt csinalta, hogy egy webes kepernyon kellett bejelentkezned, es ha sikerult, akkor 2 percre kinyotta az ssh portot annak az ip-nek amirol csatlakoztal. A 2 perc utani visszazarodas persze a mar letrehozott kapcsolatokat nem gyilkolta le.

Ez viszont határozottan tetszik, köszi! Gyakorlatilag a webmail rendszerből is kinyerhető az adat, és akkor a user legalább egyúttal a leveleire is ránézhet. Nem is rossz!
[quote:b9b97fd1a5="nug"]Ja igen, ha sok idod van irhatsz levelet a szolgaltatonak, es akkor legalabb megvan az az erzesed, hogy naprol napra jobb lesz toled a vilag. :)

Áhh, csak eggyel több fölösleges levél van a neten. Jobb akkor lenne, ha személyesen megkeresném a szennyedéket és érvényesíteném rajta az elmaradt atyai szigort valamint a helyes viselkedés alapjaira vezető egyéb lépéseket :).

[quote:e7d29edaaa="Panther"]A mirrorral van egy kis gond. A támadó az X gépről indítja Y ál ip-címmel a gépedre. Te megfordítod, így a te gépedről az Y gépre fog menni. Na most az lehet bármilyen gép, és végül téged fognak - jó esetben csak - elővenni miatta. Persze előbb rá kell jönni, hogy mirrorozod...

Igazad van, kéne egy olyan target, ami a dest-ip-t a source-ip-re írja át, és úgy tolja vissza :)
Vissza komolyra, ami az én elővételemet illeti, még jogos is lenne, a kérdés viszont pont az, hogy és ezt hogyan? Mert ha szegény Y elő tud venni engem, akkor ugye pont ugyanúgy én is elővehetném X-et, és eszembe sem jutna mirrorozgatni. Egy dinamikus ip esetén meg nemigen van idő bírói végzésre meg a routerek végigjárására.

[quote:258527d506="gsimon"]
[quote:258527d506="nug"]Ja igen, ha sok idod van irhatsz levelet a szolgaltatonak, es akkor legalabb megvan az az erzesed, hogy naprol napra jobb lesz toled a vilag. :)

Áhh, csak eggyel több fölösleges levél van a neten. Jobb akkor lenne, ha személyesen megkeresném a szennyedéket és érvényesíteném rajta az elmaradt atyai szigort valamint a helyes viselkedés alapjaira vezető egyéb lépéseket :).

Nem ertem miert kell sok ido ehhez:

----
Tisztelt Szolgaltato/Rendszergazda!

A RIPE adatbazisa alapjan az On/onok szamara kiosztott x.x.x.x ip cimrol folyamatos betoresi kiserleteket latok az egyik szerverem ssh portjan.
Melleltem errol a logbejegyzeseket.
Kerem tegyek meg a szukseges lepeseket a tevekenyseg beszuntetesere mielobb!

Udvozlettel:
XY
Admin

Dear ISP/Admin!

Based on the RIPE database from one of your IP address I'm recieving persistent breaking attempts.
I've attached the log entries about these.
Please do what is necessary to stop this activity immediately!

Regards,
YX,
Admin
-----

lehet hogy nem valaszolnak, de ha igen, akkor legalabb egy geppel kevesebb lesz feltorve a neten.

Szerintem ez fontos dolog, es ez lenne minden - nem crackernek - az erdeke. Az igaz, hogy csinalni kell valamit. Aki erre lusta/nincs kedve/nincs ideje az ne tegye, de en nem gondolom, hogy ez olyan sok idot igenyelne...

[quote:2b9fa21320="gsimon"][quote:2b9fa21320="lukit"]Irtam ra kis perl scriptet, logot nezi, ha valaki rossz juzerrel akar bejonni, mar benne is talalja magat az iptables feneketlen bugyraiban.

Próbaképpen tegyél be 1-2 ezer kamu címet szűrésre, és nézd meg a teljesítményesést a sok szabály miatt.

Probakeppen 2-3 naponta kiuritem ... amugy sincs naponta 50 probalkozonal tobb.

[quote:e478190ea4="lukit"][quote:e478190ea4="gsimon"][quote:e478190ea4="lukit"]Irtam ra kis perl scriptet, logot nezi, ha valaki rossz juzerrel akar bejonni, mar benne is talalja magat az iptables feneketlen bugyraiban.

Próbaképpen tegyél be 1-2 ezer kamu címet szűrésre, és nézd meg a teljesítményesést a sok szabály miatt.

Probakeppen 2-3 naponta kiuritem ... amugy sincs naponta 50 probalkozonal tobb.

Különböző tényleg nincs. Na de egy gépről... A rekordom vhol 600 és 700 között volt. Tök jó, még én sem tudom a root jelszót a routeremen :P

[quote:379872069e="jaci"]Konkrétan végigolvastad??

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p TCP -s fehérlistázandó_IP_cím --syn --dport ssh -j ACCEPT
iptables -A INPUT -p TCP --syn --dport ssh -m recent --update --seconds 60 --hitcount 3 -j DROP
iptables -A INPUT -p TCP --syn --dport ssh -m recent --set -j ACCEPT

És ehhez képest a megoldásod mennyiben jobb:
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p TCP -s fehérlistázandó_IP_cím -m state --state NEW --dport ssh -j ACCEPT
iptables -A INPUT -p TCP --dport ssh -m limit --limit 3/min -m state --state NEW -j ACCEPT
iptables -A INPUT -p TCP -m state --state NEW --dport ssh -j DROP

valahol mintha lattam volna egy iptables peldat, hogy lehet ipre limitet rakni. Megisvan a patch-o-magicban van egy ilyen: hashlimit

This patch adds a new match called 'hashlimit'.
The idea is to have something like 'limit', but either per
destination-ip or per (destip,destport) tuple.

De ugyanilyen a connlimit is:

This adds an iptables match which allows you to restrict the
number of parallel TCP connections to a server per client IP address
(or address block).

tehat pl 5 csatlakozas/ip/perc + icmp-net-unreachable es kesz is :)

Nekem is van napi 3-4 probálkozás, de nem igazán tudok mit csinálni. :(
Viszonylag sok (2 naponta 1 :) jön a saját kiszolgálómtól, de ezek ip-it nem blokkolom, mert hátha legközelebb én kapom azt az ip-t, aztán nem tudok bejelentkezni. :)Küldtem már e-mail -t rendszergazdáknak, de sz*rnak rá... :( Annyi maradt, hogy bízom a saját passwd-ömben, meg a szerencsémben. Havonta váltok password-öt. Ha több lesz a probálkozás rászokok a hetire. ( Csak akkor már fel kell írni :) )

Sz.

Udv,

Tegnap en is kutakodtam a temaban, ugyanis engem is zavar, hogy naponta terhelik a vonalamat az ilyen probalkozasokkal. Szemely szerint egy olyan eszkozt tartanek idealisnak, amelyik meg tudja szamolni, hogy x idon belul y teves azonositasi kerelem erkezett, majd ez alapjan ha eleri a limitet, akkor programot tudna futtatni (a program egy shell szkript lenne, ami a ki es a bejovo forgalmat az iptables DROP szabalyara iranyitana az adott iprol).
Jah es meg valami - az volna jo, ha a program a syslogd kimenetet olvasna - ugyanis akkor nem csak erre lehetne a kesobbiekben megtanitani.

Tud valaki ilyen eszkozt?

En csak arra talaltam megoldast, hogy hogyan lehetne megirni, sajnos erre az elkovetkezendo ket hetben meg egyelore nem nagyon lesz idom.

Hijaszu

Root user tiltása, idétlen nevű normál user, jelszavas authentikáció tiltása. Jöhet a jelszóval védett publikus kulcsos hitelesítés. Azt törjék fel :)

[quote:26cfa91f96="Hijaszu"]

En csak arra talaltam megoldast, hogy hogyan lehetne megirni, sajnos erre az elkovetkezendo ket hetben meg egyelore nem nagyon lesz idom.

Hijaszu

Linket tudsz adni?

Erről már volt szó itt:
http://hup.hu/modules.php?name=News&file=article&sid=7716

Ez a limites megoldás nekem is bejött, 3 próbálkozás után 10 percre tiltva van.. Még egy se jött vissza utána próbálkozni...

http://logspy.sourceforge.net/docs.html

Ezen az oldalon le van irva, fifot kell csinalni es arra egy programot ratelepiteni. Elvileg az itt talalhato program is lehet meg tudna oldani a feladatot - de jelenleg nem ugy nez ki mintha nagyon keszen lenne.

Hijaszu

[quote:74034d0c88="jaci"]Konkrétan végigolvastad??

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p TCP -s fehérlistázandó_IP_cím --syn --dport ssh -j ACCEPT
iptables -A INPUT -p TCP --syn --dport ssh -m recent --update --seconds 60 --hitcount 3 -j DROP
iptables -A INPUT -p TCP --syn --dport ssh -m recent --set -j ACCEPT

Kiégett a szemem, de nem találom, hogy ez hol van leírva...

[quote:ca691e0ed6="Frimen"][quote:ca691e0ed6="1g0R"]Sziasztok,
Biztos ti is tapasztaltátok, hogy folyamatosan bombázzák az sshd-t..

Szerintem a legjobb megoldás bezárni minden portot.
Ha el akarod érni a "szervert" akkor odarohansz hozzá,
megnyitod a portot..:))
Persze miután kijátszottad magad visszarohansz és bezárod.:))
Ha elég gyors vagy, akkor a rohangálások alatt kcisi az esély,
hogy megtörjék a szervert.:))
Nekem ez bevált.:))
Fri

Lehet nyitogatni a knockd -al is.
http://www.zeroflux.org/cgi-bin/cvstrac/knock/wiki

[quote:18d108019d="Panther"][quote:18d108019d="lukit"][quote:18d108019d="gsimon"][quote:18d108019d="lukit"]Irtam ra kis perl scriptet, logot nezi, ha valaki rossz juzerrel akar bejonni, mar benne is talalja magat az iptables feneketlen bugyraiban.

Próbaképpen tegyél be 1-2 ezer kamu címet szűrésre, és nézd meg a teljesítményesést a sok szabály miatt.

Probakeppen 2-3 naponta kiuritem ... amugy sincs naponta 50 probalkozonal tobb.

Különböző tényleg nincs. Na de egy gépről... A rekordom vhol 600 és 700 között volt. Tök jó, még én sem tudom a root jelszót a routeremen :P

No de ha mar eccer beprobalkozik, vagja is ki iptables-el, teccikerteni?:) Arrol az IP-rol 1 ideig biztos nem lesz mas.

A knock nem tul jo, ha:
-el vagy rejtve egy masik fw moge, tehat a portjaid forwaldolva vannak, mert akkor csak forwardolt portokra knockolhatsz-> tele lesz a logja kezdemenyezesekkel...(jah, logrotate stb, tudom, de akkor is)
-ha egzotikus portokat valasztasz, es pl internetkavezobol, vagy T-DSL firewall mogul akarsz bemenni, jah, az default konfiggal nem enged ki... es lusta vagy konfiguralni, vagy.....

en sokkal jobb utat valasztottam: a port zarva, meg kell nezned egy weboldalt, es akkor nyilik REMOTE_ADDRESS fele a port egy idore.
azota napi >100 rol nulla probalkozas erdekes modon ;-D

Nálam többet soha. Néha optimalizálom a blakclistemet, és teljes hálót tiltok :P SSH-nál lehet, más szolgáltatásnál csak időszakos tiltás a működőképes.

Oksa, köszönöm, a hozzászólásokban megtalálható.
Csak itt nem néztem.. :)

[quote:dbe1e88179="jaci"]Erről már volt szó itt:
http://hup.hu/modules.php?name=News&file=article&sid=7716

Ez a limites megoldás nekem is bejött, 3 próbálkozás után 10 percre tiltva van.. Még egy se jött vissza utána próbálkozni...

Én keményebb vagyok 3 próbálkozás után 1 óra tiltás.
Az elején naponta többezer usernév/jelszó próbát kaptam, ma már összesen valami 10-12 db-ot.

Na és akkor ez miért nem működik az alábbi formában?
(bár bevallom, nem erősségem az iptables. Sőt.. :(

Ezzel bővítettem a tűzfalat, s most belépni se enged, a log szerint eldobja a 22-es portra érkező kéréséket, még mielőtt kérné a usert:

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p TCP --syn --destination-port 22 -m recent --update --seconds 180 --hitcount 3 -j DROP
$IPT -A INPUT -p TCP --syn --destination-port 22 -m recent --set -j ACCEPT

Maga a tűzfal ide tartozó része:

$IPT -A bad_packets -p ALL -m state --state INVALID -j LOG \
--log-prefix "fp=bad_packets:1 a=DROP "
$IPT -A bad_packets -p ALL -m state --state INVALID -j DROP
$IPT -A bad_packets -p tcp -j bad_tcp_packets
$IPT -A bad_packets -p ALL -j RETURN
$IPT -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j LOG \
--log-prefix "fp=bad_tcp_packets:1 a=DROP "
$IPT -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j DROP
$IPT -A bad_tcp_packets -p tcp --tcp-flags ALL NONE -j LOG \
--log-prefix "fp=bad_tcp_packets:2 a=DROP "
$IPT -A bad_tcp_packets -p tcp --tcp-flags ALL NONE -j DROP
$IPT -A bad_tcp_packets -p tcp --tcp-flags ALL ALL -j LOG \
--log-prefix "fp=bad_tcp_packets:3 a=DROP "
$IPT -A bad_tcp_packets -p tcp --tcp-flags ALL ALL -j DROP
$IPT -A bad_tcp_packets -p tcp --tcp-flags ALL FIN,URG,PSH -j LOG \
--log-prefix "fp=bad_tcp_packets:4 a=DROP "
$IPT -A bad_tcp_packets -p tcp --tcp-flags ALL FIN,URG,PSH -j DROP
$IPT -A bad_tcp_packets -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j LOG \
--log-prefix "fp=bad_tcp_packets:5 a=DROP "
$IPT -A bad_tcp_packets -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP
$IPT -A bad_tcp_packets -p tcp --tcp-flags SYN,RST SYN,RST -j LOG \
--log-prefix "fp=bad_tcp_packets:6 a=DROP "
$IPT -A bad_tcp_packets -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
$IPT -A bad_tcp_packets -p tcp --tcp-flags SYN,FIN SYN,FIN -j LOG \
--log-prefix "fp=bad_tcp_packets:7 a=DROP "
$IPT -A bad_tcp_packets -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
$IPT -A bad_tcp_packets -p tcp -j RETURN

# sshd
$IPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -A INPUT -p TCP -s az.en.ip.m --syn --destination-port 22 -j ACCEPT
$IPT -A INPUT -p TCP --syn --destination-port 22 -m recent --update --seconds 60 --hitcount 3 -j DROP
$IPT -A INPUT -p TCP --syn --destination-port 22 -m recent --set -j ACCEPT
$IPT -A tcp_inbound -p TCP -j RETURN
$IPT -A tcp_outbound -p TCP -s 0/0 -j ACCEPT

$IPT -A INPUT -p ALL -i $LO_IFACE -j ACCEPT
$IPT -A INPUT -p ALL -j bad_packets
$IPT -A INPUT -p ALL -d 224.0.0.1 -j DROP
# $IPT -A INPUT -p ALL -d 224.0.0.1 -j ACCEPT

# Inbound Internet Packet

$IPT -A INPUT -p ALL -i $INET_IFACE -m state --state ESTABLISHED,RELATED \
-j ACCEPT

# Route the rest to the appropriate user chain
$IPT -A INPUT -p TCP -i $INET_IFACE -j tcp_inbound
$IPT -A INPUT -p UDP -i $INET_IFACE -j udp_inbound
$IPT -A INPUT -p ICMP -i $INET_IFACE -j icmp_packets
$IPT -A INPUT -m pkttype --pkt-type broadcast -j DROP
$IPT -A INPUT -j LOG --log-prefix "fp=INPUT:99 a=DROP "
$IPT -A OUTPUT -m state -p icmp --state INVALID -j DROP

# Localhost
$IPT -A OUTPUT -p ALL -s $LO_IP -j ACCEPT
$IPT -A OUTPUT -p ALL -o $LO_IFACE -j ACCEPT
$IPT -A OUTPUT -p ALL -o $INET_IFACE -j ACCEPT
$IPT -A OUTPUT -j LOG --log-prefix "fp=OUTPUT:99 a=DROP "

Helló!

Én a lejobb megoldásnak azt tartom, hogy iptables-ben input-ot DROP-ra állítom majd engedélyezem azokat a tarományokat/ip-ket, amikről jöhetnek a júzerek, így ha belegondoltok sokkal jobb min egyesével tíltani minden rosszindulatut. Ugyan ez vonatkozik nálam http-re is bár én nem céges servert gazdizom csak a sajátomat. Ha meg azt nem akarjátok akkor meg kinyitod és sanyi.

Könnyebb megoldás mint minden címet tíltani, persze ez nem vonatkozik olyan szerverekre ahhol 50-júzernél többen vannak bár lehet akkor tartományok megadása lehet lecsökkenti a bejegyzések számát. És ha azon bellül érkezik támadás akkor őt lehet külön tíltani.

Nekem ez a meglátásom miután beleuntam én is az tartomány tiltásokba mert én nem szarakodtam ip-kel.

Sziasztok!

Hm. Reszletezned? :wink:

Frimen. Erről eszembe jutott egy ma olvasott vicc.
Íme:
http://www.hup.hu/modules.php?name=Forums&file=viewtopic&p=83342#83342

[quote:3a704756f1="Hijaszu"]Udv,

Tud valaki ilyen eszkozt?

Hijaszu

http://denyhosts.sourceforge.net/features.html

Ez valami hasonlo. Esetleg bejohet.

ha kevesen használják az ssh t érdemes átteni egy másik portra!!!
én így oldottam meg mert nekem megfelelő volt így is, ha csak pár embernek kell ssh ez müxik, persze valahol tiltják tűzfalon hogy csak szabvány porton lehet kifelé kapcsolodni, akkor ez nem jó...

Én magam is így gondolom. Átteszem másik portra, de ha valami/valaki megtalálná, s elkezdene próbálkozni, akkor nem baj egy másodlagos védelem.
Épp csak nem müxik ez a nyavajás..
Ha beteszem az ip-t engedélyezettek közé, akkor játszhatok a végtelenségig a usernevekkel, de ha nem, akkor se putty, se winscp alól nem tudok belépni, be se jön a beléptető ablak.. :(

[quote:7553abe0d5="1g0R"]Sziasztok,

Biztos ti is tapasztaltátok, hogy folyamatosan bombázzák az sshd-t, úgy hogy szinte másodpercenként ua. az IP ről, különböző usernévvel probálkoznak bejönni.
Találtam egy megoldást a védelemre (bár biztos van más is,http://denyhosts.sourceforge.net/), de szeretném megtudni, hogy milyen script-el, vagy milyen programmal csinálják ezt.Bevallom azzak a szándékkal, hogy egy kicsit visszavágjak ;-o
Illetve érdekelni, hogy a "rootkit" szó mit takar.
Köszönöm a segíŧséget.

Előtte 2 dologról gondolkodj el:
1.) Könnyen lehet, hogy az adott ip mögött lévő gép gazdája mitsem tud arról, hogy mire használják a gépét.
2.) Spoof-olt ip esetén be is szivathatod magad egy bosszuló script-tel.

Üdv,
Dw.

[quote:169faa7157="jaci"]Konkrétan végigolvastad??

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p TCP -s fehérlistázandó_IP_cím --syn --dport ssh -j ACCEPT
iptables -A INPUT -p TCP --syn --dport ssh -m recent --update --seconds 60 --hitcount 3 -j DROP
iptables -A INPUT -p TCP --syn --dport ssh -m recent --set -j ACCEPT

Ha még nem tuttad volna: Drastik utájja a linuxot.
Nála iptables nem jáccik.

Üdv,
Dw.

[quote:e21497e7f3="1g0R"]Hi,

és a private-public key lehet megoldás, úgy hogy az sshd.conf-ban a PasswordAuth -ot NO-ra állítom ? Igy csak az jön be akinek kulcsa van, nemde ?

[code:1:e21497e7f3]PubkeyAuthentication yes
PasswordAuthentication no
UsePAM no
PermitRootLogin no
[/code:1:e21497e7f3]

így le van tiltva a pamból való jelszavas azonosítás - meg a root user is. Elvileg nem kell több :)

[quote:927e91b312="mocsi"][quote:927e91b312="jaci"]Erről már volt szó itt:
http://hup.hu/modules.php?name=News&file=article&sid=7716

Ez a limites megoldás nekem is bejött, 3 próbálkozás után 10 percre tiltva van.. Még egy se jött vissza utána próbálkozni...

Én keményebb vagyok 3 próbálkozás után 1 óra tiltás.
Az elején naponta többezer usernév/jelszó próbát kaptam, ma már összesen valami 10-12 db-ot.

ezt konkretan mivel?

Konkrétan végigolvastad??

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p TCP -s fehérlistázandó_IP_cím --syn --dport ssh -j ACCEPT
iptables -A INPUT -p TCP --syn --dport ssh -m recent --update --seconds 60 --hitcount 3 -j DROP
iptables -A INPUT -p TCP --syn --dport ssh -m recent --set -j ACCEPT

[quote:9f0ead25ce="sb"][quote:9f0ead25ce="Hijaszu"]Udv,

Tud valaki ilyen eszkozt?

Hijaszu

http://denyhosts.sourceforge.net/features.html

Ez valami hasonlo. Esetleg bejohet.

:oops: :oops:
Na en aztan ma jo vaksi vagyok.

Sziasztok!

Nálam is égető probléma lett a próbálkozások kizárása, de az itt - és más fórumokon talált - megoldás nem működik..

[code:1:bb2e27c16f]
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
#iptables -A INPUT -p TCP -s fehérlistázandó_IP_cím -m state --state NEW --dport ssh -j ACCEPT
iptables -A INPUT -p TCP --dport ssh -m limit --limit 3/min -m state --state NEW -j ACCEPT
iptables -A INPUT -p TCP -m state --state NEW --dport ssh -j DROP
[/code:1:bb2e27c16f]

A fent szemléltetésből kikommnetelt sort nem akartam aktiválni, mivel jelenleg szeretném tesztelni a rendszeren, de a másik három paraméterezett parancsot kiadtam.
Olyan vidáman próbálkozhatok kajli nevekkel és olyan korlátlanul, mint annak előtte.

Ide másolom az iptable --list kimenetének - feltételezett - ide vonatkozó részét.
[code:1:bb2e27c16f]
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh limit: avg 3/min burst 5 state NEW
DROP tcp -- anywhere anywhere state NEW tcp dpt:ssh
[/code:1:bb2e27c16f]

Mi nem oké?

[quote:3d7c07c548="jaci"]Konkrétan végigolvastad??

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p TCP -s fehérlistázandó_IP_cím --syn --dport ssh -j ACCEPT
iptables -A INPUT -p TCP --syn --dport ssh -m recent --update --seconds 60 --hitcount 3 -j DROP
iptables -A INPUT -p TCP --syn --dport ssh -m recent --set -j ACCEPT

szal iptables

nem nem olvastam vegig

Nah, jól van, akkor nem csak nálam van gond.. :)

Én kipróbáltam a másikat is, ami itt van a topicban, azzal is ugyanez a helyzet.. :(
Amikor betöltöm a tűzfalat az új szabályokkal, ezt az üzenetet kapom:

iptables: No chain/target/match by that name
iptables: No chain/target/match by that name

Környezet: debian sarge, 2.4 kernel, iptables 1.2.11-10.
[/code]

Jah, ok. Az első változat az ipt_recent modult használja, ami ugye 2.4-es kernelen nincs.
Ellenben viszont ez a limites változat érdekelne, hogy miért nem müxik..