iptables의 모든 소스가“너무 개방 된”것으로 간주되는 경우 관련, 설립을 수락합니까?

9

규칙이 자주 -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT적용되는 것을 보았습니다 . 나는 전문가가 아니지만, 그 특정 선이 저에 관한 것입니다. 이 규칙은 연결이 설정되었거나 확립 된 연결과 관련되어 있어야하는 예외를 제외하고 모든 트래픽을 허용 합니다.

대본

22서브넷 등의 서버 LAN에서 기본 SSH 포트로의 연결을 허용합니다 192.168.0.0/16.
SuperInsecureApp®port에 무언가를 노출 1337시켜 INPUT체인에 추가합니다 .
내가 추가 한 conntrack수용 할 규칙 ESTABLISHED과 RELATED에서 모든 소스
체인 정책은 DROP

따라서 기본적으로이 구성은 LAN의 SSH 연결 만 허용하면서 세계의 포트 1337에서 인바운드 트래픽을 허용합니다.

여기가 내 혼란이 피었습니다. 겠습니까 conntrack어떤 식 으로든 하나는 얻을 수 있도록 해주는 보안 결함 노출 설정된 연결 1337에을 (그것의 세계 개방 이후), 다음 SSH 포트에 이득 액세스에 해당 연결 (또는 그 문제에 대해 다른 포트)를 활용?

security iptables ip tcp

— 덴커
소스

8

ESTABLISHED 및 RELATED 트래픽이 너무 개방 된 것으로 간주하지 않습니다. 관련을 생략 할 수 있지만 확실하게 허용해야합니다. 이러한 트래픽 카테고리는 모두 conntrack 상태를 사용합니다.

ESTABLISHED 연결은 다른 규칙에 의해 이미 검증되었습니다. 따라서 단방향 규칙을 구현하는 것이 훨씬 간단 해집니다. 이를 통해 동일한 포트에서 트랜잭션을 계속할 수 있습니다.

관련 연결도 다른 규칙에 의해 검증됩니다. 많은 프로토콜에는 적용되지 않습니다. 다시 규칙을 구성하는 것이 훨씬 간단 해졌습니다. 또한 적용되는 연결의 올바른 순서를 보장합니다. 이것은 실제로 규칙을 더 안전하게 만듭니다. 이렇게하면 다른 포트에서 연결할 수 있지만 해당 포트는 FTP 데이터 연결과 같은 관련 프로세스의 일부 여야합니다. 허용되는 포트는 프로토콜 별 conntrack 모듈에 의해 제어됩니다.

ESTABLISHED 및 RELATED 연결을 허용하면 방화벽에서 허용 할 새 연결에 집중할 수 있습니다. 또한 반환 트래픽을 허용하지만 새로운 연결을 허용하는 규칙이 위반되는 것을 방지합니다.

포트 1337의 프로그램을 안전하지 않은 것으로 분류했으면 루트가 아닌 전용 사용자 ID를 사용하여 시작해야합니다. 이것은 응용 프로그램을 크랙하고 향상된 액세스 권한을 얻는 사람이 할 수있는 피해를 제한합니다.

포트 1337의 연결이 포트 22에 원격으로 액세스하는 데 사용될 가능성은 거의 없지만 포트 1337에 대한 연결을 사용하여 포트 22에 대한 연결을 프록시 할 수 있습니다.

SSH가 심층적으로 보호되도록 할 수 있습니다.

방화벽 제한 외에도 hosts.allow를 사용하여 액세스를 제한하십시오.
루트 액세스를 방지하거나 최소한 키를 사용해야하며 authorized_keys 파일에서 액세스를 제한하십시오.
로그인 실패 감사. 로그 스캐너는 비정상적인 활동에 대한 정기적 인 보고서를 보낼 수 있습니다.
반복 된 액세스 실패시 자동으로 액세스를 차단하려면 fail2ban과 같은 도구를 사용하십시오.

