Odpowiedzi:
Ostrzeżenie: zgodnie z komentarzami nie działa to, jeśli użytkownik utworzy plik o nazwie
~/.ssh/rc
. *
Zmodyfikuj lub utwórz /etc/ssh/sshrc
za pomocą następującej zawartości:
ip=`echo $SSH_CONNECTION | cut -d " " -f 1`
logger -t ssh-wrapper $USER login from $ip
echo "User $USER just logged in from $ip" | sendemail -q -u "SSH Login" -f "Originator <from@address.com>" -t "Your Name <your.email@domain.com>" -s smtp.server.com &
To skutecznie powiadomi Cię e-mailem za każdym razem, gdy ktoś zaloguje się za pośrednictwem SSH, a login zostanie zalogowany w syslog.
Uwaga: Do działania powiadomienia e-mail potrzebujesz sendemail
pakietu ( sudo apt-get install sendemail
).
Uwaga: działa z przekierowaniem portów, ale z opcją -N nie.
~/.ssh/rc
więc jest to całkiem bezużyteczne ze względów bezpieczeństwa. Odpowiedź @adosaiguas dotycząca pam_exec
jest poprawna.
~/.ssh/rc
plików. Korzystanie z ogólnosystemowej metody opartej na pam
jest po prostu bardziej niezawodne i bezpieczniejsze, ponieważ tylko root
można się z tym pograć. Tak więc odpowiedź brzmi: sshrd
metody działają dobrze dla systemów z jednym użytkownikiem, ale pam
metoda działa niezawodnie dla wszystkich systemów.
Ostrzeżenie: jak zawsze po zmianie konfiguracji logowania, pozostaw otwartą sesję tworzenia kopii zapasowych w tle i przetestuj logowanie z nowego terminala.
Ponieważ sshrc
metoda nie działa, jeśli użytkownik ma własny ~/.ssh/rc
plik, wyjaśnię, jak to zrobić za pomocą pam_exec
@adosaiguas. Dobrą rzeczą jest to, że można to łatwo dostosować do typów logowania innych niż ssh
(np. Lokalne loginy lub nawet wszystkie loginy) poprzez podłączenie do innego pliku /etc/pam.d/
.
Najpierw musisz mieć możliwość wysyłania poczty z wiersza poleceń. Istnieją inne pytania na ten temat. Na serwerze pocztowym jest prawdopodobnie najłatwiejszy do zainstalowania mailx
(i tak już prawdopodobnie jest już zainstalowany).
Następnie potrzebujesz pliku skryptu wykonywalnego login-notify.sh
(umieszczam go /etc/ssh/
na przykład) o następującej treści. Możesz zmienić zmienne, aby zmienić temat i treść powiadomienia e-mail. Nie zapomnij wykonać, chmod +x login-notify.sh
aby był wykonywalny.
#!/bin/sh
# Change these two lines:
sender="sender-address@example.com"
recepient="notify-address@example.org"
if [ "$PAM_TYPE" != "close_session" ]; then
host="`hostname`"
subject="SSH Login: $PAM_USER from $PAM_RHOST on $host"
# Message to send, e.g. the current environment variables.
message="`env`"
echo "$message" | mailx -r "$sender" -s "$subject" "$recepient"
fi
Gdy to zrobisz, możesz dodać następujący wiersz /etc/pam.d/sshd
:
session optional pam_exec.so seteuid /path/to/login-notify.sh
Do celów testowych moduł jest dołączony jako optional
, abyś mógł nadal się logować, jeśli wykonanie się nie powiedzie. Po upewnieniu się, że działa, możesz zmienić optional
na required
. W takim przypadku logowanie nie będzie możliwe, chyba że wykonanie skryptu przechwytującego zakończyło się powodzeniem (jeśli tego właśnie chcesz).
Dla tych z Was, którzy potrzebują wyjaśnienia, czym jest PAM i jak działa, oto bardzo dobre .
/etc/ssh/login-notify.sh failed: exit code 13
zaraz po zalogowaniu :(
UsePAM
ustawiłeś yes
opcję w swoim sshd_config.
unconfined_u:object_r:bin_t:s0
. Potem ja chmod +x /bin/login-notify.sh
i to działa.
Używamy Monit monitorować procesy na naszych linuxowych. Monitor może również powiadamiać e-mailem o udanych logowaniach przez ssh. Nasza konfiguracja monitora wygląda następująco
check file ssh_logins with path /var/log/auth.log
# Ignore login's from whitelist ip addresses
ignore match "100.100.100.1"
# Else, alert
if match "Accepted publickey" then alert
Uwaga: konfigurację serwera pocztowego, format wiadomości e-mail itp. Należy ustawić w monitrc
pliku
Aktualizacja: Napisałem bardziej szczegółowy post na ten temat
Wprowadź następujące dane /etc/profile
:
if [ -n "$SSH_CLIENT" ]; then
TEXT="$(date): ssh login to ${USER}@$(hostname -f)"
TEXT="$TEXT from $(echo $SSH_CLIENT|awk '{print $1}')"
echo $TEXT|mail -s "ssh login" you@your.domain
fi
/etc/profile
jest wykonywany przy każdym logowaniu (dla użytkowników powłoki bash). Instrukcja if zwróci wartość true tylko wtedy, gdy użytkownik zaloguje się przez ssh, co z kolei spowoduje uruchomienie bloku kodu z wcięciem.
Następnie budujemy tekst wiadomości:
$(date)
zostanie zastąpiony przez wynik date
polecenia${USER}
zostanie zastąpiony nazwą użytkownika $(hostname -f)
zostanie zastąpiony pełną nazwą hosta, do którego logowany jest system Druga TEXT
linia dodaje się do pierwszej, podając adres IP systemu, z którego loguje się ten użytkownik. Na koniec wygenerowany tekst jest wysyłany w wiadomości e-mail na Twój adres.
Podsumowanie Linux domyślnie rejestruje każde logowanie do systemu, czy to przez ssh, czy nie, w plikach dziennika systemu, ale czasami - szczególnie w przypadku systemu, do którego dostęp jest rzadko uzyskiwany za pośrednictwem ssh - przydatne może być szybkie i nieprzyzwoite powiadomienie.
W tym drugim pytaniu prawdopodobnie masz to, czego szukasz. Zasadniczo możesz dodać wywołanie do polecenia mail w skrypcie, który jest uruchamiany, gdy użytkownik loguje się za pośrednictwem ssh: /etc/pam.d/sshd
Wziąłem kilka doskonałych odpowiedzi z tego wątku i stworzyłem coś, co można mniej więcej skopiować i wkleić. Używa Mailgun do wysyłania wiadomości e-mail, dzięki czemu oszczędzasz wszelkich problemów z konfiguracją STMP. Potrzebujesz tylko klucza API Mailgun i domeny wysyłającej.
Po zalogowaniu SSH skrypt wyśle szczegóły logowania (użytkownik, nazwa hosta, adres IP i wszystkie bieżące zmienne środowiskowe) na adres e-mail. Łatwo jest dodać inne parametry, które chcesz wysłać, dostosowując message
zmienną.
#!/bin/sh
# this script is triggered on SSH login and sends an email with details of the login
# such as user, IP, hostname, and environment variables
# script should be placed somewhere on the server, eg /etc/ssh
# to trigger on SSH login, put this line in /etc/pam.d/sshd:
# session optional pam_exec.so seteuid /etc/ssh/snippet-for-sending-emails-on-SSH-login-using-PAM.sh
# Script settings
MAILGUN_API_KEY=
MAILGUN_DOMAIN=
SENDER_NAME=
SENDER_EMAIL_ADDRESS=
RECIPIENT_EMAIL_ADDRESS=
if [ "$PAM_TYPE" != "close_session" ]; then
host=$(hostname)
ip=$(dig +short myip.opendns.com @resolver1.opendns.com) # gets public IP
# Message to send, e.g. the current environment variables.
subject="SSH login - user:$USER pam-host:$PAM_RHOST host:$host ip:$ip" \
message=$(env)
curl -s --user '$MAILGUN_API_KEY' \
https://api.mailgun.net/v3/$MAILGUN_DOMAIN/messages \
-F from='$SENDER_NAME <$SENDER_EMAIL_ADDRESS>' \
-F to=$RECIPIENT_EMAIL_ADDRESS \
-F subject="$subject" \
-F text="${subject} ${message}"
fi
Po opublikowaniu zauważyłem, że @pacharanero pisze również o mailgunie, ale nie rozumiem, co robią z kopaniem, więc opublikuję również moje rozwiązanie.
Jeśli korzystasz z maszyny wirtualnej, która nie ma SMTP, być może będziesz musiał użyć czegoś takiego jak mailgun, sendgrid lub tym podobne. To działało dla mnie w Google Cloud.
Jednym z zagrożeń związanych z tym podejściem jest to, że osoba atakująca może uzyskać poświadczenia wychodzące wiadomości e-mail, jeśli może sudo su
i znajdzie skrypt, lub jeśli skrypt zostanie wysłany jako czytelny. Mailgun ma białą listę adresów IP, którą powinieneś skonfigurować, ale to oczywiście nie jest idealne w tym konkretnym przypadku użycia.
Ten skrypt powinien działać z pocztą po przejściu mydomain.com
na rzeczywistą domenę. Możesz zapisać skrypt w /root/login-alert.sh
bardziej niejasnej lokalizacji.
#!/bin/bash
if [ "$PAM_TYPE" != "close_session" ]; then
APK='api:your-mailgun-api-key-goes-here'
FROM='Login Alert <mailgun@mg.mydomain.com>'
TO='me@mydomain.com'
SUBJECT="Login: $PAM_USER @ mydomain.com from $PAM_RHOST"
DATE=$(date)
TEXT="At $DATE a login occurred for $PAM_USER on mydomain.com from $PAM_RHOST"
curl -s --user $APK \
https://api.mailgun.net/v3/mg.mydomain.com/messages \
-F from="$FROM" \
-F to="$TO" \
-F subject="$SUBJECT" \
-F text="$TEXT"
fi
Następnie możesz postępować zgodnie z odpowiedzią @Fritz, aby zmienić, /etc/pam.d/sshd
aby uwzględnić:
session optional pam_exec.so seteuid /root/login-alert.sh
Zauważam, że działa to bez uprawnień odczytu dla przybywających użytkowników ( chmod 700 /root/login-alert.sh
), więc przybywający użytkownicy nie muszą mieć dostępu do odczytu skryptu.
Skrypt ten /etc/ssh/sshrc
wysyła wiadomość e-mail i dodaje dziennik do rejestratora systemu. Wprowadzono różnicę (więc możesz ją wyłączyć, jeśli chcesz) między osobistą podsiecią a siecią (wymaga sudo apt-get install mailutils
).
SUBNET="192.168.0"
IP=`echo $SSH_CONNECTION | cut -d " " -f 1`
CURRENT_SUBNET="$(echo $IP|cut -d'.' -f1-3)"
if [ "$CURRENT_SUBNET" = "$SUBNET" ]; then
msg="This message comes from same subnet! User $USER just logged in from $IP"
echo $msg|mail -s "$msg" root
else
msg="This message comes from different subnet! User $USER just logged in from $IP"
echo $msg|mail -s "$msg" root
fi
logger -t ssh-wrapper $USER login from $IP
Używam programu swatchdog z pakietu swatch do monitorowania wszelkich wierszy zawierających wyrażenie „ fail ” (bez rozróżniania wielkości liter) w /var/log/auth.log . Skonfigurowałem go tak, aby działał jako prosta usługa systemowa.
apt install swatch
Utwórz plik konfiguracyjny /etc/swatch/swatch-auth-log.conf z rootem właściciela, uprawnieniem 644 -
watchfor /fail/i
pipe /usr/local/sbin/sendmail -t auth.log@xxx.com
„/ Nie / i” jest wyrażeniem regularnym, z „ja”, co wskazuje, że nie uwzględnia wielkości liter. (Mój sendmail to skrypt wysyłający wszystko na ustalony adres za pośrednictwem skrzynki pocztowej , więc adres tak naprawdę nie ma znaczenia).
Utwórz plik usługi systemd /etc/systemd/system/swatch-auth-log.service z rootem właściciela, uprawnieniem 644 -
[Unit]
Description=monitor /var/log/auth.log, send fail notices by mail
[Service]
ExecStart=/usr/bin/swatchdog -c /etc/swatch/swatch-auth-log.conf -t /var/log/auth.log
[Install]
#WantedBy=multi-user.target
WantedBy=pre-network.target
Następnie włącz, uruchom i wyświetl status usługi -
sudo systemctl enable swatch-auth-log.service
sudo systemctl start swatch-auth-log.service
sudo systemctl status swatch-auth-log.service
Przykład udanego raportu o stanie -
● swatch-auth-log.service - monitor /var/log/auth.log, send fail notices by mail
Loaded: loaded (/etc/systemd/system/swatch-auth-log.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2019-01-31 21:41:52 PST; 17min ago
Main PID: 27945 (swatchdog)
Tasks: 3 (limit: 4915)
CGroup: /system.slice/swatch-auth-log.service
├─27945 /usr/bin/perl /usr/bin/swatchdog -c /etc/swatch/swatch-auth-log.conf -t /var/log/auth.log
├─27947 /usr/bin/perl /.swatchdog_script.27945
└─27949 /usr/bin/tail -n 0 -F /var/log/auth.log
Jan 31 21:41:52 ub18 systemd[1]: Started monitor /var/log/auth.log, send fail notices by mail.
Jan 31 21:41:52 ub18 swatchdog[27945]: *** swatchdog version 3.2.4 (pid:27945) started at Thu Jan 31 21:41:52 PST 2019
Usługa zostanie automatycznie uruchomiona podczas rozruchu i będzie monitorowana przez systemd .
Dyskusja
Pierwotnie użyłem rozwiązania pam podobnego do powyższego, ale w /etc/pam.d/common-auth nie sshd . To było złapanie ssh, sudo i loginów. Ale potem po aktualizacji wszystkie moje hasła przestały działać, nawet po zmianie haseł w trybie ratunkowym. W końcu zmieniłem /etc/pam.d/common-auth z powrotem na oryginalny i hasła znów działały. Oto opis na płycie Stack Exchange UNIX i Linux
Uznałem, że bezpieczniej będzie nie dotykać trudnych do zrozumienia ustawień bezpieczeństwa. I tak wszystko jest w plikach dziennika.
Właśnie zmodyfikowałem odpowiedź @ SirCharlo
ip=`echo $SSH_CONNECTION | cut -d " " -f 1`
logger -t ssh-wrapper $USER login from $ip
echo "User $USER just logged in from $ip" | mail -s "SSH Login" "who to <who-to@youremail.com>" &
Działa to na serwerach 14.04, 16.04 i Centos 6.5.x, które skonfigurowałem, jestem prawie pewien, że musisz upewnić się, że mta jest skonfigurowany, ale kiedy to zrobisz, działa to uroczo. Kolejny krok powiadomienia Twilio
ssh -N
Tylko przekierowanie portów.