[ anon315 @ 23.06.2005. 10:15 ] @
Logovi su mi puni ovih sranja. Dictionary napadi bukvalno svaki dan.

Code:

(06/23/05 06:24:39) PoliceMan: 
    Jun 23 06:24:38 p3 sshd[6626]: Invalid user jubar from 81.4.79.60

(06/23/05 06:24:40) PoliceMan: 
    Jun 23 06:24:38 p3 sshd[6626]: reverse mapping checking getaddrinfo for
    ip-space.by.businesshosting.nl failed - POSSIBLE BREAKIN ATTEMPT!

(06/23/05 06:24:40) PoliceMan: 
    Jun 23 06:24:39 p3 sshd[6632]: Invalid user mckey from 81.4.79.60

(06/23/05 06:24:41) PoliceMan: 
    Jun 23 06:24:39 p3 sshd[6632]: reverse mapping checking getaddrinfo for
    ip-space.by.businesshosting.nl failed - POSSIBLE BREAKIN ATTEMPT!

(06/23/05 06:24:42) PoliceMan: 
    Jun 23 06:24:42 p3 sshd[6639]: Invalid user notorius from 81.4.79.60

(06/23/05 06:24:43) PoliceMan: 
    Jun 23 06:24:42 p3 sshd[6639]: reverse mapping checking getaddrinfo for
    ip-space.by.businesshosting.nl failed - POSSIBLE BREAKIN ATTEMPT!

(06/23/05 06:24:43) PoliceMan: 
    Jun 23 06:24:43 p3 sshd[6646]: Invalid user avenues from 81.4.79.60

(06/23/05 06:24:44) PoliceMan: 
    Jun 23 06:24:43 p3 sshd[6646]: reverse mapping checking getaddrinfo for
    ip-space.by.businesshosting.nl failed - POSSIBLE BREAKIN ATTEMPT!

(06/23/05 06:24:45) PoliceMan: 
    Jun 23 06:24:44 p3 sshd[6655]: Invalid user sanderson from 81.4.79.60

(06/23/05 06:24:46) PoliceMan: 
    Jun 23 06:24:45 p3 sshd[6655]: reverse mapping checking getaddrinfo for
    ip-space.by.businesshosting.nl failed - POSSIBLE BREAKIN ATTEMPT!

(06/23/05 06:24:47) PoliceMan: 
    Jun 23 06:24:47 p3 sshd[6660]: Invalid user courier from 81.4.79.60

(06/23/05 06:24:48) PoliceMan: 
    Jun 23 06:24:47 p3 sshd[6660]: reverse mapping checking getaddrinfo for
    ip-space.by.businesshosting.nl failed - POSSIBLE BREAKIN ATTEMPT!

(06/23/05 06:24:49) PoliceMan: 
    Jun 23 06:24:48 p3 sshd[6668]: Invalid user duane from 81.4.79.60

(06/23/05 06:24:49) PoliceMan: 
    Jun 23 06:24:48 p3 sshd[6668]: reverse mapping checking getaddrinfo for
    ip-space.by.businesshosting.nl failed - POSSIBLE BREAKIN ATTEMPT!

(06/23/05 06:24:51) PoliceMan: 
    Jun 23 06:24:50 p3 sshd[6673]: Invalid user erin from 81.4.79.60

(06/23/05 06:24:52) PoliceMan: 
    Jun 23 06:24:50 p3 sshd[6673]: reverse mapping checking getaddrinfo for
    ip-space.by.businesshosting.nl failed - POSSIBLE BREAKIN ATTEMPT!

(06/23/05 06:24:52) PoliceMan: 
    Jun 23 06:24:51 p3 sshd[6681]: Invalid user exim from 81.4.79.60

(06/23/05 06:24:53) PoliceMan: 
    Jun 23 06:24:51 p3 sshd[6681]: reverse mapping checking getaddrinfo for
    ip-space.by.businesshosting.nl failed - POSSIBLE BREAKIN ATTEMPT!


Kako ovo resiti:

Promenite port na kome slusa sshd sa 22 na primer na 1000. Takodje zabranite logovanje root-a preko ssh-a. Restartujte sshd. Sada se ovako logujete na masinu:

