logi serwera auth.log

[krk 2]

Witam ostatnio w logach znalazłem takie coś. czy to oznacza że ktoś wbił mi się na serwer ?

 

Jan 18 09:00:01 puszcza sudo: pam_unix(sudo:session): session opened for user root by (uid=0)
Jan 18 09:00:01 puszcza sudo: pam_unix(sudo:session): session closed for user root
Jan 18 09:00:01 puszcza CRON[15215]: pam_unix(cron:session): session closed for user admin
Jan 18 09:00:02 puszcza sudo: pam_unix(sudo:session): session closed for user root
Jan 18 09:00:02 puszcza CRON[15214]: pam_unix(cron:session): session closed for user admin
Jan 18 09:03:10 puszcza sshd[15492]: Accepted password for root from 81.15.179.6 port 50789 ssh2
Jan 18 09:03:10 puszcza sshd[15492]: pam_unix(sshd:session): session opened for user root by (uid=0)
Jan 18 09:03:10 puszcza sshd[15495]: lastlog_openseek: Couldn't stat /var/log/lastlog: No such file or directory
Jan 18 09:03:10 puszcza sshd[15495]: lastlog_openseek: Couldn't stat /var/log/lastlog: No such file or directory
Jan 18 09:05:01 puszcza CRON[15510]: pam_unix(cron:session): session opened for user admin by (uid=0)
Jan 18 09:05:01 puszcza CRON[15509]: pam_unix(cron:session): session opened for user admin by (uid=0)
Jan 18 09:05:01 puszcza sudo: pam_unix(sudo:session): session opened for user root by (uid=0)
Jan 18 09:05:01 puszcza sudo: pam_unix(sudo:session): session opened for user root by (uid=0)
Jan 18 09:05:01 puszcza sudo: pam_unix(sudo:session): session closed for user root
Jan 18 09:05:01 puszcza CRON[15510]: pam_unix(cron:session): session closed for user admin
Jan 18 09:05:02 puszcza sudo: pam_unix(sudo:session): session closed for user root

 

Jan 18 10:29:22 puszcza sshd[20734]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=185.130.5$
Jan 18 10:29:24 puszcza sshd[20734]: Failed password for invalid user user from 185.130.5.234 port 57116 ssh2
Jan 18 10:29:24 puszcza sshd[20734]: Received disconnect from 185.130.5.234: 11: Bye Bye [preauth]
Jan 18 10:29:24 puszcza sshd[20736]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=185.130.5$
Jan 18 10:29:26 puszcza sshd[20736]: Failed password for admin from 185.130.5.234 port 59157 ssh2
Jan 18 10:29:26 puszcza sshd[20736]: Received disconnect from 185.130.5.234: 11: Bye Bye [preauth]
Jan 18 10:29:26 puszcza sshd[20738]: Invalid user ubnt from 185.130.5.234
Jan 18 10:29:26 puszcza sshd[20738]: input_userauth_request: invalid user ubnt [preauth]
Jan 18 10:29:26 puszcza sshd[20738]: pam_unix(sshd:auth): check pass; user unknown
Jan 18 10:29:26 puszcza sshd[20738]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=185.130.5$
Jan 18 10:29:28 puszcza sshd[20738]: Failed password for invalid user ubnt from 185.130.5.234 port 32852 ssh2
Jan 18 10:30:01 puszcza CRON[20830]: pam_unix(cron:session): session opened for user admin by (uid=0)
Jan 18 10:30:01 puszcza CRON[20829]: pam_unix(cron:session): session opened for user admin by (uid=0)
Jan 18 10:30:01 puszcza sudo: pam_unix(sudo:session): session opened for user root by (uid=0)
Jan 18 10:30:01 puszcza sudo: pam_unix(sudo:session): session opened for user root by (uid=0)
Jan 18 10:30:01 puszcza sudo: pam_unix(sudo:session): session closed for user root
Jan 18 10:30:01 puszcza CRON[20830]: pam_unix(cron:session): session closed for user admin
Jan 18 10:30:02 puszcza sudo: pam_unix(sudo:session): session closed for user root
Jan 18 10:30:02 puszcza CRON[20829]: pam_unix(cron:session): session closed for user admin

 

Edytowano Styczeń 20, 2016 przez krk (zobacz historię edycji)

[KerbenII 19]

Czy nie masz przypadkiem na tym serwerze wgranego DirectAdmin?

[krk 2]

Czy nie masz przypadkiem na tym serwerze wgranego DirectAdmin?

 

niee jest vestacp

[N0Name 48]

Sprawdź czy to nie twoje ip, swoją drogą mógłbyś zainstalować fail2ban lub denyhosts, zmienić port ssh i zablokować logowanie na roota. Ja ostatnio też wychwyciłem znacznie więcej ataków niz kiedykolwiek.

[KerbenII 19]

Z analizy informacji zapisanych w authlogu mogę powiedzieć, że ostatnie udane logowanie z zewnątrz do maszyny udało się z adresu:

81.15.179.6 

