놀라울 정도로 높은 비율의 "봇넷" SSHD 로그인 실패에 대처하기 위한 팁은 무엇입니까?

Question 1

무작위로 선택된 IPv4 주소로 향하는 악의적인 시도의 비율은 어느 정도입니까?

인터넷의 배경 소음: 노출된 호스트 및 서비스에 대한 인터넷 검색의 상당 부분에 대한 일상적이고 자동화된 드래그넷(IPv4 주소를 특별히 대상으로 하는 것이 아니라) 검색입니다. 노출된 SSHD에서만 하루에 수백 건의 로그인/악용 시도가 쉽게 발생하는 연속적인 프로브 스트림(특정 공급자 IP 주소 범위가 다른 것보다 더 많이 타겟팅되는 경우 숫자는 수십에서 수천까지 다양할 수 있음) 다양한 소스:

부지런한 제공업체(안전하지 않거나 취약하거나 손상된 시스템을 운영할 때 고객에게 경고/연결을 끊기 위해 취약성 스캐너를 실행할 수 있음)
연구 프로젝트(예를 들어shodan.io및 기타) 및 기타 호기심 많은 사람들
악의적인 행위자(탐색을 실행하기 위해 봇넷을 사용할 수 있음)
기타 등등

이에 대응하여 어떤 조치를 취해야 합니까, 아니면 그냥 참아야 합니까?

일반적으로 서버와 서비스를 인터넷에 노출할 때 전체 인터넷의 연결과 가장 중요한 남용(시도)을 예상해야 합니다.

공공서비스를 목적으로 하지 않는 경우그 다음에인터넷 전체에 노출되어서는 안 됩니다.
가능한 경우: 모범 사례는 액세스 제어를 적용하는 것입니다. 이는 여러 가지 형태를 취할 수 있지만 일반적으로 알려진 IP 주소 및/또는 알려진 IP 주소 범위에 대한 액세스를 제한하는 것입니다. 또는 좋은 IP 주소 범위를 정확히 알지 못하는 경우 유효한 액세스 요구 사항이 없을 가능성이 높은 범위를 차단합니다.
IP 주소(범위)를 지리적 위치에 연결하는 것은 100% 신뢰할 수 있거나 완전하지 않지만 Geo-IP 데이터를 사용하는 액세스 목록은 그런 점에서 매우 유용할 수 있습니다.

액세스 제어는 보안 그룹이나 방화벽 어플라이언스와 같은 호스트 외부에서 설정할 수 있습니다. 그러면 서버 자체는 이를 유지하기 위해 리소스를 제공할 필요가 없습니다.

호스트 기반 방화벽(Linux netfilter/iptables/nftables)과 같은 호스트 기반 액세스 제어나 애플리케이션 자체의 액세스 제어가 더 유연하지만 호스트 자체의 리소스도 필요한 경우가 많습니다. 예를 들어 이는 종종 사용자마다 다른 IP 주소 제한을 설정하는 유일한 방법일 수 있습니다.

서비스를 의도한 경우공공 서비스를 위해, 예를 들어 공개 웹사이트가 있는 웹 서버,일반적으로 액세스 제어를 적용하지 않습니다., 실제 사이트 방문자는 어디에서나 환영받기 때문입니다.
이러한 공공 서비스는 다음과 같은 접근 방식을 취하는 경우가 많습니다. 모든 곳에서 액세스를 허용하지만악의적인 행동을 탐지하고 악의적인 행위자가 사용하는 IP 주소를 (일시적으로) 차단합니다.. 같은 도구Fail2ban그러한 접근 방식 중 하나입니다.IDS 및 IPS 시스템또 다른.

_{예:내 고향인 암스테르담에 있는 현지 레스토랑의 테이크아웃 주문 페이지와 온라인 예약 시스템에 대한 액세스 제어 목록입니다. 암스테르담의 IP 주소에 대한 액세스만 허용하도록 설정하지는 않습니다. 이는 아마도 지나치게 제한적일 수 있으며 예를 들어 휴대폰을 사용하여 사이트에 액세스하는 유효한 지역 방문자를 거부할 수 있습니다.

그러나 반면에 유로파 외부에서 할당 및 사용 중인 것으로 알려진 IP 주소 범위를 차단하고 예를 들어 아프리카, 아시아 태평양, 북미 및 남미 지역에서 사용되는 경우 남용 시도 횟수를 크게 줄여야 하며 가능성은 낮습니다. 예약/테이크아웃 주문 수에 영향을 미칩니다.

대조적으로 동일한 웹 서버의 SSH 액세스에 대한 액세스 제어 목록은 사이트 관리자의 고정 IP 주소, 사무실 게이트웨이 및/또는 고정 IP 주소 또는 IP 주소가 없는 경우로 쉽게 제한될 수 있습니다. VPN 서버를 해당 ISP에서 사용하는 범위로 확장합니다.}

