sudo proxychains versus proxychains sudo: de ce contează ordinea
Înțelegeți de ce proxychains sudo poate pierde biblioteca de interceptare, în timp ce sudo proxychains pornește wrapperul în contextul de execuție al țintei.
Aceste comenzi nu au aceeași graniță de execuție:
proxychains4 sudo command
sudo proxychains4 command
Proxychains-ng face ca o bibliotecă să fie preîncărcată în programul țintă. Pe Linux, executarea unui program set-user-ID precum sudo declanșează regulile de securitate ale loaderului, care elimină variabilele relevante de încărcare a bibliotecilor înainte ca sudo să le poată păstra.
În consecință, „păstrarea mai multui mediu” nu este o soluție fiabilă pentru a pune sudo în interiorul wrapperului. Manualul sudoers descrie explicit că variabile precum LD_* sunt eliminate înainte ca sudo să înceapă.
Dacă o comandă chiar are nevoie de contul țintă, porniți wrapperul în acel context autorizat. Apoi verificați ce configurație citește: sudo poate schimba HOME, PATH și fișierul aplicabil pentru fiecare utilizator. O invocare fără privilegii care funcționează nu dovedește că root a ales aceeași listă de proxy.
Preferați interfața de proxy nativă a programului atunci când aceasta există. Astfel evitați să depindeți de interceptare pentru o cerere pe care programul știe deja să o dirijeze.
De asemenea, țineți cont de limitele de acoperire ale proxychains. Mesajul său de pornire dovedește că wrapperul a pornit; nu dovedește că pachetele brute, apelurile neacceptate sau un proces de aplicație existent pornit separat i-au folosit biblioteca. Confirmați operațiunea de rețea pe care intenționați să o trimiteți prin proxy, în loc să tratați privilegiul de root ca dovadă că fiecare operațiune a fost interceptată.