Planeta Srbija

Posle jedne od diskusija na linuxo.net forumima palo mi je na pamet da sastavim jedno malo uputstvo za povećanje bezbednosti OpenSSH servera. OpenSSH je odlična aplikacija za udaljeni pristup računarima jer omogućava kriptovanu vezu i potpuni osećaj rada u komandnoj liniji kao na lokalnoj mašini. OpenSSH je projekat, pazi ti to, OpenBSD ekipe. Dakle, postoji više načina da zaštitite svoj SSH pristup od radoznalaca i loših ljudi. Ja ću se ovde koncentrisati na jedan konkretan - sertifikati. Upotreba sertifikata za pristup udaljenoj mašini je jedan od boljih načina da se poveća sveukupna bezbednost servera. Sertifikati se obično koriste za tzv. pristup bez šifre. Naime, da ne biste pamtili stalno svoju šifru kreiraćete sertifikat koji nema šifru i pomoću njega pristupati sistemu. Ovo je loše jer ako neko dođe u posed vašeg sertifikata onda nastaju problemi. Za ovu priliku ću ipak koristiti seritifkat sa šifrom. Dakle, pređimo na posao. # local$ ssh-keygen -t rsa - obavezno unesite šifru u dijalogu za nju # local$ scp ~/.ssh/id_dsa.pub udaljena_masina # local$ ssh username@udaljena_masina # remote$ cat ~/id_rsa.pub >> ~/.ssh/authorized_keys # remote$ chmod 644 ~/.ssh/authorized_keys - obavezno ovo uradite jer u suprotnom sistem neće čitati sertifikat nego će tražiti šifru. To je to. Prekinete vezu sa udaljenom mašinom i kada pokušate ponovo da se nakačite dobićete nešto ovako: Enter passphrase for key ‘/home/nightweaver/.ssh/id_rsa’: Unesete šifru RSA ključa i bićete na sistemu. OK, idemo korak dalje. Ukoliko neko nema sertifikat biće prebačen na obično logovanje. Mi to ne želimo. Želimo da samo ljudi sa sertifikatom mogu da pristupe sistemu. Slede momenti napredne paranoje. Pre svega, napravimo korisnika koji ima neko neobično ime. Nešto što će biti teško povezati sa vama. Recimo, gatto. Dakle, imamo korisnika gatto. Prebacimo onaj sertifikat od malopre u home DIR korisnika gatto. Proverimo da li radi tako što ćemo uraditi: ssh gatto@udaljena_masina Ako se traži šifra sertifikata onda je sve OK. Idemo dalje. OpenSSH server ne mora slušati na podrazumevanom portu 22. To je port koji će razni skeneri prvo napadati. Prebacimo taj port na nešto visoko i nestandardno. Recimo: 7000. Ovo sve radim na OpenBSD mašini ali je procedura identična i za FreeBSD i GNU/Linux. Dakle: vim /etc/ssh/sshd_config Pri vrhu datoteke ćete videti liniju: Port 22. Izmenite to u 7000. Sačuvajte izmene i restartujte SSH server. Sada čete se na sistem kačiti na sledeći način: ssh -p 7000 gatto@udaljena_masina a sftp če raditi ovako: sftp -oPort=7000 gatto@udaljena_masina Proverite da li sve radi kako treba. Radi? Sjajno, idemo dalje. Kao što sam već naveo, ukoliko neko nema sertifikat bićemu tražena obična šifra. Ali mi želimo da ti "brute force" pokušaji unošenja šifre budu potpuno onemogućeni. Izmenimo sshd_config podatke da izgledaju ovako: LoginGraceTime 1m PermitRootLogin no StrictModes yes MaxAuthTries 3 AllowUsers gatto Ovako postižemo sledeće: korisnik ima 1m da unese svoju šifru, logovanje root korisnika direktno nije dozvoljeno a na raspolaganju će imati samo tri šanse da unese šifru. Poslednji red je veoma koristan. Samo korisnička imena koja se tu nalaze će uopše moći da priđu SSH serveru. Dakle, čak i da ne koristite sertifikate samo čete korisnikom gatto moći da se ulogujete. Lukavo, zar ne? Idemo dalje. Ukažimo sistemu gde mu se nalate RSA ključevi: RSAAuthentication yes PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys Isključimo sve ostalo: RhostsRSAAuthentication no HostbasedAuthentication no IgnoreRhosts yes Sledeći redovi su jako bitni. Stavite ovde NO samo ako ste prethodno testirali pristup RSA ključevima. Posto kada ovo prebacite u NO više neće biti moguće ući na sistem običnom šifrom. PasswordAuthentication no PermitEmptyPasswords no Dakle, sada samo korisnik gatto može pokušati da se uloguje i to ako i samo ako ima RSA sertifikat. No, ovo meni nije bilo dovoljno. Želeo sam da čak i ako neko uspe da uđe na sistem ne može tek tako doći do root naloga. Zato korisnika gatto nisam stavio u grupu wheel te samim tim komanda SU nije radila za njega. No, gatto se može prebaciti na nekog drugog korisnika. Napravio sam sebi radni nalog nightweaver koji je član grupe wheel i može postati root. Da vidimo sada malo skicirano kako izgleda ulaz na sistem: A nema sertifikat i ne zna dozvoljenog korisnika –> server - odbijen i pokušaj prilaska A ima sertifikat ali ne zna dozvoljenog korisnika –> server - odbijen i pokušaj prilaska A ima sertifikat, zna dozvoljenog korisnika ali ne za koji korisnik moze da radi SU –> ne može da napravi veliku štetu Putanja do sistema bi onda izgledala ovako: A mora imati sertifikat A mora znati koji korisnik koristi taj sertifikat i koja je šifra sertifikata A mora znati koji korisnik na serveru može da radi SU i koja je njegova šifra A se mora prebaciti na korisnika koji može raditi SU pa tek onda postati root Sve ovo može izgledati dosta komplikovano… verujte mi, nije. Probajte sami pa ćete videti. Kao neko ko se dosta dugo bavi bezbednošču računarskih mreža mogu vam reći da ni jedan sistem nikada neće biti najbezbedniji. Uz dovoljno truda i znanja svaka se zaštita može pre ili kasnije probiti. Ali zašto ne zakomplikovati put do sistema za one kojima tamo nije mesto?