Code:
ssh -p 1000 user@masina
[ mkdsl @ 23.06.2005. 10:43 ] @
Sve to stoji, ali onda i napadac menja port. Doduse, ne vidim svrhu tih dictionary brute force napada, kad to ne prolazi ni u snovima...

Ali evo josh jednog predloga:

Program se zove sshd_sentry, lako se konfigurishe. Treba staviti broj pokusaja logovanja, vreme banovanja ip adrese, email adresu na koju vam shalje obaveshtenje (mislim da je to to, mozhda sam neshto propustio). Adrese nakon x pokushaja logovanja smeshta u /etc/hosts.deny na odredjeno (ili neodredjeno) vreme, i time ste mirni. Zanimljiva alatka, zaista.

[ anon315 @ 23.06.2005. 11:01 ] @
Ma ja mislim da on gadja 22 bas. Kako ce da mi nabode bas taj port koji ja lupim, mislim da nema sansi. Trebalo bi da odma odustane ako vidi da nema nista na 22. Javicu za koji dan kako stoje stvari.
[ Jbyn4e @ 23.06.2005. 11:10 ] @
À sto mi slis da ne moze da ga nabode? Prvo iskoristi nmap da vidi sta imas otvoreno od portova, a telnet na port mu moze otkriti o cemu se radi:
Citat:

telnet localhost 22
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
SSH-1.99-OpenSSH_3.8p1

Mislim da je onaj predlog odozgo mnogo bolji.. lepo banuje ip i moze da se slika...
[ random @ 23.06.2005. 11:11 ] @
Mislim da je lakše da vatrozidom kompletno zabraniš sav incoming traffic sa tog IP-ja.
[ mkdsl @ 23.06.2005. 11:24 ] @
Citat:
Vanja Petreski: Ma ja mislim da on gadja 22 bas. Kako ce da mi nabode bas taj port koji ja lupim, mislim da nema sansi. Trebalo bi da odma odustane ako vidi da nema nista na 22. Javicu za koji dan kako stoje stvari.


Pa ako si jedini korisnik, promeni. Ako imash vishe korisnika, njima morash dojaviti broj porta, a to je vec informacija koja curi u javnost . Kao shto reche Jbyn4e, vrlo lako je ponovo pronaci port. I tuci po njemu.

Citat:
random: Mislim da je lakše da vatrozidom kompletno zabraniš sav incoming traffic sa tog IP-ja.


Da, ali npr. moj messages ima pokusaja brute-a za dobru enciklopediju, zato se ne isplati rucno trazhiti ip adrese, vec pustish skriptu da to odradi on-the-run.

OT: Bilo bi skroz korisno kad bi sshd_config imao opciju da se enable-uje remote root login samo sa odredjene (zadate) ip adrese. Chudi me da tako neshto ne postoji.

PS. Vanja, koristan savet: iskljuchi reverse mapping, samo ti stvara nepotreban saobracaj. IP adresa je sasvim dovoljna. Sem ako bash imash potrebu za reverzovanjem.
[ Jbyn4e @ 23.06.2005. 11:45 ] @
Citat:
mkdsl:
OT: Bilo bi skroz korisno kad bi sshd_config imao opciju da se enable-uje remote root login samo sa odredjene (zadate) ip adrese. Chudi me da tako neshto ne postoji.

Pa zasto bi postojalo?
ssh [email protected]
pa posle jedno vrlo jednostavno
su -
....
[ anon315 @ 23.06.2005. 13:30 ] @
Alo ljudi, to nije jedna IP adresa, svaki put je druga! Morao bih celom svetu posle 15 dana da zabranim da mi pridje :) Drugo, sta ako od nekog Djure imam potrebu da pridjem masini, dakle ne znam unapred sve IP adrese sa kojih bih pristupao. I trece, koliko sam ja skapirao to nije user koji koristi nmap pa onda krlja, vec nekakav worm koji nasumice gadja. Takodje, jedini sam koji pristupa masini, tako da ... Inace, sa nmapom vidim da je otvoren port (aj nek bude za primer) 1000, ali ne pise sta je. Zakljucak, ipak mislim da je solidno resenje. Btw, do sada bi vec bilo bar jos 200 ovakvih poruka, ali nema ni jedne ;)
[ littleboy @ 23.06.2005. 16:17 ] @
Zabranis sa svih sors adresa konekciju na --dport 22 a pustis samo sa neke svoje masine, ili kucnog ip opsega (ako imas dinamicnu adresu).
[ bojan_bozovic @ 23.06.2005. 16:22 ] @
postavite dozvolu 754 na su da se samo iz grupe root moze npr koristiti su

