(SO에서 이동)
SIP 서버를 보호하는 iptables가 있습니다. 내가 특별히 열었던 IP를 제외한 모든 IP를 차단하며 거의 모든 사람에게 효과적입니다. 화이트리스트에없는 많은 IP 주소에서 테스트를 마쳤으며 모두 정상적으로 삭제되었습니다.
그러나 나는 iptables 규칙을 우회 할 수있는 것처럼 보이는 "해커"를 선택했습니다. 그의 조사 초대는 그것을 통해 이루어지고, 나는 그것이 어떻게, 또는 심지어 그것이 가능했는지 전혀 모른다. 10 년 동안 나는 이것을 본 적이 없다.
나는 그것이 내가 한 일이라고 생각하지만 그것을 볼 수는 없습니다.
iptables는 다음과 같이 생성됩니다 (MYIP는 최상위에 정의 됨).
iptables -F
iptables -X
iptables -N ALLOWEDSIP
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -p tcp -d $MYIP --dport 22 -j ACCEPT
iptables -t filter -A INPUT -j ALLOWEDSIP
# This is my white list.
iptables -A ALLOWEDSIP -j RETURN
이제 ALLOWEDSIP에 NOTHING이 있으면 할 수있는 SSH 만 있으면됩니다. 전화를 걸면 모두 삭제됩니다. 그러나 wireshark는 이것을 보여줍니다 (내 IP가 수정되었습니다).
89.163.146.25 -> x.x.x.x SIP/SDP 805 Request: INVITE sip:521088972597572280@x.x.x.x |
x.x.x.x -> 89.163.146.25 SIP 417 Status: 100 Giving a try |
x.x.x.x -> 89.163.146.25 SIP 875 Status: 407 Proxy Authentication Required |
그의 전화는 내 스위치를 쳤고 결국 ACL에 의해 거부되었지만 결코 거기에 도착해서는 안됩니다. 다른 것은 통과되지 않습니다. 머리를 뽑아 누구 알아?
완전성을 위해 iptables -L의 결과는 다음과 같습니다.
# iptables -L --line-numbers -v
Chain INPUT (policy DROP 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 10 640 ACCEPT all -- any any anywhere anywhere state RELATED,ESTABLISHED
2 0 0 ACCEPT all -- lo any anywhere anywhere
3 0 0 ACCEPT tcp -- any any anywhere <redacted>.com tcp dpt:6928
4 0 0 ALLOWEDSIP all -- any any anywhere anywhere
Chain FORWARD (policy DROP 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 6 packets, 544 bytes)
num pkts bytes target prot opt in out source destination
Chain ALLOWEDSIP (1 references)
num pkts bytes target prot opt in out source destination
1 0 0 RETURN all -- any any anywhere anywhere
편집 : 방금 wireshark에서 이것을 보았습니다. 그들은 다른 방식으로 확립 된 다음 확립 된 규칙을 따르는 것과 같이 끔찍한 일을하고있을 수 있습니까? 아마 그들은 관련의 구멍에서 놀고 있습니까?
89.163.146.25 -> <redacted> RTCP 806 Source port: tag-pm Destination port: sip
편집 2 : UDP가 핵심입니다. TCP 만 수신하도록 OpenSIPS를 설정하면 문제가 사라지는 것 같습니다. "tag-pm"메시지를 더 많이 보내지 만 더 이상 시도하지 않습니다. 패킷이 opensip에 도달하는 이유를 설명하지 않습니다. iptables가 먼저 중지해야합니다. 내가 여기서 잘못한 것을 알고 싶습니다.
편집 3 : 관련을 제거하면 응답을 중지하므로 그와 관련이 있습니다. 그러나 나는 관련이 필요하다고 생각합니다. 해결 방법에 대한 팁이 있습니까?
RELATED
에 -p icmp
. 어쩌면 이것이 해결됩니다 (또는 conntrack 도우미에 대해 읽을 필요가없는 적절한 해결책입니다).
ESTABLISHED
UDP에서 작동합니다. 패킷 흐름을 확인하고 (발신) 요청에 대한 응답을 수락합니다. "해커"는 고정 IP를 가지고 있습니까? 그래서, 체크 / proc 디렉토리 / 그물 /의 nf_conntrack들이 현재시 상태 테이블이 그들에 대해에 포함 된 내용을 볼 경우 ;-) /하지 / 연결 ...RELATED
더 까다로운 일이 ... 할 일이되지는 SIP에 대해 무엇을 알고 .modprobe
ipt_sip 모듈 또는 "매직"작업을 수행하는로드 된 무언가가 표시 됩니까 ?