방화벽과 RSA 키 외에 SSH 연결을 보호하는 다른 방법이 있습니까?

방화벽과 RSA 키 외에 SSH 연결을 보호하는 다른 방법이 있습니까?

때로는 고정 IP가 없어서 웹 서버를 원격으로 관리해야 할 때가 있습니다. 포트 22를 더 안전하게 열기 위해 추가할 수 있는 추가 보호 계층을 찾고 있습니다.

현재 SSH를 통한 루트 비밀번호 로그인을 비활성화했습니다. 로그인하려면 RSA 키가 필요합니다(개인 키는 USB 스마트 카드에 저장되어 있음).

포트 22가 대중에게 공개된 경우 내 구성에 알려진 위험이 있습니까? 포트 22 외에도 iptables는 포트 80과 포트 443만 외부 세계에 개방합니다.

저는 Windows 컴퓨터를 사용하여 Putty를 통해 Centos 6 Linux에 연결하고 있습니다.

포트를 스캔하는 사람에게 포트가 열려 있지 않도록 포트 22에 대한 액세스를 내 특정 컴퓨터로 추가로 제한하기 위해 방화벽이나 SSH 구성에 추가할 수 있는 다른 명령문이 있습니까? 현재 iptables를 방화벽으로 사용하고 있습니다.

답변1

기존 구성은 매우 안전해 보입니다. 그러나 다른 방법을 사용하여 액세스를 제한할 수도 있습니다.

포트 노킹은 대부분의 경우 포트를 닫아두는 데 사용할 수 있습니다. 이는 iptables. 사용할 수 있는 데몬이 있거나 iptables규칙이 다음에 설명된 대로 완전히 구현될 수 있습니다.해안 벽 문서화.

TCP 래퍼가 활성화된 경우. /etc/hosts.allow(아래 표시)의 몇 가지 규칙은 에 원격으로 연결할 때 작동합니다 deamon. 첫 번째 규칙은 IP 주소 범위를 적절하게 조정하여 로컬 연결이 자동으로 작동하도록 합니다. 두 번째 규칙은 여러 국가 TLD로 전환되는 주소의 액세스를 차단하고 연결이 성공할 때마다 메시지를 이메일로 보냅니다. 포트 노크를 사용하지 않을 경우 소음이 발생할 수 있습니다.

sshd :          10.0.0.0/8 192.168.0.0/24 

sshd :          ALL \
            EXCEPT .ar .au .br .by .cl .co .cz .do .eg .gt \
                .id .il .in .jp .ma .mx .nl .pe .pk .pl .pt \
                .ro .rs .ru .sa .sg .tr .tw .ua .vn .za \
                .ae .at .bg .gh .hr .hu .ke .kz .lt .md \
                .my .no .sk .uy .ve : \
            spawn (/bin/echo "SSH connection to %N from %n[%a] allowed" | \
                /usr/bin/mailx -s "SSH Allowed" [email protected])

fail2ban규칙을 사용하면 서버에 무차별 공격을 시도하는 호스트를 일시적으로 블랙리스트에 올릴 수 있습니다. SSH를 인터넷에 노출하면 가끔 시도가 발생합니다.

답변2

다른 사람들이 말했듯이 SSH는 이미 충분히 안전한 작업을 수행하고 있습니다. sshd 데몬을 다른 위치로 옮기는 것은 의미가 없다고 생각합니다. 나는 이것을 무선 액세스 포인트를 설정하고 SSID를 숨기는 것에 비유합니다. 은밀한 조치를 통해 이러한 유형의 보안 조치를 우회하는 것은 쉽지 않습니다.

SSH 액세스나 다른 수단을 통해 루트 사용자뿐만 아니라 주요 사용자에게만 액세스를 제한하는 것은 항상 좋은 생각입니다.

내가 찾은 도움이 되는 것 중 하나는 이와 같은 것을 활용하는 것입니다 fail2ban. 이를 사용하여 잠재적인 공격자를 감지하고 대응 조치를 취하여 속도를 늦추고 중지할 수 있습니다.

답변3

SSH 설치는 이미 보안 측면에서 최첨단입니다.

당신이 할 수 있는 일이 있지만, 그것이 당신을 위한 진정한 보호보다 더 고통스러울 수 있다는 점을 명심하십시오. 포트를 22에서 잘 알려지지 않은 포트로 변경하여 수신되는 공격 및 인증 프로브 수를 줄일 수 있습니다.

답변4

서버 측의 유일한 위험은 사전 인증 취약점입니다. SSH에 대한 (공개) 기록은 많지 않습니다.

관련 정보