높은 비율의 악의적인 시도를 처리하는 데 더 최적화된 대체 SSH 서버 소프트웨어 패키지가 있습니까? 예를 들어, sshd는 인증 전에 새로운 연결마다 새 프로세스를 생성하는데, 이는 불필요한 오버헤드가 많이 발생하는 것처럼 보입니다.

나는 귀하가 실제 리소스 요구 사항과 로그인 시도의 영향을 크게 과대평가하고 있다고 생각하고 희망합니다. 내가 본 노출된 VPS 시스템에서 "정상적인" 수준의 SSH 남용 시도가 생성하는 부하는 실제 애플리케이션 부하에 비해 무시할 수 있는 수준입니다.

HTTP를 열어야 할 때 SSH를 차단하는 것은 약간 무의미해 보입니다.

보안에 대한 일반적인 접근 방식은 다음과 같습니다.최소 권한의 원칙; 방화벽 규칙에서는 다음과 같이 해석됩니다.

기본적으로 모든 것을 차단합니다
필요한 사람에게만 필요한 것에 대한 액세스를 허용합니다.

따라서 전 세계가 아닌 일부 IP 주소에서만 ssh 액세스를 허용하고 전 세계가 포트 80(일반 https로 리디렉션) 및 443 기본 https 포트에 대한 액세스를 허용하는 것은 의미가 없습니다.

Answer

무작위로 선택된 IPv4 주소로 향하는 악의적인 시도의 비율은 어느 정도입니까?

인터넷의 배경 소음: 노출된 호스트 및 서비스에 대한 인터넷 검색의 상당 부분에 대한 일상적이고 자동화된 드래그넷(IPv4 주소를 특별히 대상으로 하는 것이 아니라) 검색입니다. 노출된 SSHD에서만 하루에 수백 건의 로그인/악용 시도가 쉽게 발생하는 연속적인 프로브 스트림(특정 공급자 IP 주소 범위가 다른 것보다 더 많이 타겟팅되는 경우 숫자는 수십에서 수천까지 다양할 수 있음) 다양한 소스:

부지런한 제공업체(안전하지 않거나 취약하거나 손상된 시스템을 운영할 때 고객에게 경고/연결을 끊기 위해 취약성 스캐너를 실행할 수 있음)
연구 프로젝트(예를 들어shodan.io및 기타) 및 기타 호기심 많은 사람들
악의적인 행위자(탐색을 실행하기 위해 봇넷을 사용할 수 있음)
기타 등등

이에 대응하여 어떤 조치를 취해야 합니까, 아니면 그냥 참아야 합니까?

일반적으로 서버와 서비스를 인터넷에 노출할 때 전체 인터넷의 연결과 가장 중요한 남용(시도)을 예상해야 합니다.

공공서비스를 목적으로 하지 않는 경우그 다음에인터넷 전체에 노출되어서는 안 됩니다.
가능한 경우: 모범 사례는 액세스 제어를 적용하는 것입니다. 이는 여러 가지 형태를 취할 수 있지만 일반적으로 알려진 IP 주소 및/또는 알려진 IP 주소 범위에 대한 액세스를 제한하는 것입니다. 또는 좋은 IP 주소 범위를 정확히 알지 못하는 경우 유효한 액세스 요구 사항이 없을 가능성이 높은 범위를 차단합니다.
IP 주소(범위)를 지리적 위치에 연결하는 것은 100% 신뢰할 수 있거나 완전하지 않지만 Geo-IP 데이터를 사용하는 액세스 목록은 그런 점에서 매우 유용할 수 있습니다.

액세스 제어는 보안 그룹이나 방화벽 어플라이언스와 같은 호스트 외부에서 설정할 수 있습니다. 그러면 서버 자체는 이를 유지하기 위해 리소스를 제공할 필요가 없습니다.

호스트 기반 방화벽(Linux netfilter/iptables/nftables)과 같은 호스트 기반 액세스 제어나 애플리케이션 자체의 액세스 제어가 더 유연하지만 호스트 자체의 리소스도 필요한 경우가 많습니다. 예를 들어 이는 종종 사용자마다 다른 IP 주소 제한을 설정하는 유일한 방법일 수 있습니다.