Jun 21 18:27:41 mystique sshd[5043]: Did not receive identification string from 69.93.143.90
Jun 21 18:36:00 mystique sshd[5056]: Failed password for root from 69.93.143.90 port 46071 ssh2
Jun 21 18:36:03 mystique sshd[5059]: Invalid user admin from 69.93.143.90
Jun 21 18:36:03 mystique sshd[5059]: Failed password for invalid user admin from 69.93.143.90 port 464
36 ssh2
Jun 21 18:36:07 mystique sshd[5062]: Invalid user test from 69.93.143.90
Jun 21 18:36:07 mystique sshd[5062]: Failed password for invalid user test from 69.93.143.90 port 4683
6 ssh2
Jun 21 18:36:12 mystique sshd[5065]: Invalid user guest from 69.93.143.90
Jun 21 18:36:12 mystique sshd[5065]: Failed password for invalid user guest from 69.93.143.90 port 473
58 ssh2
Jun 21 18:36:15 mystique sshd[5068]: Invalid user webmaster from 69.93.143.90
Jun 21 18:36:15 mystique sshd[5068]: Failed password for invalid user webmaster from 69.93.143.90 port
47897 ssh2
Jun 21 18:36:23 mystique sshd[5072]: Failed password for mysql from 69.93.143.90 port 48448 ssh2
Jun 21 18:36:28 mystique sshd[5075]: Invalid user oracle from 69.93.143.90
Jun 21 18:36:28 mystique sshd[5075]: Failed password for invalid user oracle from 69.93.143.90 port 49
236 ssh2
Jun 21 18:36:32 mystique sshd[5078]: Invalid user library from 69.93.143.90
Jun 21 18:36:32 mystique sshd[5078]: Failed password for invalid user library from 69.93.143.90 port 4
9845 ssh2
Jun 21 18:36:36 mystique sshd[5081]: Invalid user info from 69.93.143.90
Jun 21 18:36:36 mystique sshd[5081]: Failed password for invalid user info from 69.93.143.90 port 5036
4 ssh2
Jun 21 18:36:41 mystique sshd[5084]: Invalid user shell from 69.93.143.90
Jun 21 18:36:41 mystique sshd[5084]: Failed password for invalid user shell from 69.93.143.90 port 509
41 ssh2
Jun 21 18:36:44 mystique sshd[5087]: Invalid user linux from 69.93.143.90

:D :D :D jos sam na dial-upu hehehe

-------- EDIT malo izmenjeno , hm dolazim ovde da odmorim mozak ;D ---


[Ovu poruku je menjao bojan_bozovic dana 23.06.2005. u 18:02 GMT+1]

[Ovu poruku je menjao bojan_bozovic dana 23.06.2005. u 18:19 GMT+1]
[ mkdsl @ 23.06.2005. 16:30 ] @
Citat:
Jbyn4e: Pa zasto bi postojalo?
ssh [email protected]
pa posle jedno vrlo jednostavno
su -
....


Pa mislim, hvala, kao da nisam znao . Sve to stoji, ali ja nekad ZHELIM da se logujem kao root, ne zhelim da se su-ujem...

Citat:
Vanja Petreski: Alo ljudi, to nije jedna IP adresa, svaki put je druga! Morao bih celom svetu posle 15 dana da zabranim da mi pridje Drugo, sta ako od nekog Djure imam potrebu da pridjem masini, dakle ne znam unapred sve IP adrese sa kojih bih pristupao. I trece, koliko sam ja skapirao to nije user koji koristi nmap pa onda krlja, vec nekakav worm koji nasumice gadja. Takodje, jedini sam koji pristupa masini, tako da ... Inace, sa nmapom vidim da je otvoren port (aj nek bude za primer) 1000, ali ne pise sta je. Zakljucak, ipak mislim da je solidno resenje. Btw, do sada bi vec bilo bar jos 200 ovakvih poruka, ali nema ni jedne


