☰

보안 검토: SSH 로그인 시도 분류 [닫기]

tag-icon • tag-icon ssh security logs aws
보안 검토: SSH 로그인 시도 분류 [닫기]

AWS EC2 Ubuntu Linux 인스턴스에 대한 내 SSH 로그인이 다음과 같이 표시됩니다.

Nov 18 07:32:21 ip-10-20-30-40 sshd[9487]: Accepted publickey for ubuntu from 15.26.37.48 port 46273 ssh2: RSA SHA256:e37A/qiEdkHHNpeksdPO

내가 달릴 때희귀한취약점을 찾는 명령

ubuntu@ip-12-34-56-78:~$ grep "Failed password" /var/log/auth.log
ubuntu@ip-12-34-56-78:~$ egrep "Failed|Failure" /var/log/auth.log
ubuntu@ip-12-34-56-78:~$ grep "Failed password" /var/log/auth.log | awk '{print $11}' | uniq -c | sort -nr
ubuntu@ip-12-34-56-78:~$ journalctl _SYSTEMD_UNIT=ssh.service | egrep "Failed|Failure"
ubuntu@ip-12-34-56-78:~$ journalctl _SYSTEMD_UNIT=sshd.service | grep "failure"

아무것도 나타나지 않습니다. 여태까지는 그런대로 잘됐다.

그런데 로그 파일을 찾아보던 중 두 가지 의심스러운 문제를 발견했습니다. 먼저 "인증 실패"가 표시됩니다.

ubuntu@ip-12-34-56-78:~$  grep "authentication failure" /var/log/auth.log

Nov 14 09:23:19 ip-12-34-56-78 sshd[9711]: Disconnecting authenticating user root 98.76.54.32 port 36745: Too many authentication failures [preauth]
Nov 14 09:23:22 ip-12-34-56-78 sshd[9713]: Disconnecting authenticating user root 98.76.54.32 port 36754: Too many authentication failures [preauth]
Nov 16 11:45:29 ip-12-34-56-78 sshd[20710]: Disconnecting invalid user admin 15.48.27.78 port 51289: Too many authentication failures [preauth]

둘째, ssh로 접속해도 아래와 같은 줄이 뜹니다.ssh -i myKeyPair.pem [email protected]

Nov 17 17:17:01 ip-12-34-56-78 CRON[948]: pam_unix(cron:session): session opened for user root by (uid=0)
Nov 17 17:17:01 ip-12-34-56-78 CRON[948]: pam_unix(cron:session): session closed for user root

Nov 17 18:23:25 ip-12-34-56-78 sshd[1004]: Invalid user stuart from 34.55.89.144 port 32946
Nov 17 18:23:25 ip-12-34-56-78 sshd[1004]: Connection closed by invalid user stuart 34.55.89.144 port 32946 [preauth]

Nov 17 07:29:47 ip-12-34-56-78 sshd[32620]: Invalid user ubnt from 21.34.55.89 port 56171
Nov 17 07:29:47 ip-12-34-56-78 sshd[32620]: error: Received disconnect from 21.34.55.89 port 56171:14: Unable to connect using the available authentication methods [preauth]
Nov 17 07:29:47 ip-12-34-56-78 sshd[32620]: Disconnected from invalid user ubnt 21.34.55.89 port 56171 [preauth]

Nov 17 12:39:00 ip-12-34-56-78 sshd[32695]: Did not receive identification string from 233.55.89.13 port 54959

Nov 17 23:51:58 ip-12-34-56-78 sshd[1396]: Received disconnect from 144.233.55.89 port 42056:11: Normal Shutdown, Thank you for playing [preauth]
Nov 17 23:51:58 ip-12-34-56-78 sshd[1396]: Disconnected from invalid user sinusbot 144.233.55.89 port 42056 [preauth]
Nov 17 23:52:24 ip-12-34-56-78 sshd[1398]: Invalid user sinusbot from 144.233.55.89 port 57180