서비스를 의도한 경우공공 서비스를 위해, 예를 들어 공개 웹사이트가 있는 웹 서버,일반적으로 액세스 제어를 적용하지 않습니다., 실제 사이트 방문자는 어디에서나 환영받기 때문입니다.
이러한 공공 서비스는 다음과 같은 접근 방식을 취하는 경우가 많습니다. 모든 곳에서 액세스를 허용하지만악의적인 행동을 탐지하고 악의적인 행위자가 사용하는 IP 주소를 (일시적으로) 차단합니다.. 같은 도구Fail2ban그러한 접근 방식 중 하나입니다.IDS 및 IPS 시스템또 다른.

_{예:내 고향인 암스테르담에 있는 현지 레스토랑의 테이크아웃 주문 페이지와 온라인 예약 시스템에 대한 액세스 제어 목록입니다. 암스테르담의 IP 주소에 대한 액세스만 허용하도록 설정하지는 않습니다. 이는 아마도 지나치게 제한적일 수 있으며 예를 들어 휴대폰을 사용하여 사이트에 액세스하는 유효한 지역 방문자를 거부할 수 있습니다.

그러나 반면에 유로파 외부에서 할당 및 사용 중인 것으로 알려진 IP 주소 범위를 차단하고 예를 들어 아프리카, 아시아 태평양, 북미 및 남미 지역에서 사용되는 경우 남용 시도 횟수를 크게 줄여야 하며 가능성은 낮습니다. 예약/테이크아웃 주문 수에 영향을 미칩니다.

대조적으로 동일한 웹 서버의 SSH 액세스에 대한 액세스 제어 목록은 사이트 관리자의 고정 IP 주소, 사무실 게이트웨이 및/또는 고정 IP 주소 또는 IP 주소가 없는 경우로 쉽게 제한될 수 있습니다. VPN 서버를 해당 ISP에서 사용하는 범위로 확장합니다.}

높은 비율의 악의적인 시도를 처리하는 데 더 최적화된 대체 SSH 서버 소프트웨어 패키지가 있습니까? 예를 들어, sshd는 인증 전에 새로운 연결마다 새 프로세스를 생성하는데, 이는 불필요한 오버헤드가 많이 발생하는 것처럼 보입니다.

나는 귀하가 실제 리소스 요구 사항과 로그인 시도의 영향을 크게 과대평가하고 있다고 생각하고 희망합니다. 내가 본 노출된 VPS 시스템에서 "정상적인" 수준의 SSH 남용 시도가 생성하는 부하는 실제 애플리케이션 부하에 비해 무시할 수 있는 수준입니다.

HTTP를 열어야 할 때 SSH를 차단하는 것은 약간 무의미해 보입니다.

보안에 대한 일반적인 접근 방식은 다음과 같습니다.최소 권한의 원칙; 방화벽 규칙에서는 다음과 같이 해석됩니다.

기본적으로 모든 것을 차단합니다
필요한 사람에게만 필요한 것에 대한 액세스를 허용합니다.

따라서 전 세계가 아닌 일부 IP 주소에서만 ssh 액세스를 허용하고 전 세계가 포트 80(일반 https로 리디렉션) 및 443 기본 https 포트에 대한 액세스를 허용하는 것은 의미가 없습니다.

Question 2

나는 이전에 SSH에 대한 Slowloris 유형의 공격을 본 적이 없습니다. 문서를 보면 MaxStartups는 이들이 동일한 클라이언트에서 온 것인지 여부에 대해 신경 쓰지 않는 것 같습니다(즉, 이를 사용하여 DOS를 용이하게 할 수 있습니다). 공격 패턴에 따라 첫 번째 대응은 iptables connlimit(클라이언트 IP당 연결 제한)를 사용하는 것입니다.

Fail2ban은 대부분의 SSH 공격에 대한 확실한 솔루션이지만(HTTP[S] 트래픽에도 사용했습니다) ipset을 사용하도록 구성되었는지 확인하십시오.

IP 주소를 변경하는 것은 장기적으로 도움이 되지 않을 것입니다.

내가 액세스할 수 있는 다른 VPS를 제외한 모든 곳에서 SSH를 차단합니다.

예. 점프 박스를 사용하는 것은 매우 일반적인 관행입니다. 다시 한번 말씀드리지만 이것은 스스로 할 수 있는 일입니다. 포트 22에 대한 기본 방화벽 규칙을 설정한 다음 점프박스를 화이트리스트에 추가하기만 하면 됩니다. SSH에는 사용을 투명하게 해주는 기능도 내장되어 있습니다.

ssh -J [email protected] [email protected]

또는 ssh_config에서 이를 설정할 수 있습니다 ssh targethost.example.com.

Host jumpbox.example.com
   User: jumpuser
   IdentityFile: ~/.ssh/jumpuser.id_rsa