Ja ti rekoh za sshd_sentry, ti vidi shta cesh . Ako si jedini, digni port na npr 62000 (dok te bude skenirao, smorice se zhiv, pa ce verovatno na nekih 30000 i prestati ). Josh uvek ne postoji "worm" koji nasumice gadja sshd, mada ko zna...

Citat:
littleboy: Zabranis sa svih sors adresa konekciju na --dport 22 a pustis samo sa neke svoje masine, ili kucnog ip opsega (ako imas dinamicnu adresu).


Ja imam shell hosting server, zabrana source adresa na port 22 ne reshava problem... Bilo bi dobro kad bi SVI sem root-a mogli da se loguju na sshd, a root samo sa odredjene ip adrese... (ovo dvoje u isto vreme)

[Ovu poruku je menjao mkdsl dana 23.06.2005. u 17:42 GMT+1]
[ alex @ 23.06.2005. 16:39 ] @
Vanja,

pitanje je vremena kada ce tim napadima prethoditi portscan i pronalazenje ssh daemona na ciljnom serveru. Ko zna, mozda je to vec sada slucaj. Menjanje porta je security through obscurity, sto se odavno pokazalo kao neefikasna metoda.


Kod zastite od ovakvih napada akcenat nije na kolicini informacija koja zbog tog napada zavrsi u log fajlu - vec na cinjenici da li napadac moze ili ne moze da pristupi sistemu.

To se ne resava pomeranjem sshd-a na drugi port vec konfigurisanjem servisa da bude sigurniji.

Povrh svega, ja sam npr. zabranio ssh pristup svim IP adresama iz Azije, Afrike, Amerike, i Australije, itd..

Iz /etc/hosts.deny:
Citat:
sshd: 58.0.0.0/8, 59.0.0.0/8, 60.0.0.0/8, 61.0.0.0/8, 202.0.0.0/8, 203.0.0.0/8, 210.0.0.0/8, 211.0.0.0/8, 218.0.0.0/8, 219.0.0.0/8, 220.0.0.0/8, 221.0.0.0/8, 222.0.0.0/8

Poz,
alex.
[ mkdsl @ 23.06.2005. 16:52 ] @
@ Alex,

kao shto menjanje portova nije zashtita, nije ni banovanje ostalih kontinenata zashtita . Moj brat iz Amerike chesto putuje, i loguje se na server (sajt njegovog klinca) sa raznih lokacija. U neku ruku, to je samo suzhavanje problema, a ne reshavanje.

@ Vanja,

ako je u pitanju kucni rachunar na kome drzhish sshd, evo ti predlog: ifconfig-u dodaj virtuelni eth uredjaj i dodeli mu ip adresu, tipa 10.0.0.2 (ako ti je sadashnja 10.0.0.1), i stavi sshd da slusha po toj ip adresi. Faktichki, niko spolja ne mozhe da vidi taj virtuelni eth uredjaj sem tebe (i ostatka LAN-a koji/ako imash). U sluchaju da to nije sluchaj (uh), sshd_sentry ti je jedino reshenje (banovanje ip adrese koja pokushava da se loguje npr. 5 puta u roku od 1 minuta i trajanje ban-a npr mesec dana ). Posle tih mesec dana, banovi iz /etc/hosts.deny automatski nestaju, tako da nemash potrebu da chistish ruchno ishta... Takodje, u /etc/hosts.allow dodaj adrese sa kojih dozvoljavash pristup (tvoja ip adresa, ili adresa faksa etc.) i chak ako se tebi desi da 5 puta pogreshish, /etc/hosts.deny cesh zaobici (bez obzira shto ce te faktichki smestiti tamo, ipak si u hosts.allow)...
[ TiXo @ 23.06.2005. 19:26 ] @
Nije baš direktan odgovor na pitanje, ali:
Zašto koristiti autentifikaciju lozinkama?
obavezan ključić i mirno spavaj...
[ mkdsl @ 23.06.2005. 19:36 ] @
Dok neko ne dodje do tog kljuchica... A onda zdravo...

Drzhanje kljucha ispod praga nije zashtita.
[ anon315 @ 23.06.2005. 20:54 ] @
Alex, izvalio si me 1000%, upravo me je nervirao broj linija u logu, jer me jabber obaveštava o ovim napadima i onda mi se Psi redovno zakuca kad ga upalim ujutru jer primi > 600 poruka, a još se nisam ni umio

Sviđa mi se i Alexovo i mkdslovo rešenje, poigraću se sa oba.

Thanx
[ littleboy @ 24.06.2005. 02:18 ] @
Citat:
mkdsl: Dok neko ne dodje do tog kljuchica... A onda zdravo...

Drzhanje kljucha ispod praga nije zashtita.


?

Kako ce da dodje do kljuca ?
Drzis kljuc valjda na svojoj masini, ako ti uhaka masinu onda mu i ne treba access na nekom tamo shell serveru... a obicno na kucnim masinama i ne treba da bude nekih servisa pa da moze da dodje do naloga.

A pored toga, ovde nije pitanje kako ce da dodje i da li ce neko da dodje do ssh kljuca nego o sprijecavanju pogadjanja passworda.

Mislim da bi se prije trebao da orijentises na to da osiguras masinu, to jest shell naloge da ne mogu nikakve gluposti da rade na serveru. Pocevsi od ubijanja procesora, pa do ddosa.
Korisnik bi trebao da postavi password na svoju odgovornost, tvoje je da ga upoznas sa tim ako drzis shell server.

Ja ne drzim shell server, ali mislim da je to fer i korekt.
[ alex @ 24.06.2005. 09:53 ] @
Citat:
mkdsl: @ Alex,
kao shto menjanje portova nije zashtita, nije ni banovanje ostalih kontinenata zashtita :). Moj brat iz Amerike chesto putuje, i loguje se na server (sajt njegovog klinca) sa raznih lokacija. U neku ruku, to je samo suzhavanje problema, a ne reshavanje.


To suzavanje je ACL princip i sasvim je odgovarajuca zastita pored osiguravanja samog servisa putem bezbednije konfiguracije, tipa RSA ili pubkey kljuceva umesto cleartext lozinki, zatim ogranicavanje pristupa samo odredjenim korisnicima (u mom slucaju samo jedan korisnik) itd. ACL se koristi svuda u svetu. Sad, administratoru (korisniku) je ostavljeno da odluci sta ce i kako ce da izvede to suzavanje - ja sam ga izveo na gore-spomenuti nacin iz slicnih razloga kao i Vanja. Siguran sam da necu da se konektujem putem SSH-a iz Afrike. :) Cak i da hocu, tu je uvek VPN.

Znaci, daleko naprednija resenja ukljucuju VPN konekcije i slicno, mada time vec idemo malo van dâte teme.

Kao dodatno resenje se odlicno pokazao i port-knocking servis. Sistem je po defaultu konfigurisan da odbija konekcije sa svih ip adresa i dozvoljava konekciju samo sa IP adresa koje tacno izvedu port-knock sekvencu. Sjajna stvar.

Pozdrav,
alex.
[ anon315 @ 24.06.2005. 10:06 ] @
Mmm, pa to je genijalna fora! Mislis na ovako nesto:

http://www.zeroflux.org/knock
http://www.gatheringofgray.com

?

Nemam sad vremena da se igram sa tim, ali cu definitivno i to probati, svidja mi se.

Za sad, samo informativno, kako se onda kacis na tu masineriju tj. kako se onda generise ta sekvenca koju samo ti znas?

Baci liniju
[ alex @ 24.06.2005. 10:13 ] @
Sekvencu podesis u konfiguracionom fajlu (imas lep primer na sajtu knockd servera).

Citat:

[options]
logfile = /var/log/knockd.log

[opencloseSSH]
sequence = 2222:udp,3333:tcp,4444:udp
seq_timeout = 15
tcpflags = syn,ack
start_command = /usr/sbin/iptables -A INPUT -s %IP% -p tcp --syn -j ACCEPT
cmd_timeout = 10
stop_command = /usr/sbin/iptables -D INPUT -s %IP% -p tcp --syn -j ACCEPT



