Re: 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, [email protected] wrote:
>>> On 26 December 2016 11:33:35 EET, Adrian Sevcenco
>>> <[email protected]> wrote:
>>>> Salut!
>>>>
>>>> On 12/25/2016 03:15 PM, [email protected] 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
[email protected]
http://lists.lug.ro/mailman/listinfo/rlug