Host targethost.example.com
   User: user
   ProxyCommand: ssh -q -W %h:%p [email protected]:22 
   IdentityFile: ~/.ssh/user.id_rsa

실패한 시도에 대한 로그 메시지를 무음으로 설정하시겠습니까?

나는 이것을 옹호하지 않을 것입니다. 무단 액세스를 방지하기 위해 합당한 조치를 취했다면 이를 무시해도 됩니다.

Pepoluan이 제안한 것처럼 비표준 포트와 포트 노킹을 사용할 수도 있습니다(후자는 사용할 수 있음).순수하게 iptables로 구현됨knockd를 사용하지 않고)

Answer

나는 이전에 SSH에 대한 Slowloris 유형의 공격을 본 적이 없습니다. 문서를 보면 MaxStartups는 이들이 동일한 클라이언트에서 온 것인지 여부에 대해 신경 쓰지 않는 것 같습니다(즉, 이를 사용하여 DOS를 용이하게 할 수 있습니다). 공격 패턴에 따라 첫 번째 대응은 iptables connlimit(클라이언트 IP당 연결 제한)를 사용하는 것입니다.

Fail2ban은 대부분의 SSH 공격에 대한 확실한 솔루션이지만(HTTP[S] 트래픽에도 사용했습니다) ipset을 사용하도록 구성되었는지 확인하십시오.

IP 주소를 변경하는 것은 장기적으로 도움이 되지 않을 것입니다.

내가 액세스할 수 있는 다른 VPS를 제외한 모든 곳에서 SSH를 차단합니다.

예. 점프 박스를 사용하는 것은 매우 일반적인 관행입니다. 다시 한번 말씀드리지만 이것은 스스로 할 수 있는 일입니다. 포트 22에 대한 기본 방화벽 규칙을 설정한 다음 점프박스를 화이트리스트에 추가하기만 하면 됩니다. SSH에는 사용을 투명하게 해주는 기능도 내장되어 있습니다.

ssh -J [email protected] [email protected]

또는 ssh_config에서 이를 설정할 수 있습니다 ssh targethost.example.com.

Host jumpbox.example.com
   User: jumpuser
   IdentityFile: ~/.ssh/jumpuser.id_rsa

Host targethost.example.com
   User: user
   ProxyCommand: ssh -q -W %h:%p [email protected]:22 
   IdentityFile: ~/.ssh/user.id_rsa

실패한 시도에 대한 로그 메시지를 무음으로 설정하시겠습니까?

나는 이것을 옹호하지 않을 것입니다. 무단 액세스를 방지하기 위해 합당한 조치를 취했다면 이를 무시해도 됩니다.

Pepoluan이 제안한 것처럼 비표준 포트와 포트 노킹을 사용할 수도 있습니다(후자는 사용할 수 있음).순수하게 iptables로 구현됨knockd를 사용하지 않고)

Question 3

내 제안:

SSH 포트를 22에서 다른 것으로 변경하십시오.
봇이 여전히 포트를 찾을 수 있으면 knockd포트 노킹을 구현하도록 서버를 설치하고 구성하세요.

Answer

내 제안:

SSH 포트를 22에서 다른 것으로 변경하십시오.
봇이 여전히 포트를 찾을 수 있으면 knockd포트 노킹을 구현하도록 서버를 설치하고 구성하세요.

Question 4

공용 IP를 통해 SSH를 노출하면 조만간 스캔되며 위협 행위자는 VPS 공급자나 네트워크에 관계없이 인증 시도를 시도합니다.

다음과 같은 Ansible 플레이북을 사용하여 SSH 구성을 강화하겠습니다. https://github.com/dev-sec/ansible-collection-hardening/tree/master/roles/ssh_hardening

또는 전체 서버를 강화하는 이 플레이북: https://github.com/konstruktoid/ansible-role-hardening

그리고 나는 또한 Fail2ban을 추천하고 싶습니다. Fail2Ban: 여러 인증 오류를 일으키는 호스트를 금지합니다. Fail2Ban은 /var/log/auth.log와 같은 로그 파일을 검사하고 너무 많은 로그인 시도 실패를 수행하는 IP 주소를 금지합니다. 구성 가능한 시간 동안 해당 IP 주소로부터의 새 연결을 거부하도록 시스템 방화벽 규칙을 업데이트하여 이를 수행합니다.

또는 VPS 네트워크에 대한 VPN 연결을 생성하거나 OpenVPN(예를 들어)을 사용하여 VPS에 VPN 서버를 생성하고 VPN 뒤에 SSH를 배치하고 인터넷에 노출시키지 않을 수도 있습니다.

Answer