Claws Mail је напредни мултиплатформски (подржани оперативни системи: GNU/Linux, FreeBSD, Solaris, Mac OS X, Windows и Maemo) клијент за електронску пошту и дискусионе групе (nntp/news). Мали, брз, функционалан, са великим бројем напредних функција (филтери, додаци, покретање спољних конзолних програма, адресар и др). Пошто је дијалог за подешавања програма веома комплексан, т.ј. (прегледно) натрпан гомилом опција интуитивно груписаних у смислене секције, неке поставке које утичу на изглед и понашање програма остале су „скривене“ и не налазе се на овом дијалогу већ се морају ручно подесити у конфигурационој датотеци програма.

Да би се не тако мали број ових скривеих опција подесио ручно, треба знати која опција чему служи, па је очекивано да и за њих постоји нека алатка за фино штеловање „ситних цревца“. И, постоји. Зове се (more…)

Написао Александар Урошевић за блог Записи. Слободна употреба садржаја у складу са BY-CC-SA 3.0 лиценцом.

Повезани записи Априлска (0) Конверзија PXL у XLS формат (0) Угашен „Fluxmod“ (2) cupti 0.1 – српски за GOCR (2) Опера за Џ (2)

The other days I installed Apache 2.2.4 (compiled from source) on FreeBSD 5.3, and while everything seemingly worked fine, after apachectl -k graceful command (actually sending SIGUSR1 to httpd process), httpd crashed leaving core dump in ServerRoot, and

pid 21090 (httpd), uid 0: exited on signal 11 (core dumped)pid 43276 (httpd), uid 0: exited on signal 11 (core dumped)pid 44355 (httpd), uid 0: exited on signal 11 (core dumped)pid 44458 (httpd), uid 0: exited on signal 11 (core dumped)

in dmesg. And since I have recently been on Solaris x86 crash dump analysis training by Frank Hofmann, I decided to practice learned and take a look into core file ...

[root@isis apache2-horus]# gdb /usr/local/httpd/apache2-horus/bin/httpd \/usr/local/httpd/apache2-horus/httpd.core #0 0x283c1711 in engine_table_select () from /lib/libcrypto.so.3 (gdb) bt full #0 0x283c1711 in engine_table_select () from /lib/libcrypto.so.3 No symbol table info available. #1 0x283c11c1 in ENGINE_get_default_DH () from /lib/libcrypto.so.3 No symbol table info available. #2 0x283bbfc5 in DH_new_method () from /lib/libcrypto.so.3 No symbol table info available. #3 0x283bbf16 in DH_new () from /lib/libcrypto.so.3 No symbol table info available. #4 0x282d156a in ?? () from /usr/local/httpd/apache2-horus/modules/mod_ssl.so No symbol table info available. #5 0x282c1b6f in ?? () from /usr/local/httpd/apache2-horus/modules/mod_ssl.so No symbol table info available. #6 0x282c1c84 in ?? () from /usr/local/httpd/apache2-horus/modules/mod_ssl.so No symbol table info available. #7 0x282c3402 in ?? () from /usr/local/httpd/apache2-horus/modules/mod_ssl.so No symbol table info available. #8 0x080717f4 in ap_run_post_config (pconf=0x80ac018, plog=0x80da018, ptemp=0x80eb018, s=0x80adeb8) at config.c:91 pHook = (ap_LINK_post_config_t *) 0x9 n = 5 rv = 134849408 #9 0x08061b3a in main (argc=3, argv=0xbfbfeb18) at main.c:706 exit_status = 0 c = 0 '\0' configtestonly = 0 confname = 0x808916f "conf/httpd.conf" def_server_root = 0x8088e8c "/usr/local/httpd/apache2-horus" temp_error_log = 0x0 error = 0x9 <address 0x9 out of bounds> server_conf = (server_rec *) 0x80adeb8 pglobal = (apr_pool_t *) 0x80aa018 pconf = (apr_pool_t *) 0x80ac018 plog = (apr_pool_t *) 0x80da018 ptemp = (apr_pool_t *) 0x80eb018 pcommands = (apr_pool_t *) 0x80ae018 opt = (apr_getopt_t *) 0x80ae0b0 rv = 134930104 mod = (module **) 0x80adeb8 optarg = 0xbfbfeae0 "(뿿�\020\006\b" signal_server = (apr_OFN_ap_signal_server_t *) 0x809a380

Looks like Apache and dso module mod_ssl were compiled against /lib/libcrypto.so.3 which doesn't provide functions which mod_ssl requires such as ENGINE_get_default_DH, DH_new_method, DH_new etc. Solution was to install new libcrypto.so (libcrypto.so.4) from openssl-0.9.8e_1 package and to recompile apache again (I was using same configure options as before installing openssl-0.9.8e_1, just this time configure found this new version of libcrypto.so library and generated Makefiles with -L /usr/local/lib

Running nm on libcrypto.so.4 for safety's sake:

[bilke@isis ~]% nm /usr/local/lib/libcrypto.so.4 | \egrep 'ENGINE_get_default_DH|DH_new_method|DH_new'00089368 T DH_new00089384 T DH_new_method0008deb8 T ENGINE_get_default_DH[bilke@isis ~]%

After installation of recompiled Apache 2.2 first thing was to check what version of libcrypto.so mod_ssl was compiled against

[bilke@isis ~]% ldd /usr/local/httpd/apache2-horus/modules/mod_ssl.so/usr/local/httpd/apache2-horus/modules/mod_ssl.so: libssl.so.4 => /usr/local/lib/libssl.so.4 (0x28179000) libcrypto.so.4 => /usr/local/lib/libcrypto.so.4 (0x281b4000)[bilke@isis ~]%

Everything looks good, and Apache is not crashing anymore on SIGUSR1 (apachectl -k graceful)