Hacker iptables atlama


9

(SO'dan taşındı)

Bir yudum sunucusu korumak iptables var. Özellikle açtığım IP'ler hariç tüm IP'leri engelliyor ve neredeyse herkes için çalışıyor gibi görünüyor. Beyaz listelenmeyen ip adresleri bir sürü test ettik ve hepsi gerektiği gibi düştü.

AMA, iptables kurallarını atlayabilen bir "hacker" aldım. Araştırma yapan INVITE'leri bunu başardı ve nasıl ya da bunun mümkün olduğunu bilmiyorum. 10 yıl içinde bunu daha önce görmedim.

Sanırım yaptığım bir şey olmalı ama göremiyorum.

iptables böyle yaratıldı (MYIP yukarıda tanımlandı - düzeltildi):

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

Şimdi, İZİN VERİLEN HİÇBİR ŞEY ile, yapabileceğim tek şey SSH (ki yapabilirim). Eğer ona çağrı atarsam hepsi düşüyor. Ama wireshark bana bunu gösterir (benim ipim düzeltildi):

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 |

Onun çağrıları benim anahtarımı vurdu ve sonuçta ACL tarafından reddedilmesine rağmen, asla oraya gitmemeliler. Başka hiçbir şey geçemez. Saçımı çekiyorum. Kimse biliyor mu?

Sadece tamlık için, iptables -L'nin sonucu şudur:

# 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

EDIT: bunu wireshark'tan gördüm. Belirlenmiş kural üzerinde oynamaktan başka bir şekilde kurulmak gibi korkunç bir şey yapıyor olabilirler mi? Belki İLGİLİ bir deliğe oynuyorlar?

89.163.146.25 -> <redacted> RTCP 806 Source port: tag-pm  Destination port: sip

DÜZENLEME 2: UDP burada anahtar. OpenSIPS'i yalnızca TCP dinleyecek şekilde ayarladığımda, sorun ortadan kalkıyor gibi görünüyor. Bu "tag-pm" iletilerinden daha fazlasını gönderiyor olsalar da, girişimlerinin hiçbiri artık gerçekleşmiyor. Yine de paketlerin neden açılmaya başladığını açıklamıyor. iptables ilk önce onları durdurmalıydı. Burada neyi yanlış yaptığımı bilmek isterdim.

DÜZENLEME 3: İLİŞKİ kaldırırsam onlara yanıt vermemeye başladım, bu yüzden bununla ilgili bir şey var. Ama bence buna ihtiyacım var. Geçici çözümlerle ilgili ipuçlarınız var mı?


1
ESTABLISHEDUDP için çalışmalı. Görünüşe göre paket akışı ve (giden) isteklerin yanıtlarını kabul ediyor. "Bilgisayar korsanlarının" statik IP'leri var mı? ;-) Öyleyse, / proc / net / nf_conntrack'ı kontrol edin / şu anda / bağlı değilken durum tablosunun onlar hakkında neler içerdiğini görmek için ... RELATEDdaha zor bir şeydir ... SIP için ne yaptığını bilmiyorum . Does modprobebelki bu "sihirli" şeyler yapacağını yüklenir.İşte bir ipt_sip modülü veya bir şey göstermek?
Marki

@Marki - bu ipucu için teşekkürler. / proc / net / nf_conntrack mevcut değil (centos 7) bu yüzden ne / neden / nerede olduğunu bulmam gerekecek.
David Wylie

2
"conntrack-tools" şey, repo yüklenebilir, daha sonra "conntrack -L" çalıştırmak onları listelemek gibi görünüyor. Bunun ne getireceğini görecek. Yine de tipik olarak, durdu. Umarım sadece bir duraklama olur.
David Wylie

1
Mümkünse: sınırlamaya çalışın RELATEDiçin -p icmp. Belki de bunu çözer (veya etrafınızdaki yardımcılar hakkında okumanızı gerektirmeyen uygun bir çalışmadır).
corny

1
Bir zincir ekleyerek etrafı karıştırdın. KABUL zincirleri özel ALLOWEDSIP'inizden önce kontrol edilirse, ALLOWEDSIP işe yaramaz olabilir.
Olağanüstü Zeka

Yanıtlar:


1

Nasıl çalışabileceğine dair tek makul açıklama, rahatsız edici UDP datagramlarının bir şekilde geçmesidir --state ESTABLISHED,RELATED.

UDP'nin durum bilgisi olmayan bir protokol olduğu göz önüne alındığında, statemodülün üzerinde etkili bir izleme olduğundan şüpheliyim .

Sorunu çözmek için, devlet denetimini TCP protokolüyle sınırlandırırım:

-A INPUT -m tcp -m state -p tcp --state ESTABLISHED,RELATED -j ACCEPT`

Ve ALLOWEDSIPUDP protokolü ile ön filtre (ve tercihen hedef port ile de):

iptables -t filter -A INPUT -m udp -p udp --dport 5060 -j ALLOWEDSIP

-2

Nullroute yapabilirsiniz. Bu iptables'ı atlamalıdır.

route add 89.163.146.25 gw 127.0.0.1 lo

Kontrol et

netstat -nr

VEYA

route -n

Deliği sadece bunu engellemekle kalmayıp yeni bir saldırgana karşı yama yapmak istiyor.
Zdenek
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.