jest to adres utrzymywany w Polsce (najprawdopodobniej Twój własny).

 

Powodem dziwnych logów jest CRON, który podnosi uprawnienia do roota dla użytkownika admin.

Jeżeli nie chcesz, aby Twój authlog był "zaśmiecany" działaniem crona wykonaj następujące czynności:
(poradnik dla Debiana)

 

1. przejdź do katalogu /etc/pam.d otwórz ulubionym edytorem plik: common-session-noninteractive
2. poszukaj linii z takim wpisem:

   session required pam_unix.so

3. Nad tą odszukaną linijką dodaj nową z następującą zawartością:

   session [success=1 default=ignore] pam_succeed_if.so service in cron quiet use_uid 

4. zapisz plik i wyjdź z niego
5. dokonaj restartu usługi CRON poleceniem

   service cron restart

   Na koniec na wszelki wypadek można sprawdzić czy kolejne logowania się do maszyny pojawiają się w pliku auth.log. Jeżeli z jakiegoś powodu kolejne informacje w logu się nie pojawiają (bo np. wpadliśmy na pomysł grzebania w tym pliku) to restartujemy usługę rsyslogd poleceniem:

service rsyslog restart

Jeżeli chcesz zwiększyć bezpieczeństwo serwera to masz dwa warianty do wyboru:

1. Jesteś administratorem usług hostingu współdzielonego (i udostępniasz swoim klientom logowanie po SSH)
   W takim przypadku nie powinieneś zmieniać portu dla usługi SSH, tylko zainstalować i skonfigurować fail2ban (który będzie automatycznie banować userów, których IP będzie wielokrotnie wskazywać nieprawidłowe logowania).
   Pamiętaj, że takie działanie może zablokować Twojego klienta (który np. zapomniał hasła do maila) i będziesz musiał go odblokować - najlepiej, aby wtedy Strona Główna Twojego hostingu była na innej maszynie niż Twój hosting, tak, aby klient dalej miał możliwość zobaczenia Twoich informacji kontaktowych.
2. Jesteś administratorem serwera dla siebie (i/lub kilku zaprzyjaźnionych osób):
   Wtedy możesz iść na "maksa" z bezpieczeństwem. Konfigurujesz sobie OpenVPNa i na Firewallu blokujesz jakikolwiek dostęp "z zewnątrz" do SSH, FTP i innych kluczowych zasobów.
   Swoim zaufanym znajomym dajesz certyfikaty lub loginy i hasła do VPNa, dzięki któremu podłączają się oni do serwera, ale jako użytkownicy lokalni.

Z doświadczenia wiem, że nie opłaca się zmieniać domyślnego portu SSH. Może kiedyś to działało, teraz zazwyczaj boty skanują całą sieć w poszukiwaniu odpowiedzi odpowiedniego daemona, więc moim zdaniem zmiana portu SSH = po prostu utrudnienie sobie życia.

[N0Name 48]

Niby boty skanują całą sięc, ale też można zablokować skanowania portów, zawsze zwiększa bezpieczeństwo.

[Gość mariaczi]

W takim przypadku nie powinieneś zmieniać portu dla usługi SSH, tylko zainstalować i skonfigurować fail2ban (który będzie automatycznie banować userów, których IP będzie wielokrotnie wskazywać nieprawidłowe logowania).

Pamiętaj, że takie działanie może zablokować Twojego klienta (który np. zapomniał hasła do maila) i będziesz musiał go odblokować - najlepiej, aby wtedy Strona Główna Twojego hostingu była na innej maszynie niż Twój hosting, tak, aby klient dalej miał możliwość zobaczenia Twoich informacji kontaktowych.

Nie za bardzo popłynąłeś? fail2ban działa per usługa zatem zablokowanie dostepu do poczty nie zablokuje dostepu do strony. No chyba że i pocztę i stronę masz na tych samych portach Edytowano Styczeń 22, 2016 przez mariaczi (zobacz historię edycji)

[behemoth 230]

Jeśli fail2ban zablokuje Ci ip na firewallu, to odetnie też dostęp do strony

[Gość mariaczi]

Blokuje IP na firewallu ale dla konkretnego portu. Nie całe IP. Jeśli zablokuje całe IP bez wskazania portu, to oczywiście, że i do strony nie będzie dostępu. fail2ban ma jednak za zadanie blokować IP dla usługi, a nie "po całości"

[KerbenII 19]

Nie za bardzo popłynąłeś? fail2ban działa per usługa zatem zablokowanie dostepu do poczty nie zablokuje dostepu do strony. No chyba że i pocztę i stronę masz na tych samych portach

 

Zależy od konfiguracji jail.conf:

enabled = true
filter = sshd
action = iptables[name=SSH, port=ssh, protocol=tcp] #zablokuje pojedynczy port
logpath = /var/log/auth.log
maxretry = 5

enabled = true
filter = fail2ban
action = iptables-allports[name=fail2ban] #zablokuje na wszystkich portach
logpath = /var/log/fail2ban.log
maxretry = 5