Pre ssh konektovanja samo pokrenes knock klijenta sa odgovarajucom sekvencom i server ti otvori port. Po zavrsetku, ponovo otkucas sekvencu i server zatvori port. Easy as that!
[ mkdsl @ 24.06.2005. 10:22 ] @
Citat:
littleboy: ?

Kako ce da dodje do kljuca ?
Drzis kljuc valjda na svojoj masini, ako ti uhaka masinu onda mu i ne treba access na nekom tamo shell serveru... a obicno na kucnim masinama i ne treba da bude nekih servisa pa da moze da dodje do naloga.


Logovanjem sa javnih mashina, putem java ssh, da ne pominjem logovanjem sa drugih shell servera kojima administratori imaju pristup shellovima... Mozhe na dosta nachina...

Citat:
Ja ne drzim shell server, ali mislim da je to fer i korekt.


Ja ga, nazhalost drzhim, ali neki korisnici ne znaju za pojam rechi fer i korekt...

Citat:
alex: To suzavanje je ACL princip i sasvim je odgovarajuca zastita pored osiguravanja samog servisa putem bezbednije konfiguracije, tipa RSA ili pubkey kljuceva umesto cleartext lozinki, zatim ogranicavanje pristupa samo odredjenim korisnicima (u mom slucaju samo jedan korisnik) itd.


Da, ali kad imash shell hosting kome pristupaju ljudi shirom sveta?

Citat:
ACL se koristi svuda u svetu. Sad, administratoru (korisniku) je ostavljeno da odluci sta ce i kako ce da izvede to suzavanje - ja sam ga izveo na gore-spomenuti nacin iz slicnih razloga kao i Vanja. Siguran sam da necu da se konektujem putem SSH-a iz Afrike. Cak i da hocu, tu je uvek VPN.


VPN je dobar nachin, ali nije za ovu temu, zaista

Citat:
Kao dodatno resenje se odlicno pokazao i port-knocking servis. Sistem je po defaultu konfigurisan da odbija konekcije sa svih ip adresa i dozvoljava konekciju samo sa IP adresa koje tacno izvedu port-knock sekvencu. Sjajna stvar.


Odlichno! Moracu da probam to, nadam se da nece stvoriti konfuziju kod korisnika
[ anon315 @ 24.06.2005. 10:26 ] @
Aj vec kad pricamo i imamo multiple resenja, evo jos jedna varijanta:

http://www.snort.org/

+

http://freshmeat.net/projects/blockit/

+

IPTables | IPChains | IPFWADM | Checkpoint

Resava problem promenljive IP adrese napadaca.

[Ovu poruku je menjao Vanja Petreski dana 24.06.2005. u 11:33 GMT+1]
[ gandalf @ 24.06.2005. 10:30 ] @
http://gentoo-wiki.com/HOWTO_Protect_SSHD_with_Swatch
Radi odlicno, mada je mnogo bolje knocd. E da ali obavezno stavi knockd da ga pokrece supervice.
[ anon315 @ 24.06.2005. 10:33 ] @
http://gentoo-wiki.com/HOWTO_Port_Knocking

Dobar ovaj Gentoo-Wiki
[ TiXo @ 24.06.2005. 21:20 ] @
Citat:
mkdsl:
Citat:
littleboy: ?

Kako ce da dodje do kljuca ?
Drzis kljuc valjda na svojoj masini, ako ti uhaka masinu onda mu i ne treba access na nekom tamo shell serveru... a obicno na kucnim masinama i ne treba da bude nekih servisa pa da moze da dodje do naloga.


Logovanjem sa javnih mashina, putem java ssh, da ne pominjem logovanjem sa drugih shell servera kojima administratori imaju pristup shellovima... Mozhe na dosta nachina...



hm, ovde se više ne govori o zaštiti servisa na bruteforce napad, već o politici korišćenja resursa, ako imaš neodgovorne korisnike/radnike/isl neće ti pomoći nikakva zaštita. Veseljak uvek može svoju knock sekvencu i user/pass da zapiše u .txt i da to ostavlja po desktopima u internet kafeima, isl...

A šta sve i kako može da zloupotrebi i "ukrade" lokalni admin (admin drugog shell servera, internet kafea, isl) od "letećeg" korisnika nema smisla ni nabrajati...

Korisnik mora da potpuno bude svestan šta znači njegov secret key i da odgovara ukoliko ga neko zloupotrebi.




