LINUX.ORG.RU

Last что-то скрывает...

 


1

1

Друзья, обнаружил в локалке брутфорсер, начал судорожно проверять серверную инфраструктуру. В первую очередь гипервизор, у команды last странный вывод, у некоторых записей отсутствуют ip, хотя вход вроде как по сети.

root     pts/1        10.1.1.66        Sat Feb 29 22:55   still logged in
root     pts/1        10.1.1.66        Sat Feb 29 22:50 - 22:52  (00:01)
root     pts/1        10.1.1.66        Sat Feb 29 15:41 - 22:50  (07:09)
root     pts/1        10.1.1.66        Sat Feb 29 12:27 - 12:57  (00:30)
root     pts/1        10.1.1.66        Fri Feb 28 23:46 - 00:35  (00:49)
root     pts/1        10.1.1.66        Fri Feb 28 12:03 - 12:06  (00:03)
root     pts/1        10.1.1.66        Thu Feb 27 18:28 - 19:07  (00:39)
root     pts/1        10.1.1.66        Wed Feb 26 16:15 - 22:34  (06:18)
root     tty1                          Tue Feb 25 08:40   still logged in
reboot   system boot  5.0.15-1-pve     Tue Feb 25 08:37   still running
root     tty1                          Tue Feb 18 14:00 - 12:52 (2+22:52)
root     pts/1                         Tue Feb 18 08:22 - down  (7+00:11)
root     pts/1        10.1.1.66        Mon Feb 17 20:03 - 20:37  (00:33)
root     pts/1                         Mon Feb 17 18:05 - 20:03  (01:58)
root     pts/1        10.1.1.66        Mon Feb 10 00:26 - 01:08  (00:41)
root     tty1                          Fri Feb  7 14:47 - 22:43 (10+07:56)
reboot   system boot  5.0.15-1-pve     Thu Feb  6 08:10 - 08:33 (19+00:23)
root     pts/0        10.1.1.66        Thu Feb  6 08:02 - down   (00:01)
root     pts/0        10.1.1.66        Wed Feb  5 16:38 - 17:38  (01:00)
root     pts/0                         Thu Dec 26 17:07 - 16:38 (40+23:30)
root     tty1                          Tue Dec 24 16:25 - 17:18 (2+00:53)
root     pts/3        10.1.1.66        Mon Dec 16 14:36 - 19:11 (1+04:35)
root     pts/0                         Mon Dec 16 14:34 - 17:07 (10+02:33)
root     pts/0        10.1.1.66        Mon Dec  9 14:06 - 14:22  (00:16)
root     pts/0                         Mon Dec  9 01:20 - 14:06  (12:45)
root     pts/0                         Sat Dec  7 19:24 - 01:20 (1+05:56)
root     pts/0                         Sat Dec  7 19:23 - 19:24  (00:01)
root     pts/0                         Sat Dec  7 14:41 - 19:23  (04:42)
root     pts/0                         Sat Dec  7 14:37 - 14:41  (00:03)
root     pts/2                         Sat Nov 16 04:00 - down  (82+04:03)
root     pts/2                         Sat Nov 16 03:59 - 04:00  (00:00)
root     pts/0        10.1.1.66        Sat Nov 16 03:41 - 00:01 (1+20:20)
root     pts/0        10.1.1.66        Sat Nov 16 03:22 - 03:41  (00:18)
reboot   system boot  5.0.15-1-pve     Sat Nov 16 03:22 - 08:03 (82+04:41)
root     pts/0        10.1.1.66        Sat Nov 16 03:03 - down   (00:16)
reboot   system boot  5.0.15-1-pve     Sat Nov 16 03:02 - 03:20  (00:18)
root     pts/0        10.1.1.66        Sat Nov 16 02:41 - down   (00:19)
reboot   system boot  5.0.15-1-pve     Sat Nov 16 02:32 - 03:00  (00:27)

