OpenSSH 보강

OpenSSH (또는 Secure Shell) 는 telnet 프로 토 콜 을 대체 하여 원 격 접근 을 위 한 기 존 기준 이 됩 니 다.SSH 는 telnet 등 프로 토 콜 을 불필요 하 게 만 들 었 습 니 다. 그 중에서 대부분 은 연결 이 암호 화 되 고 일반 텍스트 로 암 호 를 공개 적 으로 전송 하지 않 기 때 문 입 니 다.
그러나 부족 한 ssh 설 치 는 완벽 하지 않다.ssh 서버 를 운영 할 때 몇 가지 간단 한 절차 가 당신 의 설 치 를 뚜렷하게 보강 할 수 있 습 니 다.
 
1. 추측 하기 어 려 운 구령/사용자 이름 사용
 
만약 당신 이 운영 하 는 ssh 가 대외 적 인 것 이 라면, 당신 이 먼저 발견 할 수 있 는 일 은 해 킹 이 사용자 의 이름/구령 의 기록 을 추측 하려 고 시도 하 는 것 일 수 있 습 니 다.해 킹 은 일반적으로 포트 22 (ssh 결 성 경청 포트) 를 스 캔 하여 ssh 를 실행 하 는 기 계 를 찾 아 강제로 공격 하려 고 한다.추측 하기 어 려 운 구령 을 사용 함으로써 우 리 는 어떤 공격 도 성공 하기 전에 기록 되 고 주 의 를 받 기 를 바란다.
당신 이 이미 추측 하기 어 려 운 구령 을 채택 하 기 를 바 랍 니 다.그렇지 않 으 면 다음 과 같은 특징 을 가 진 암 호 를 선택 하 십시오.

최소 8 글자

큰 해서 체 와 가 는 해서 체 자모

가 동시에 있다.

자모 와 숫자 가 동시에 있다