확실하지 않은 질문이 많이 있습니다.

  1. "놀아주셔서 감사합니다"는 무슨 농담인가요? 이것은 나쁜 게임 서버가 아닙니다. 응?
  2. 자동으로 "기회를 잡으려고" 노력하는 것처럼 보이는 "스튜어트"와 같은 사용자가 많이 있습니다. 이건 그냥 로봇인가요?
  3. 이러한 시도가 발생하거나 처리되는 것을 방지할 수 있는 구성이 있습니까?
  4. 예전에는 ssh-keygen을 통해 파일을 생성한 후 원격 서버에 복사/붙여넣기를 했었는데, 지금은 AWS를 사용하고 있습니다. 방해 없이 허용됩니다. 내가 맞나요?ssh -i myKeyPair.pem [email protected]
  5. 가장 중요한 것은:공개 키 SSH를 유일한 인증 방법으로 선택했던 기억이 나지만 AWS 설정에서도 이것저것 시도해 보았습니다. 나나 다른 누구도 SSH에 공개 키 외에 아무것도 열려 있지 않은지 지속적으로 확인하기 위해 어떤 테스트를 실행할 수 있습니까?

답변1

1~3까지의 단답형 문제

덜 혼란스러운 분석을 위해 나는 그것이 꼭 필요 last -i하다고 생각합니다 lastb -i.

  • 이 preauth기호는 로그인 시도 실패를 나타냅니다.

  • 이것놀러 와줘서 고마워요기호에는 관리자의 유머 감각이 약간 있습니다.

  • 실패한 시도는 모두 기록됩니다.

  • 말씀하신 대로 "게이트"는 인터넷에 열려 있습니다. 따라서 포트 범핑을 구성하지 않는 한 전 세계의 모든 호스트가 "게이트에 도달"합니다.

일반적으로 공개 키가 ssh구성에 대한 유일한 인증 방법인 경우 스크립트 봇은 공격하기가 거의 불가능합니다. 그러나 한 달에 수천 번 또는 그 이상을 시도할 수도 있습니다.

그러한 시도가 우려된다면 설치하고 구성할 수 있습니다.실패 2 금지.

더 긴 답변과매트릭스에 오신 것을 환영합니다

로봇과 낮게 매달린 과일

경험이 부족한 대부분의 관리자는 로그 파일을 보기 시작할 때 당황할 수 있습니다. 제가 질문을 받았을 때 귀하가 게시한 것과 동일한 질문을 많이 하기 시작했다는 것을 알고 있습니다. 이는 인터넷에서 끝이 없어 보이는 해킹 수에 대한 일반적인 반응입니다.

내 기술 친구들과 동료들은 내가 보고 있는 것이 표적 공격이 아니라 자동화된 스크립트 확인을 위한 대부분의 쉬운 결과라고 확신했습니다. 그리고 그건...

평판이 좋지 않은 다양한 장소에서 사고 팔 수 있는 사용자 이름과 비밀번호 목록이 있습니다. 스크립트 봇을 실행하는 개인은 이러한 목록 중 하나 이상을 구매하고 이를 사용하여 특정 서브넷 내의 모든 컴퓨터에 액세스하려고 시도하며 전체 IPv4 주소 공간을 크롤링할 수도 있습니다.

이것이 바로 다음과 같은 약 100개의 이름이 시리즈로 표시되는 이유입니다.프레드, 샐리, 조지... 등등...당신은 당신의 이름이나 비슷한 것을 볼 수도 있습니다. 이메일과 같이 실행할 수 있는 다른 서비스에도 마찬가지입니다. 파일을 보면 /var/log/mail.log동일한 유형의 사용자 이름과 비밀번호 조합 해킹 시도를 볼 수 있습니다.

이러한 공격은 봇입니다. 서버에 합리적인 보안 조치가 구성되어 있으면 ssh해커 시도로 인해 손상될 가능성이 줄어듭니다.

SSH 키

SSH 키 쌍에는 공개 구성요소와 비공개 구성요소가 있습니다. 비공개 구성요소는 절대 배포하면 안 됩니다. 공용 구성 요소는 ~/.ssh/authorized_keys대상 서버의 파일 에 배치되어야 합니다 .

공개 키 인증 중에는 개인 키나 해당 키에 대한 비밀번호가 연결을 통해 전송되지 않습니다. 인증되면 ssh합의된 대칭 세션 키를 사용하여 세션이 암호화됩니다. 귀하의 개인 키를 훔치는 공격자는 여전히 귀하의 비밀번호를 알아내야 합니다. 그리고 공격자는 개인 키가 저장된 컴퓨터를 손상시키지 않고는 해당 암호를 스니핑할 수 없어야 합니다.

SSH 키는 암호화 개체이므로 알고리즘 종료 날짜 및/또는 특정 알고리즘의 수명 전반에 걸쳐 발견된 취약점이 적용됩니다. 따라서 서버 소프트웨어를 자주 업데이트하고 새로 발견된 문제가 있는지 사용자 키를 확인하는 것이 중요합니다.