P.S: Gentoo wiki je odličan ;)
[ weB_KiLeR @ 24.06.2005. 21:37 ] @
@Alex

Metoda deny all ti je bash efektivna mnogo, to se jednostavno tako ne radi ;)

Inace od ddos-a je nemoguce da se odbranite jer jednostavno tako je internet koncipiran, ako bilo ko tvrdi suprotno taj ne razume osnove.
Neki napadi samo mogu da se ublaze, ali efektivno je nemoguce da se ddos spreci u potpunosti.

Poz
[ alex @ 24.06.2005. 21:57 ] @
web_Killer:

Prvo, metoda nije deny all, citaj malo pazljivije.

Drugo, ovo nema nikakve veze sa ddos napadima, vec brute force napadom na ssh servis (da li si procitao o cemu se prica u ovoj temi?), sto je druga prica.

Trece, odbrana od (d)dos napada se ne resava na nivou sshd servisa na linux masini.

Na kraju, jaaaako bih voleo da me prosvetlis kako se to radi. Bas bih voleo da cujem tvoje eeekspertsko misljenje na tu temu.

[ mkdsl @ 24.06.2005. 22:04 ] @
Citat:
TiXo: hm, ovde se više ne govori o zaštiti servisa na bruteforce napad, već o politici korišćenja resursa, ako imaš neodgovorne korisnike/radnike/isl neće ti pomoći nikakva zaštita.


Pomoci ce mi to shto im necu dozvoliti da key sa svog rachunara zloupotrebi neko drugi. To je bukvalno poklanjanje naloga neovlashcenoj osobi.

Citat:
Veseljak uvek može svoju knock sekvencu i user/pass da zapiše u .txt i da to ostavlja po desktopima u internet kafeima, isl...


A mozhe i da kazhe svom drugaru, pa drugar kazhe drugom drugaru... Shto se svodi manje vishe na isto... Ali tad bar znam da je moj sistem siguran, tachnije da JA nisam omogucio trecoj osobi da neovlashceno koristi nalog.

Citat:
A šta sve i kako može da zloupotrebi i "ukrade" lokalni admin (admin drugog shell servera, internet kafea, isl) od "letećeg" korisnika nema smisla ni nabrajati...


Bash zbog toga...

Citat:
Korisnik mora da potpuno bude svestan šta znači njegov secret key i da odgovara ukoliko ga neko zloupotrebi.


Upravo tako.

Citat:
weB_KiLeR: @Alex

Inace od ddos-a je nemoguce ...


???!? Poenta?

@ Alex,

bez nervoze, please . Apsolutno te razumem
[ weB_KiLeR @ 24.06.2005. 22:52 ] @
Rasprava sa vama nema poente, uzgred alex znam o cemu se radi i ove 2 teme su usko vezane, a tvoja secure metoda me odusevljava, najlakse je zabraniti sav saobracaj sa odredjenih lokacija...
[ caboom @ 25.06.2005. 02:30 ] @
hm, sto se kljuceva tice, nije problem staviti passphrase na key auth i isto tako zabraniti login/PAM autentifikaciju. sa druge strane, moguce je menjati neke od block-ova u raznim cipherima i time praviti jedinstveni klijent/server par, ali nisam siguran koliko je to pametno posto se time slabi sam algoritam. elem, mislim da je firewalling ponajbolje resenje ako se serveru pristupa sa fiksnih adresa, svakako mnogo bolje nego ostaviti ga na dobar dan. podsetio bih na predivna desavanja sa openssl-om i openssh-om pre par godina kada je mesec dana sve bilo busno i exploiti su nadirali svakih par dana. ne bih se pouzdao u tradicionalno supalj sw, vec bih se drzao suptilnijih metoda...
[ littleboy @ 25.06.2005. 03:12 ] @
Ko prica o ddosu ?

Ne moguce je 100 % zastiti masinu od ovakvih napada, mozes da koristis knockd, ali ponovo postoji rizik, kao i kod public keyeva.. i ostalih metoda.
Zato sam i rekao da je najbolje da se osigura masina prvo, pa onda tek tamo neke sshd zastite i slicno..a password da bude na odgovornost korisnika.