비 영수 문자 (예 를 들 어! "£ $% ^ 등 특별 문자)

예측 하기 어 려 운 암 호 를 사용 하 는 것 은 ssh 뿐만 아니 라 시스템 안전 에 도 영향 을 줄 수 있 습 니 다. 암 호 를 사용 하 는 더 많은 정 보 는 CentOS 문서 에서 찾 을 수 있 습 니 다.
http://www.centos.org/docs/4/html/rhel-sg-en-4/s1-wstation-pass.html
사용자 가 알 아 맞 히 기 쉬 운 암 호 를 사용 하 는 것 을 전혀 막 을 수 없다 면 무 작위 로 생 성 되 거나 추측 하기 어 려 운 글자 로 사용자 이름 을 사용 하 는 것 을 고려 하 십시오. 나 쁜 사람 이 사용자 이름 을 추측 할 수 없다 면 암 호 를 강요 할 수 없습니다. 그러나 이것 은 은밀 한 정보 로 안전 을 바 꿀 뿐 이 므 로 사용자 이름 이 사용자 가 보 낸 이메일 등 경 로 를 통 해 누설 되 는 것 을 주의해 야 합 니 다.
 
2. 루트 로그 인 중지
 
SSH 서버 설정 은/etc. shh/sshd confg 파일 에 저 장 됩 니 다. 루트 로그 인 을 중지 하려 면 다음 줄 이 있 는 지 확인 하 십시오.
 

#    root   ：
PermitRootLogin no

 
그리고 sshd 서 비 스 를 다시 유도 하 십시오.
 

service sshd restart

 
루트 권한 이 필요 하 다 면 일반 사용자 로 로그 인 한 다음 su 명령 을 사용 하 십시오.
 
3. 사용자 로그 인 제한
 
SSH 로그 인 은 원 격 접근 이 필요 한 사용자 에 게 만 제 한 될 수 있 습 니 다. 시스템 에 많은 사용자 가 있다 면 원 격 접근 을 제한 하 는 것 이 합 리 적 인 방법 입 니 다. 다른 사용자 가 사용 하기 쉬 운 암 호 를 사용 하 는 영향 을 줄 이 는 것 입 니 다./etc/ssh/sshd config 에 AllowUsers 줄 을 추가 하여 사용자 이름 을 빈 칸 으로 나 누 는 것 입 니 다. 예 를 들 어:
 

AllowUsers alice bob

 
그리고 sshd 서비스 다시 안내 해 주세요.
 
4. 제 1 류 프로 토 콜 사용 정지
 
SSH 는 두 가지 프로 토 콜 을 사용 할 수 있 습 니 다. 첫 번 째 클래스 및 두 번 째 클래스 프로 토 콜 입 니 다. 오래된 첫 번 째 클래스 프로 토 콜 보다 안전성 이 낮 기 때문에 사용 을 중지 해 야 합 니 다. 사용 해 야 한 다 는 것 을 알 지 않 는 한./etc/ssh/sshd config 파일 에서 다음 줄 을 찾 아 설명 을 해제 하고 다음 과 같이 수정 하 십시오.
 

# Protocol 2,1
Protocol 2

 
그리고 sshd 서 비 스 를 다시 유도 하 세 요.
 
5. 비표 준 포트 38332 사용
 
결 성 된 값 에 따라 ssh 는 포트 22 에서 내부 연결 을 듣 습 니 다. 해 킹 이 ssh 가 기계 에서 작 동 하 는 지 여 부 를 단정 하려 면 포트 22 를 스 캔 하 는 것 이 가장 좋 습 니 다. 그 를 효과적으로 헷 갈 리 게 하 는 방법 은 표준 이 아 닌 포트 에서 ssh 를 실행 하 는 것 입 니 다. 사용 되 지 않 은 포트 는 모두 가능 하지만 1024 이상 을 선 호 합 니 다. 많은 사람들 이 2222 를 교체 단 으로 선택 합 니 다.8080 이 HTTP 대체 포트 로 자주 사용 되 는 것 처럼 입 (기억 하기 쉽 습 니 다). 이 때문에 좋 은 선택 이 아 닙 니 다. 포트 22 를 스 캔 하 는 해커 도 포트 2222 를 놓 치지 않 기 때 문 입 니 다. 사용 되 지 않 은 고위 포트 를 무 작위 로 선택 하 는 것 이 좋 습 니 다. 변경 하려 면/etc/ssh/sshd config 파일 에 다음 줄 을 추가 하 십시오.
 

#            ssh：
Port 38332  #  

 
그리고 sshd 서 비 스 를 다시 유도 합 니 다. 공유 기 및 관련 방화벽 규칙 에 필요 한 변경 사항 을 잊 지 마 십시오.
ssh 는 더 이상 표준 포트 에서 연결 을 듣 지 않 기 때문에 클 라 이언 트 에 게 어느 포트 에 연결 할 지 알려 야 합 니 다. 명령 행 에서 ssh 클 라 이언 트 를 실행 할 때 - p 옵션 으로 포트 를 지정 할 수 있 습 니 다.
 

$ ssh -p 2345 myserver

 
또는 konqueror 의 fish 프로 토 콜 을 사용 하면 다음 을 사용 할 수 있 습 니 다.
 

fish://myserver:2345/remote/dir

 
연결 할 때마다 포트 를 지정 하 는 것 이 고 통 스 러 우 면 개인 적 인 ~/. ssh/config 파일 에 지정 한 포트 기록 을 추가 하 십시오.
 

 #     ~/.ssh/config
Host myserver
HostName 72.232.194.162
        User bob
        Port 2345

 
~/. ssh/config 는 다음 과 같은 접근 권 이 있어 야 합 니 다:
 

$ chmod 600 ~/.ssh/config

 
 
6. 방화벽 에 SSH 걸 러 내기
 
만약 IP 주소 로 원 격 접근 을 해 야 한다 면 (예 를 들 어 사무실 에서 집에 들 어 가 는 서버) 공유 기 나 iptables 에 방화벽 을 추가 하 는 규칙 을 고려 하여 포트 22 의 접근 권 을 특정한 IP 주소 로 제한 하고 이 를 통 해 연결 을 걸 러 낼 수 있 습 니 다. 예 를 들 어 iptables 에서 이 유형의 규칙 으로 이 목적 을 달성 할 수 있 습 니 다.
 

iptables -A INPUT -p tcp -s 72.232.194.162 --dport 22 -j ACCEPT

 
SSH 도 TCP 포장 함 식 에 내 장 된 지원 이 있 기 때문에 ssh 서비스의 방문 권 은 host. allow 와 hosts. deny 로 동시에 통제 할 수 있다.
만약 당신 이 출처 의 IP 주 소 를 제한 할 수 없고 ssh 포트 를 공개 해 야 한다 면, iptables 는 같은 IP 주소 에서 온 중복 로그 인 시 도 를 기록 하고 차단 함으로써 강제 적 인 공격 을 막 을 수 있 습 니 다. 예 를 들 어:
 

iptables -A INPUT -p tcp --dport 22 -m recent --set --name ssh --rsource
iptables -A INPUT -p tcp --dport 22 -m recent ! --rcheck --seconds 60 --hitcount 4 --name ssh --rsource -j ACCEPT

 
첫 번 째 규칙 은 recent 모듈 을 이용 하여 모든 방문 포트 22 의 시 도 를 기록 합 니 다. 두 번 째 규칙 은 이 IP 주소 가 과거 60 이동 내 에 4 번 이상 연결 을 시도 하 였 는 지 확인 합 니 다. 압축 을 더 받 아들 이지 않 았 다 면 이 규칙 은 입력 체인 이 DROP 의 결 성 정책 을 사용 해 야 합 니 다.
다음은 또 다른 사례 입 니 다. 이번 에는 iptables 의 limit 모듈 을 사용 하여 ssh 포트 의 분당 최대 3 개의 연결 을 제한 합 니 다.
 

iptables -A INPUT -p tcp --dport 22 --syn -m limit --limit 1/m --limit-burst 3 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 --syn -j DROP

 
첫 번 째 줄 은 포트 22 에 새 연결 을 받 아들 일 때 1 분 동안 세 번 이상 연결 하지 않 은 IP 주소 에서 나 와 야 합 니 다. 세 번 이상 연결 을 시도 하면 지난 1 분 동안 나타 나 려 고 시도 하면 두 번 째 줄 은 이 연결 을 중단 합 니 다.
표준 이 아 닌 포트 에서 ssh 를 실행 할 경우 포트 에 대한 수정 을 잊 지 마 십시오. 상황 이 허 가 된 경우 방화벽 을 이용 하여 여과 하 는 것 은 ssh 서버 를 보강 하 는 매우 효과 적 인 방법 입 니 다. Don 't forget to change the port as appropriate if you are running ssh on a non - standard port. Where possible, filtering at the firewall is an extremely effective method of securing access to an ssh server.
 
7. 공공/전용 키 로 검증
 
암호 화 키 를 사용 하여 인증 하 는 것 은 두 가지 장점 을 제공 합 니 다. 우선, 공공/전용 키 를 사용 하면 편리 합 니 다. 암 호 를 입력 하지 않 아 도 되 기 때 문 입 니 다. (암호 로 키 를 보호 하지 않 는 한)둘째, 서버 가 키 에 대한 검증 을 할 수 있 을 때 암호 검증 을 완전히 중단 할 수 있 습 니 다. 즉, 방문 할 때 권한 을 수 여 받 은 키 에 의존 하기 때문에 암 호 를 추측 하려 는 시도 가 없습니다.
ssh 서버 에 키 를 만 들 고 설치 하 는 것 은 상대 적 으로 간단 한 과정 입 니 다.
우선, 서버 에 연 결 된 클 라 이언 트 에 한 쌍 의 키 를 만 들 것 입 니 다. (연결 할 기계 마다 이렇게 해 야 합 니 다)
 

$ ssh-keygen -t rsa

 
이렇게 하면 당신 의 (숨겨 진) ~/. ssh 디 렉 터 리 에 id rsa 와 id rsa. pub 라 는 두 개의 파일 을 설치 합 니 다. id rsa 는 당신 의 전용 키 이 고, id rsa. pub 는 당신 의 공공 키 입 니 다.
연결 할 때마다 암 호 를 묻 지 않 으 려 면 키 쌍 을 만 들 때 엔 터 만 암 호 를 누 르 십시오. 암 호 를 만 들 때 암 호 를 암호 화 할 지 여 부 는 순 전 히 당신 의 결정 입 니 다. 암 호 를 암호 화하 지 않 고 로 컬 기 계 를 빼 앗 으 면 원 격 서버 의 ssh 접근 권 이 자동 으로 있 습 니 다. 또한 로 컬 기기 의 루트 는 당신 의 루트 에 접근 할 수 있 습 니 다.키: 하지만 루트 (또는 루트 가 점령 되 었 습 니 다) 를 믿 지 못 한다 면 큰 화 를 입 었 습 니 다. 키 암호 화 를 암호 화하 여 암호 화 되 지 않 은 ssh 서버 를 버 리 고 추가 보안 을 바 꾸 려 면 암 호 를 입력 하여 이 키 를 사용 하 십시오.
현재 당신 의 전용 키 에 권한 을 설정 합 니 다:
 

$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/id_rsa 

 
공공 키 (id rsa. pub) 를 서버 에 복사 한 다음 authorized keys 목록 에 설치 하 십시오.
 

$ cat id_rsa.pub >> ~/.ssh/authorized_keys

 
주: 그러나 공공 키 를 입력 하면 서버 에서 삭제 할 수 있 습 니 다.
마지막 으로 서버 에 있 는 파일 권한 설정:
 

$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/authorized_keys

 
/etc/ssh/sshd config 에 있 는 StrictModes 가 활성화 되면 (값 부족) 이상 의 권한 이 필요 합 니 다.
현재 서버 에 로그 인 할 때 암 호 를 입력 하지 않 아 도 됩 니 다.
그러나 서버 에 로그 인 할 수 있 는 키 쌍 을 확인 한 적 이 있 습 니 다./etc/ssh/sshd conf 파일 에 다음 설정 을 추가 하여 암호 인증 을 중단 할 수 있 습 니 다.
 

#       ，      
PasswordAuthentication no

 
 
8. 흔 한 질문 (FAQ)
 
― CentOS 는 X 버 전의 OpenSSH 를 사용 하고 있 으 며, 최신 버 전 은 Y 버 전 입 니 다. X 버 전 은 심각 한 안전성 구멍 이 있 습 니 다. 업 그 레이 드 를 해 야 합 니까?
답: 그 럴 리 가 없습니다. 상위 공급 자 들 은 최신 버 전의 안전성 수정 을 기 존 발행 버 전 으로 역방향 으로 이식 하 는 정책 이 있 습 니 다. 최신 업데이트 만 있 으 면 CentOS 발행 버 전 은 이미 전면적으로 수정 되 었 습 니 다. 역방향 이식 안전성 수정 에 관 한 자세 한 내용 은 여 기 를 참조 하 십시오.
http://www.redhat.com/advice/speaks_backport.html
 
9. 연결
 
http://www.centos.org/docs/5/html/Deployment_Guide-en-US/ch-openssh.html