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
