Re: [rlug] fSrpauxy
On 25-12-2016, at 12h 28'36", Ionel Mugurel Ciobîcă wrote about "[rlug] fSrpauxy" > > Pot face ceva despre port scanurile astea: > [...] > sau nu ar trebui să fiu îngrijorat? > > Am mutat portul ssh de pe 22 undeva mai sus (de ceva vreme). Oare asta > caută? Pot opri scanurile astea cumva (dacă ar trebui să fiu îngrijorat)? > Mulțumesc tuturor. Am mutat portul sshd mai sus de 1024 (dar mai jos de 1) de mai bine de 18 luni. Nu am avut nici o problemă. Înainte aveam gigei care tot încercau să intre în sistem cu useri de tip joe sau jan. Userii mei au nume românesc :-) De cînd am schimbat portul ssh nu mai am atîtea tentative. De fapt nici una :-)) Da, am și fail2ban activat. Dar nu mai face nimic, că nu are cui. Încă nu a încercat nimeni să se lege de portul meu ssh mutat. root se poate loga cu parolă doar la localhost, restul e totul cu chei ssh. Deci este destul de safe, zic eu. Astea cu scanurile sînt mai dese de cînd mi‑am pus yate... Am trecut și eu la technologia voip. Nu știu dacă ăștia cu port scan caută ssh sau altceva, de aia am întrebat. Poate din lista de porturi care încearcă ei vă sună ceva cunoscut. Și dacă tot am pomenit de yate, știe cineva cum poate configura fail2ban să oprescă pirați voip care folosesc 100+ adrese IP ca să‑mi atace yate, dar tot timpul folosesc același callername și același called (sau, mă rog terminația de la called este la fel). E adevărat că unii încearcă de la același IP de 3 ori la numere cu 000x, 00x și 900x, dar nimeresc cîte unul care se ține scai o săptămînă cu o sută de variante la numărul lui de Antarctica care‑l sună de la mai multe IP-uri. yate e configurat cum trebuie, că nu lasă pe nimeni neautentificat să treacă, dar mă stresează ăștia care keep on trying... Înțeleg bine că fail2ban ar putea să‑i oprescă înainte să interogheze yate... nu? Dacă sînt specialiști de yate pe listă mai am întrebări. De exemplu de ce nu merge funcția time? Dacă pun ^.*$=echo ${time} în regexroute.conf, rezultatul este nimic, deși în log apare la fiecare linie timpul în notația asta: 20161226204842.149389. Cînd pun eu ^.*$=echo ${time}: caller=${caller} callername=${callername} called=${called} address=${address} ip_host=${ip_host} formats=${formats} apar doar celelalte, nu și timpul... Am Yate 4.1.0 1. Mersi, Mugurel ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] fSrpauxy
2016-12-26 20:16 GMT+02:00 Adrian Sevcenco: > pe de alta parte daca ma uit la procese nu vad decat asta (EL6): > ps -C sshd --forest -o pid,ppid,user,args= > PID PPID USER > 3795 1 root /usr/sbin/sshd > 32725 3795 root \_ sshd: adrian [priv] > 32727 32725 adrian\_ sshd: adrian@pts/0 > > si ca default vad asta (EL6) : > UsePrivilegeSeparation > Specifies whether sshd(8) separates privileges by creating an unprivileged > child process to deal with incoming network traffic. After successful > authentication, another process will be created that has the privilege of > the authenticated user. The goal of privilege separation is to prevent > privilege escalation by containing any corruption within the unprivileged > processes. The default is “yes”. > > in plus EL7 si fedora au default-ul "sandbox" (incepind cu sshd-ul 5.9) > https://www.openssh.com/txt/release-5.9 > > so .. nu stiu ce sa zic... Eu zic sa faci cum stii tu mai bine. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] fSrpauxy
On 12/26/2016 04:54 PM, manuel "lonely wolf" wolfshant wrote: On 12/26/2016 03:51 PM, Adrian Sevcenco wrote: On 12/26/2016 01:55 PM, wo...@prolinux.ro wrote: On 26 December 2016 11:33:35 EET, Adrian Sevcencowrote: Salut! On 12/25/2016 03:15 PM, wo...@prolinux.ro wrote: Nu poti opri fiindca le fac altii. Poti insa securiza portul 22. Evident ideal ar fi sa permiti conectarea numai de la adrese cunoscute. Daca nu poti face asta, exista iptables match recent care e minunat in acest context, sau alternativ port knocking. Nu muta daemonul mai sus de portul 1024 ca risti sa dai in alte belele. Daca Scuze de hijacking dar ce alte belele pot fi? Eu am toate serverele cu ssh-ul > 1024 de citiva ani .. la ce sa ma astept? A cam zis rpetre totul. Surpriza suplimentara nementionata f explicit Sunt constient de problema serverelor ce folosesc intervale de porturi si porturile alese nu se suprapun cu servicile folosite de noi.. De asemeni, sunt constient ca schimbarea portului nu face decat sa reduca zgomotul, dar pentru acest scop am si schimbat portul (si zgomotul a fost redus la 0 ) e ca un daemon legat la un port > 1024 poate fi ucis de un program rauvoitot user space si inlocuit de un altul care, de pilda, sa ofere "facilitatea" de a sniffa partea de login/auth (ceea ce e o țîră mai dificil daca daemonul asculta pe un port < 1024). Mutatul sshd nu nu inteleg partea asta ... adica sshd-ul rulat ca root (cum e default) dar pe port neprivilegiat poate fi killed si inlocuit de orice user?? https://www.adayinthelifeof.nl/2012/03/12/why-putting-ssh-on-another-port-than-22-is-bad-idea/ iar ca raspuns punctual la intrebarea ta, citez din spusele altcuiva: " A malicious user could crash SSH daemon and launch a compromised one on the same port. Do NOT use ports above 1024 for SSH daemons." ( faza cu crash merge "mai greu" daca portul e <1024 pt ca trebuie drepturi de root ca sa o faci ceea ce nu e adevarat la >1024 ; sshd ruleaza ca root ok, acum am priceput idea .. desi imi pare far-fetched, pe sistemele cu multi utilizatori poate sa fie o problema .. in plus, nu vad cum vine partea cu : eu legat prin ssh la masina, crashuiesc serviciul prin care sunt legat ... decat daca pornesc un reverse shell si apoi prin shell-ul creat generez crash-ul sshd-ului ... desi, asta s-ar numi DoS si probabil s-ar cunoaste pina in acest moment ... doar cit sa faca bind pe portul 22, apoi threadul care manipuleaza efectiv traficul ruleaza ca alt user -- da un grep ssh /etc/passwd pe orice sistem si o sa intelegi ce vreau sa spun ) da cunosc asta : sshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/sbin/nologin pe de alta parte daca ma uit la procese nu vad decat asta (EL6): ps -C sshd --forest -o pid,ppid,user,args= PID PPID USER 3795 1 root /usr/sbin/sshd 32725 3795 root \_ sshd: adrian [priv] 32727 32725 adrian\_ sshd: adrian@pts/0 si ca default vad asta (EL6) : UsePrivilegeSeparation Specifies whether sshd(8) separates privileges by creating an unprivileged child process to deal with incoming network traffic. After successful authentication, another process will be created that has the privilege of the authenticated user. The goal of privilege separation is to prevent privilege escalation by containing any corruption within the unprivileged processes. The default is “yes”. in plus EL7 si fedora au default-ul "sandbox" (incepind cu sshd-ul 5.9) https://www.openssh.com/txt/release-5.9 so .. nu stiu ce sa zic... Adrian ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] fSrpauxy
On 12/26/2016 03:51 PM, Adrian Sevcenco wrote: > On 12/26/2016 01:55 PM, wo...@prolinux.ro wrote: >> On 26 December 2016 11:33:35 EET, Adrian Sevcenco >>wrote: >>> Salut! >>> >>> On 12/25/2016 03:15 PM, wo...@prolinux.ro wrote: Nu poti opri fiindca le fac altii. Poti insa securiza portul 22. Evident ideal ar fi sa permiti conectarea numai de la adrese cunoscute. Daca nu poti face asta, exista iptables match recent care e minunat in acest context, sau alternativ port knocking. Nu muta daemonul mai sus de portul 1024 ca risti sa dai in alte belele. Daca >>> Scuze de hijacking dar ce alte belele pot fi? Eu am toate serverele >>> cu ssh-ul > 1024 de citiva ani .. la ce sa ma astept? >>> >> >> A cam zis rpetre totul. Surpriza suplimentara nementionata f explicit > Sunt constient de problema serverelor ce folosesc intervale de porturi > si porturile alese nu se suprapun cu servicile folosite de noi.. > > De asemeni, sunt constient ca schimbarea portului nu face decat sa > reduca zgomotul, dar pentru acest scop am si schimbat portul (si > zgomotul a fost redus la 0 ) > >> e ca un daemon legat la un port > 1024 poate fi ucis de un program >> rauvoitot user space si inlocuit de un altul care, de pilda, sa ofere >> "facilitatea" de a sniffa partea de login/auth (ceea ce e o țîră mai >> dificil daca daemonul asculta pe un port < 1024). Mutatul sshd nu > nu inteleg partea asta ... adica sshd-ul rulat ca root (cum e default) > dar pe port neprivilegiat poate fi killed si inlocuit de orice user?? https://www.adayinthelifeof.nl/2012/03/12/why-putting-ssh-on-another-port-than-22-is-bad-idea/ iar ca raspuns punctual la intrebarea ta, citez din spusele altcuiva: " A malicious user could crash SSH daemon and launch a compromised one on the same port. Do NOT use ports above 1024 for SSH daemons." ( faza cu crash merge "mai greu" daca portul e <1024 pt ca trebuie drepturi de root ca sa o faci ceea ce nu e adevarat la >1024 ; sshd ruleaza ca root doar cit sa faca bind pe portul 22, apoi threadul care manipuleaza efectiv traficul ruleaza ca alt user -- da un grep ssh /etc/passwd pe orice sistem si o sa intelegi ce vreau sa spun ) * * ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] fSrpauxy
On 12/26/2016 12:52 PM, Petru Rațiu wrote: alte porturi. Fa chestii mai decisive, gen firewall de la ip-uri cunoscute, eliminat password auth (si lasat doar pubkey auth), scos root login (ca sa pe masinile personale am facut asta (iar la cele 2-3 la care am nevoie de root login sunt cu match pentru ip privat) dar nu pot face asta la toate ca nu sunt eu seriful ... trebuiasca sa fie ghicit si userul), sau chiar chestii mai fancy gen port knocking. Asta cu pus loggingul verbose si ingrijoratul a ce trece pe acolo m-am gindit la asta dar momentan, intru-cat nu am avut nici o incercare straina pe porturile de ssh/ sau 2-3 pe masina personala la care am pus pe un mail list adresa publica, nu m-au determinat sa il pun .. dar e in plan ca jucarie de incercat .. Multumesc frumos, Adrian ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] fSrpauxy
On 12/26/2016 01:55 PM, wo...@prolinux.ro wrote: On 26 December 2016 11:33:35 EET, Adrian Sevcencowrote: Salut! On 12/25/2016 03:15 PM, wo...@prolinux.ro wrote: Nu poti opri fiindca le fac altii. Poti insa securiza portul 22. Evident ideal ar fi sa permiti conectarea numai de la adrese cunoscute. Daca nu poti face asta, exista iptables match recent care e minunat in acest context, sau alternativ port knocking. Nu muta daemonul mai sus de portul 1024 ca risti sa dai in alte belele. Daca Scuze de hijacking dar ce alte belele pot fi? Eu am toate serverele cu ssh-ul > 1024 de citiva ani .. la ce sa ma astept? A cam zis rpetre totul. Surpriza suplimentara nementionata f explicit Sunt constient de problema serverelor ce folosesc intervale de porturi si porturile alese nu se suprapun cu servicile folosite de noi.. De asemeni, sunt constient ca schimbarea portului nu face decat sa reduca zgomotul, dar pentru acest scop am si schimbat portul (si zgomotul a fost redus la 0 ) e ca un daemon legat la un port > 1024 poate fi ucis de un program rauvoitot user space si inlocuit de un altul care, de pilda, sa ofere "facilitatea" de a sniffa partea de login/auth (ceea ce e o țîră mai dificil daca daemonul asculta pe un port < 1024). Mutatul sshd nu nu inteleg partea asta ... adica sshd-ul rulat ca root (cum e default) dar pe port neprivilegiat poate fi killed si inlocuit de orice user?? nu am inteles bine partea asta.. ma gindesc ca e clar ca un astfel de bug ar fi facut valuri pina acum... ( + din cite stiu orice program e user space chiar daca are uid/gid 0, in opozitie fiind kernel space .. gresesc? ) aduce nimic dpdv securitate, doar reduce putin zgomotull de fond din loguri, eliminindu-i pe cei care scaneaza exclusiv portul 22 (si ii face pe admini sa se simta umezi in consecinta). Numarul de boti insa la ora actuala e atit de mare iar benzile atit de largi incit scanarea tuturor porturilor nu il costa pe atacator nimic in plus fata de a incerca doar un port. In urma cu 20 de ani era usor avantajos sa reduci zgomotul schimbind portul. Acum e cvasi inutil. pentru mine, reducerea zgomotului e foarte utila.. Wolfy PS: Arunca un ochi la "Fast Internet-wide Scanning and its Security Applications [30c3]" pe youtube ca sa intelegi mai bine ce spun . E interesant, multumesc! usor boring dar in final rezultatele sint ...... edificatoare si self-explanatory PS2: uite-te si la sslh, e interesant. fantastic tool! foarte util pentru wireless-urile din hoteluri unde orice outgoing port e blocat cu exceptia 80,443 multumesc!! Adrian ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] fSrpauxy
On 26 December 2016 11:33:35 EET, Adrian Sevcencowrote: >Salut! > >On 12/25/2016 03:15 PM, wo...@prolinux.ro wrote: >> Nu poti opri fiindca le fac altii. Poti insa securiza portul 22. >> Evident ideal ar fi sa permiti conectarea numai de la adrese >> cunoscute. Daca nu poti face asta, exista iptables match recent care >> e minunat in acest context, sau alternativ port knocking. Nu muta >> daemonul mai sus de portul 1024 ca risti sa dai in alte belele. Daca >Scuze de hijacking dar ce alte belele pot fi? Eu am toate serverele cu >ssh-ul > 1024 de citiva ani .. la ce sa ma astept? > A cam zis rpetre totul. Surpriza suplimentara nementionata f explicit e ca un daemon legat la un port > 1024 poate fi ucis de un program rauvoitot user space si inlocuit de un altul care, de pilda, sa ofere "facilitatea" de a sniffa partea de login/auth (ceea ce e o țîră mai dificil daca daemonul asculta pe un port < 1024). Mutatul sshd nu aduce nimic dpdv securitate, doar reduce putin zgomotull de fond din loguri, eliminindu-i pe cei care scaneaza exclusiv portul 22 (si ii face pe admini sa se simta umezi in consecinta). Numarul de boti insa la ora actuala e atit de mare iar benzile atit de largi incit scanarea tuturor porturilor nu il costa pe atacator nimic in plus fata de a incerca doar un port. In urma cu 20 de ani era usor avantajos sa reduci zgomotul schimbind portul. Acum e cvasi inutil. Wolfy PS: Arunca un ochi la "Fast Internet-wide Scanning and its Security Applications [30c3]" pe youtube ca sa intelegi mai bine ce spun . E usor boring dar in final rezultatele sint ...... edificatoare si self-explanatory PS2: uite-te si la sslh, e interesant. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] fSrpauxy
2016-12-26 11:33 GMT+02:00 Adrian Sevcenco: > Salut! > > On 12/25/2016 03:15 PM, wo...@prolinux.ro wrote: > >> Nu poti opri fiindca le fac altii. Poti insa securiza portul 22. >> Evident ideal ar fi sa permiti conectarea numai de la adrese >> cunoscute. Daca nu poti face asta, exista iptables match recent care >> e minunat in acest context, sau alternativ port knocking. Nu muta >> daemonul mai sus de portul 1024 ca risti sa dai in alte belele. Daca >> > Scuze de hijacking dar ce alte belele pot fi? Eu am toate serverele cu > ssh-ul > 1024 de citiva ani .. la ce sa ma astept? > > Multumesc frumos! > Adrian > > Nu stiu sigur la ce fel de belele se refera wolfy, dar eu unul am dat de niste probleme foarte haioase (not!) cand am avut daemons care asculta pe porturi din intervalul din /proc/sys/net/ipv4/ip_local_port_range (care e 32768-61000 default). Porturile sub 1024 sunt protejate de kernel sa nu fie accesibile decat userului root, de la 1024 incolo incepe sa fie ceva mai haos. Ca exemplu, una din chestiile pe care le tin minte e ca aveam clienti care se legau la daemonul cu pricina pe localhost si din cand in cand gaseam unul care era legat la el insusi pe portul ala si daemonul plangea pe dinafara ca i-a papat cineva portul, in timp ce clientul care-si manca singur coada astepta forever sa-i zica cineva ceva. Nu era vorba de ssh, da' still, mi-a scos niste fire de par alb problema timp de cateva saptamani pana m-am prins. Si daca tot am comentat pe tema asta, as mentiona si ca sunt de parere ca mutatul daemonului pe alt port e frectie la picior de lemn. Nu face decat sa-ti dea tie sentimentul ca e mai pitit, pentru ca nu-s atat de multi care-l scaneaza. Dar nu scapi decat de aia foarte prosti care n-ar fi intrat oricum, cu pretul de a te pune pe tine sa schimbi toti clientii pe alte porturi. Fa chestii mai decisive, gen firewall de la ip-uri cunoscute, eliminat password auth (si lasat doar pubkey auth), scos root login (ca sa trebuiasca sa fie ghicit si userul), sau chiar chestii mai fancy gen port knocking. Asta cu pus loggingul verbose si ingrijoratul a ce trece pe acolo e echivalentul IT al urmaritului stirilor de la ora 5. -- P. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] fSrpauxy
Salut! On 12/25/2016 03:15 PM, wo...@prolinux.ro wrote: Nu poti opri fiindca le fac altii. Poti insa securiza portul 22. Evident ideal ar fi sa permiti conectarea numai de la adrese cunoscute. Daca nu poti face asta, exista iptables match recent care e minunat in acest context, sau alternativ port knocking. Nu muta daemonul mai sus de portul 1024 ca risti sa dai in alte belele. Daca Scuze de hijacking dar ce alte belele pot fi? Eu am toate serverele cu ssh-ul > 1024 de citiva ani .. la ce sa ma astept? Multumesc frumos! Adrian ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug