들어오는 SSH 연결을 허용하는 IPTables 규칙


11

이 스크립트의 목적은 localhost <-> localhost 및 들어오는 SSH 트래픽을 제외하고 VPN을 통한 트래픽 만 허용하는 것입니다. 그러나 SSH를 통해 스크립트를 실행하면 연결이 끊어지고 VM을 다시 시작해야합니다. 내 스크립트에 어떤 문제가 있습니까?

#!/bin/bash
iptables -F

#Allow over VPN
iptables -A INPUT -i tun+ -j ACCEPT
iptables -A OUTPUT -o tun+ -j ACCEPT

#Localhost
iptables -A INPUT -s 127.0.0.1/8 -j ACCEPT
iptables -A OUTPUT -d 127.0.0.1/8 -j ACCEPT

#VPN
iptables -A INPUT -s 123.123.123.123 -j ACCEPT
iptables -A OUTPUT -d 123.123.123.123 -j ACCEPT

#SSH
iptables -A INPUT -p tcp --dport ssh -j ACCEPT

#Default Deny
iptables -A INPUT -j DROP
iptables -A OUTPUT -j DROP

답변:


10

출력 체인은 모든 패킷 전송을 담당 합니다.

스크립트는 아웃 바운드 패킷이 123.123.123.123에서 인터페이스, 로컬 호스트 및 원격 호스트로 터널링 할 수 있도록합니다.

SSH 데몬이 위의 것 이외의 대상으로 패킷을 보내도록 서버에 연결하는 경우 트래픽이 나가지 않습니다.

SSH 데몬에서 SSH 클라이언트로의 아웃 바운드 패킷을 허용하려면 다음 규칙을 추가해야합니다.

iptables -A OUTPUT -p tcp --sport 22 -j ACCEPT

단일 위치에서만 연결하는 경우 위의 규칙에 대상 IP 기준을 추가 할 수도 있습니다. 이 규칙은 출력 체인에 대한 궁극적 인 'DROP any other'규칙보다 우선해야합니다.


+1 이것은 작동하며 확립 된 관련 규칙을 사용하는 것 (상황에 따라 다소 유용하게 만드는 것)보다 더 구체적입니다.
goldilocks

두 가지 훌륭한 답변 모두 많이 배웠습니다! @ SkyDan 답변을 테스트했으며 제대로 작동합니다!
Steven

Nitpick : 출력 체인은 전달 된 패킷을 담당하지 않습니다 .
Björn Lindqvist

13

귀하의 #SSH규칙은 ssh가 의사 소통의 한 가지 방법 인 것을 암시합니다. 데이터 보내어되고 백.

클라이언트 측의 포트 번호를 미리 알 수 없기 때문에이를 처리하는 일반적인 방법 은 확립 된 연결 과 "확립 된"또는 "관련된" 것으로 간주되는 연결을 허용하는 것입니다 . 이를 위해서는 다음이 필요합니다.

-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

DROP규칙 전에 (그리고 규칙이 순서대로 처리되고이 두 규칙이 대부분의 패킷에 적용되므로) 맨 위가 바람직합니다.

여기에 TCP 연결이 어떻게 설정되는지에 대한 설명이 있습니다 . 본질적으로 서버가 #SSH INPUT규칙에 의해 허용 된 패킷에 응답한다는 사실이 그렇게합니다.


1
작동하지 않습니다. 확립은 주어진 TCP 연결에 대해 양방향 으로 패킷을 보았 음을 의미합니다. 이 규칙 만 추가하면 첫 번째 아웃 바운드 패킷이 계속 차단됩니다.
hellodanylo

2
@SkyDan 여기에 대한 참조가 있습니다. 다이어그램에서 서버가 오프닝 syn를 수신 한 후 syn / ack를 클라이언트로 다시 보내면 연결 이 설정됩니다. 즉 iptables는 다음과 같은 응답을 통해 해당 패킷을 회신 할 수 있습니다. 리턴 패킷 (SYN / ACK)이 확인되면 연결을 ESTABLISHED로 간주합니다. " -> 다시 : iptables 서버가 보내려는 리턴 패킷을 보고 연결을 설정 한 후 응답을 허용합니다.
goldilocks

1
좋아, 나는 그것이 왜 효과가 있는지 알 것이다. iptables man은 예외적 인 TCP 핸드 셰이크 패킷에 대한 단어가 아니라 양방향으로 패킷을 보는 것에 대해서만 이야기하기 때문에 약간 모호합니다. 참조 주셔서 감사합니다!
hellodanylo

2
@SkyDan 실제로 논리는 tcp에만 적용되지 않습니다 -p tcp.이 점에서 차이를 만드는 것이 잘못되어 해당 페이지의 UDP에 대한 후속 설명을 참조하십시오 (동일 함). 요점은 서버가 iptables가 허용할지 여부를 알지 못하고 응답하고 iptables가 로컬 시스템의 서버에서 해당 응답을 수신 하면 클라이언트가 아직하지 않더라도 양방향으로 트래픽을 본 것입니다. 연결이 설정되고 회신을 보냅니다. 여기서 "기술" 은 두 당사자 의 중간 에있는 방화벽에 달려 있습니다.
goldilocks

1
당신은 거기에 맞습니다. 누군가이 정보를 iptables 맨에 포함시켜야합니다.
hellodanylo
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.