wtmp begins Sat Nov 16 02:32:07 2019

Это её нормальный вывод, или однозначно взломан? Команда lastb, говорит всего о 3-х неудачных входах за 3,5 месяца существования сервера, подозреваю, что я ошибался с паролем почаще, но может и кажется.



Последнее исправление: poedyatel (всего исправлений: 1)

Немного оффтопа: сейчас набегут сторонники теории массового брута по сложным паролям, пусть они посчитают, за сколько примерно они сбрутят в локалке root:AhkahF4Que например.

anonymous
()

@CaveRat в треде про спуфинга общались. Посчитаешь, сколько по времени такой пароль брутить? Я без подвоха, просто никогда логин по паролю не выключаю и ремот логин рута тоже.

anonymous
()
Ответ на: комментарий от anonymous

А почему не ключевые пары?

Пароли можно MITMить в том числе внутренними свичами организации?

anonymous
()
Ответ на: комментарий от anonymous

за сколько примерно они сбрутят в локалке root:AhkahF4Que например.

root#2PalkiLomalki_iz_JOPI#10

anonymous
()
Ответ на: комментарий от anonymous

А, кстати, кто-нибудь знает, стоит ли заморачиваться с токенами FIDO2 или U2F для SSH версии >= 8.2?

Там вроде поддержка U2F появилась, только непонятно как оно против MITM? Это U2F + ключи или только с паролем?

По идее наверно можно заюзать пару токенов: Rutoken ECP2 для ключевых пар и Token FIDO2 для второго фактора одновременно?

anonymous
()
Ответ на: комментарий от anonymous

И еще вопрос, нельзя ли серверный HSM токен для SSH временно заменить на какой-нибудь десктопный?

anonymous
()
Ответ на: комментарий от anonymous

Например-чукчоид в США на суперкомпьютере.

anonymous
()
Ответ на: комментарий от anonymous

Я тут малость без связи, сорян, и посчитать смогу только после 10-го числа :)

Вообще, 10 символов цифробуквенного уже считается не очень - штатовский NIST рекомендует пароли с битовой сложностью 80, у пароля в предыдущем клиенте будет около 60-65.

Но в брут я как-то не верю, тем более - в локалке. Слишком много следов оставляет, и не только на серваке. Любая ids начнет алертить, если увидеть брутфорс в трафике. Да даже netflow-монитор это увидит

CaveRat ★★
()
Ответ на: комментарий от CaveRat

Да я вот о том же, все кричат «логин по паролю надо обязательно отключать». Я не понимаю этого, т.к. нет смысла целенаправленно (!) брутить ssh.

anonymous
()
Ответ на: комментарий от anonymous

Вообще, есть. Как минимум, отключить логин по паролю проще, чем поддерживать парольную политику.

А брут ssh по интернетам идёт постоянно, им роботы занимаются

CaveRat ★★
()
Ответ на: комментарий от CaveRat

Если мы о своих серверах или вдс, как у спуфинга, то нормального пароля хватит. Боты брутят конечно, но не полным перебором же - максимум прогонят лист с qwerty подобными.

anonymous
()
Ответ на: комментарий от anonymous

Если мы о своих серверах или вдс, как у спуфинга, то нормального пароля хватит

Ну, как бы да.

Боты брутят конечно, но не полным перебором же - максимум прогонят лист с qwerty подобными.

Тоже верно, но этого обычно хватает.

CaveRat ★★
()
Ответ на: комментарий от anonymous

https://www.ssh.com/attack/man-in-the-middle

Various ways to prevent the attack

To protect against man-in-the-middle attacks, there needs to be some kind of shared trust or shared secret between the client and server. The most commonly used methods are:

An X.509 certificate (as in Tectia SSH and SSL/TLS)

Some kind of proprietary certificate mechanism (e.g., OpenSSH)

A public key on the client and a private key on the server (e.g., SSH)

A shared secret value (e.g., IPSec with preshared keys).
anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.