Назад | Перейти на главную страницу

SSH-атаки, как их имена пользователей попадают в auth.log? (pw auth отключен)

Таким образом, этот компьютер доступен через порт 22 (отовсюду).
Поскольку сообщения, указывающие на неудачные попытки входа в систему (такие как root, cgi, bash, production ...), наводнили /var/log/auth.log, я отключил аутентификацию по паролю с внешних IP-адресов (используя только аутентификацию с открытым ключом).
И это работает, когда я пытаюсь подключиться к этой машине по ssh с внешнего IP-адреса (без ключа), я даже не получаю приглашение имени пользователя:

В разрешении отказано (публичный ключ).

Так как же все эти фальшивые имена пользователей все еще попадают в auth.log?

  1 Aug  4 17:02:48 host sshd[17190]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=217.116.204.99  user=root
  2 Aug  4 17:02:48 host sshd[17190]: pam_winbind(sshd:auth): getting password (0x00000388)  
  3 Aug  4 17:02:48 host sshd[17190]: pam_winbind(sshd:auth): pam_get_item returned a password  
  4 Aug  4 17:02:48 host sshd[17190]: pam_winbind(sshd:auth): request wbcLogonUser failed: WBC_ERR_AUTH_ERROR, PAM error:

PAM_USER_UNKNOWN (10), NTSTATUS: NT_STATUS_NO_SUCH_USER, сообщение об ошибке 4 возраст: Нет такого пользователя
5 августа 4 17:02:50 host sshd [17190]: сбой пароля для root от 217.116.204.99 порта 40054 ssh2
6 августа 4 17:02:50 хост sshd [17190]: Получено отключение от 217.116.204.99: 11: Пока, пока [preauth]
...
513322 7 апреля, 19:45:40 хост sshd [15986]: input_userauth_request: неверный пользовательский cgi [preauth]
...

http://paste.debian.net/92403/

Хотя вы не вводите имя пользователя, если вы подключаетесь с рабочей станции linux / osx / bsd, имя пользователя неявно (по умолчанию используется имя пользователя, под которым вы вошли в систему), если у вас есть окна и вы используете шпатлевку, попробуйте подключиться без установки Автоматически войдите в систему и представьте ключ, он попросит имя пользователя, чтобы попытаться сопоставить пару.

Ключи заменяют только пароли, каждый из них связан с пользователем (и, следовательно, с именем пользователя), поэтому вы найдете authorized_keys файл под ~/.ssh/ .

Вы, вероятно, видите, что злоумышленники делают что-то похожее на ssh bash@<your.server.ip> . Сервер видит имя пользователя, но, поскольку они не предоставляют ключ, им отказывают в доступе.