— BillThor
소스

이것은 임의의 예 였지만 새 서버에서 가장 먼저하는 일은 sshd에서 항상 루트 액세스 및 일반 텍스트 인증을 비활성화하는 것입니다. 이는 매우 유용한 팁입니다. 또한 fail2ban은 실제로 예제에서 영감을 얻은 실제 설정에 이미 설치되어 있습니다. "확립 된 연결은 다른 규칙에 의해 이미 검증되었습니다" 는 제가 확신하지 못했던 질문에 대한 정확한 답변이었습니다. 당신의 명확한 답변에 감사드립니다!

— Dencker

부수적 질문 : 성능 관점에서 conntrack규칙이 체인의 시작 또는 끝에있는 경우 전혀 변경 됩니까? 내가 이해 한 iptables것처럼, 연결이 끝났다면 설정된 연결에 대한 모든 규칙을 처리해야하며 처음에 배치 된 경우 하나의 규칙 만 처리해야합니까?

— Dencker

@Dencker 먼저 ESTABLISHED, RELATED 규칙을 원합니다. 가장 많은 트래픽을 허용합니다. 가독성을 높이는 것이 가장 좋지만 트래픽을 가장 많이 수용하는 규칙을 원할 수도 있습니다. 내 규칙은 그룹화되고 지연 시간에 민감하며 트래픽이 많은 (유형별로 그룹화) 기타입니다. IPtables에는 각 규칙이 처리하는 트래픽 양을 확인할 수있는 카운터가 있습니다. Shorewall을 사용하여 유용한 기본값을 추가하고 방화벽을 만들기 위해 규칙 파일을 쉽게 읽을 수 있습니다.

— BillThor

2

ESTABLISHED 및 RELATED는 "상태 저장"패킷 필터링의 기능으로, 필터링은 정적 규칙 세트뿐만 아니라 패킷이 고려되는 컨텍스트에도 의존합니다. 연결이 작동하려면 ESTABLISHED가 필요하며 관련 ICMP 메시지와 관련이 있어야합니다. 상태 저장 필터링을 사용하면 정적 "상태 비 저장"규칙과 비교하여 더 정확하게 필터링 할 수 있습니다.

먼저 ESTABLISHED를 보자. 예를 들어, 포트 22 개시 (클라이언트)는이 전송에 TCP 생각 SYN에 serverIPaddr:22. 서버는 SYN+ACK클라이언트로 돌아갑니다 . 이제 클라이언트가을 보내야합니다 ACK. "일치하는" ACK만 허용 되도록 서버의 필터링 규칙은 어떻게 보 입니까? 일반적인 상태 비 저장 규칙은 다음과 같습니다.

-A INPUT --proto tcp --port 22 -j ACCEPT

이는 정식 규칙보다 더 자유 롭습니다. 상태 비 저장 규칙은 임의의 TCP 세그먼트를 허용합니다 (예 : ACK또는FIN 제 연결을 설정하지 않고있다. 포트 스캐너는 이러한 종류의 OS 지문 인식 동작을 이용할 수 있습니다.

이제 관련을 보자. ICMP 메시지, 주로 오류 메시지에 사용됩니다. 예를 들어, 서버에서 클라이언트로의 패킷이 삭제되면 오류 메시지가 서버로 전송됩니다. 이 오류 메시지는 이전에 설정된 연결과 "관련되어"있습니다. 관련 규칙이 없으면 일반적으로 들어오는 오류 메시지 (컨텍스트없이)를 허용하거나 많은 사이트의 사용자 정의에 따라 ICMP를 모두 삭제하고 전송 계층에서 시간 초과를 기다릴 필요가 있습니다. (이것은 IPv6에게는 좋지 않은 아이디어입니다. ICMPv6은 IP 레거시 ICMP보다 IPv6에서 더 중요한 역할을합니다.)

— 카운터 모드
소스