이 글을 쓰는 시점에서 표준 알고리즘은 여전히 ​​RSA 2048인 것으로 보입니다. AWS 키 스크립트는 다음을 기반으로 RSA 2048 키를 생성합니다.AWS 설명서. 그러나 키가 훨씬 짧고 알고리즘이 국가 기관이나 잠재적으로 손상된 개체와 독립적으로 개발된 것으로 추정되므로 모든 키를 Curve 25519로 변경했습니다.

서버 감사 및 기록 보관

처음에 SSH 공개키 인증을 활성화하고 비밀번호 인증도 비활성화한 것을 보여주었기 때문에 원격 공격자가 공개키 인증을 비활성화했다고 의심할 이유가 없습니다. 귀하의 AWS 계정 자체가 손상되지 않는 한 이는 사실입니다. 그러나 AWS 계정에 액세스하는 데 사용된 예상치 못한 IP 주소에 대한 알림을 받을 수도 있습니다.

더 긴 로깅을 원할 경우 로그 파일 보존 시간을 연장 logrotate하거나 설치할 수 있습니다.심사.

구성의 온전성 수준

소규모/개인 서버를 위한 제정신 SSH 보안 대책

  • 공개키 인증과 공개키 전용 인증
  • 루트 사용자에 대한 SSH 액세스 비활성화
  • sudo루트 권한이 필요한 사용자에게만 활성화됩니다 .
  • 최소 2048비트의 RSA 키 또는 곡선 25519 키를 사용하세요.
  • 개인 키 자료를 서버에 절대 두지 마십시오
  • 꼭 필요한 경우가 아니면 X11 전달을 비활성화합니다.

대부분의 신규 설치에서 변경해야 하는 유일한 설정은 공개 키 인증 활성화 및 X11 비활성화입니다.

/etc/ssh/shhd_config

...
PermitRootLogin no
...
PubkeyAuthentication yes
PasswordAuthentication no
X11Forwarding no
...

미친 SSH 보안

위의 내용 외에도 포트 노킹을 활성화하고 호스트 키를 단일 알고리즘(예: 곡선 25519)으로 제한하고 서버의 호스트 키 지문을 도메인의 DNS 레코드에 넣은 다음 DNSSEC를 사용하여 해당 레코드를 보호할 수 있습니다.

  • 서버의 호스트 키를 제한하려면 사용할 알고리즘의 주석 처리를 해제하고 서버를 다시 시작하면 됩니다 sshd. 이 작업이 완료되고 다시 연결을 시도하면 호스트 키가 일치하지 않습니다. 로컬에 저장된 호스트 키 지문을 교체하려고 할 때 연결 지침을 따르십시오.

/etc/ssh/sshd_config

...
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
...
  • sshfp선택한 호스트 키에 대한 DNS 레코드를 생성하려면:

ssh-keygen -r domain.tld -f /etc/ssh/ssh_host_ed25519_key

결과 레코드는 도메인의 DNS 영역 파일에 저장될 수 있으며 ssh연결에서 해당 지문을 확인합니다. 이렇게 하면 처음 연결하거나 서버의 호스트 키가 변경될 때 SSH에 대한 중간자 공격을 방지할 수 있습니다.

그리고 문서에 따라 구성하십시오.

knockd is a port-knock server.  It listens to all traffic on an ethernet (or PPP) interface, looking for special "knock" sequences of port-
hits.  A client makes these port-hits by sending a TCP (or UDP) packet to a port on the server.  This port need not be open -- since knockd
listens  at the link-layer level, it sees all traffic even if it's destined for a closed port.  When the server detects a specific sequence
of port-hits, it runs a command defined in its configuration file.  This can be used to open up holes in a firewall for quick access.

....

[options]
     logfile = /var/log/knockd.log

[openSSH]
     sequence    = 7000,8000,9000
     seq_timeout = 10
     tcpflags    = syn
     command     = /usr/sbin/iptables -A INPUT -s %IP% --dport 22 -j ACCEPT

[closeSSH]
     sequence    = 9000,8000,7000
     seq_timeout = 10
     tcpflags    = syn
     command     = /usr/sbin/iptables -D INPUT -s %IP% --dport 22 -j ACCEPT
  • DNSSEC 구성여기서는 더 자세한 내용을 설명하지 않습니다. 그러나 DNS 스푸핑은 DNSSEC가 해결하는 실제 문제라는 점을 기억하는 것이 중요합니다.

관련 정보