Skocz do zawartości
Zaloguj się, aby obserwować  
krk

logi serwera auth.log

Polecane posty

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 przez krk (zobacz historię edycji)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Czy nie masz przypadkiem na tym serwerze wgranego DirectAdmin?

 

niee jest vestacp

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
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 przez mariaczi (zobacz historię edycji)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
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" ;)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

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

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Bądź aktywny! Zaloguj się lub utwórz konto

Tylko zarejestrowani użytkownicy mogą komentować zawartość tej strony

Utwórz konto

Zarejestruj nowe konto, to proste!

Zarejestruj nowe konto

Zaloguj się

Posiadasz własne konto? Użyj go!

Zaloguj się

Zaloguj się, aby obserwować  

×