Re: [rlug] fSrpauxy

2016-12-26 Fir de Conversatie Ionel Mugurel Ciobîcă
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 Fir de Conversatie Eugeniu Patrascu
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

2016-12-26 Fir de Conversatie Adrian Sevcenco

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 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

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

2016-12-26 Fir de Conversatie manuel "lonely wolf" wolfshant
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

2016-12-26 Fir de Conversatie Adrian Sevcenco

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

2016-12-26 Fir de Conversatie Adrian Sevcenco

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?? 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

2016-12-26 Fir de Conversatie wolfy
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 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 Fir de Conversatie Petru Rațiu
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

2016-12-26 Fir de Conversatie 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

___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug