W nowoczesnych systemach Linux, pam_unix.so narzuca takie opóźnienie. Jak wcześniej informowaliśmy, to może być skonfigurowany do dwóch sekund, zmieniając FAIL_DELAY
w /etc/login.defs
. Jeśli chcesz jeszcze bardziej zmniejszyć opóźnienie, musisz dać pam_unix.so opcję „nodelay”. Na przykład w moim systemie, jeśli prześledzisz dołączenia zaczynając od /etc/pam.d/sudo
, okaże się, że musisz edytować następujący wiersz /etc/pam.d/system-auth
:
auth required pam_unix.so try_first_pass nullok
i zmień to na:
auth required pam_unix.so try_first_pass nullok nodelay
Niestety, sposób, w jaki moja linuksowa dystrybucja (arch) konfiguruje rzeczy, zawiera ten sam system-auth
plik system-remote-login
, który jest używany przez sshd.
Chociaż można bezpiecznie wyeliminować opóźnienie w sudo, ponieważ jest ono rejestrowane, używane tylko przez lokalnych użytkowników i możliwe do uniknięcia przez lokalnych atakujących, prawdopodobnie nie chcesz eliminować tego opóźnienia w przypadku zdalnego logowania. Możesz to oczywiście naprawić, pisząc niestandardowe sudo, które nie tylko zawiera udostępnione pliki uwierzytelniania systemowego.
Osobiście uważam, że opóźnienie w sudo (i ignorowanie SIGINT) jest dużym błędem. Oznacza to, że użytkownicy, którzy wiedzą, że źle wpisali hasło, nie mogą zabić procesu i sfrustrować się. Oczywiście nadal możesz zatrzymać sudo za pomocą Ctrl-Z, ponieważ sudo nie łapie SIGTSTP, a po zatrzymaniu możesz go zabić za pomocą kill -9 (SIGKILL). To po prostu denerwujące. Oznacza to, że zautomatyzowany atak może wystrzelić sudo na pseudo-terminale z bardzo dużą prędkością. Ale opóźnienie to frustruje legalnych użytkowników i zachęca ich do zawieszenia swoich powłok roota zamiast wychodzenia z nich, aby uniknąć konieczności ponownego sudo.