Hacker memintas iptables

9

(dipindahkan dari SO)

Saya memiliki iptables yang melindungi server sip. Ini memblokir semua IP kecuali yang saya buka secara khusus, dan tampaknya berfungsi untuk hampir semua orang. Saya telah menguji dari banyak alamat ip yang tidak terdaftar putih dan mereka semua dijatuhkan sebagaimana mestinya.

TETAPI, saya telah mengambil "peretas" yang tampaknya bisa mem-bypass aturan iptables. INVITEsnya yang menyelidik berhasil, dan saya tidak tahu bagaimana, atau bahkan itu mungkin. Dalam 10 tahun saya belum pernah melihat ini sebelumnya.

Saya kira itu pasti sesuatu yang telah saya lakukan, tetapi saya tidak bisa melihatnya.

iptables dibuat seperti ini (MYIP didefinisikan di atas - disunting):

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

Sekarang, dengan NOTHING di ALLOWEDSIP, yang harus saya lakukan hanyalah SSH in (yang saya bisa). Jika saya melakukan panggilan, mereka semua akan dijatuhkan. Tapi wireshark menunjukkan ini kepada saya (ip saya dihapus):

89.163.146.25 -> x.x.x.x SIP/SDP 805 Request: INVITE sip:[email protected] |
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 |

Panggilannya menghantam saklar saya dan, meskipun akhirnya ditolak oleh ACL, mereka seharusnya tidak pernah sampai di sana. Tidak ada lagi yang berhasil. Menarik rambutku. Adakah yang tahu

Hanya untuk kelengkapan, inilah hasil dari 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

EDIT: baru saja melihat ini dari wireshark. Mungkinkah mereka melakukan sesuatu yang mengerikan seperti ditegakkan dengan cara lain kemudian bermain pada aturan yang ditetapkan? Mungkin mereka bermain di suatu lubang di TERKAIT?

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

EDIT 2: UDP adalah kuncinya di sini. Ketika saya mengatur OpenSIPS untuk hanya mendengarkan TCP, masalahnya sepertinya hilang. Tidak ada satu pun dari upaya mereka yang berhasil, meskipun mereka mengirim lebih banyak pesan "tag-pm" itu. Tidak menjelaskan mengapa paket-paket itu bahkan bisa dibuka. iptables seharusnya menghentikannya terlebih dahulu. Ingin tahu apa yang saya lakukan salah di sini.

EDIT 3: Jika saya menghapus TERKAIT saya berhenti membalas mereka, jadi itu ada hubungannya dengan itu. Tapi saya pikir saya perlu berhubungan. Adakah tips tentang penyelesaian masalah?

David Wylie
sumber
1
ESTABLISHEDharus bekerja untuk UDP. Tampaknya paket mengalir dan menerima balasan untuk permintaan (keluar). Apakah "peretas" Anda memiliki IP statis? ;-) Jika demikian, centang / proc / net / nf_conntrack untuk melihat isi tabel negara tentang mereka ketika mereka saat ini / tidak / terhubung ... RELATEDadalah hal yang lebih rumit ... Tidak tahu apa fungsinya untuk SIP . Apakah modprobemungkin menampilkan modul ipt_sip atau sesuatu yang dimuat yang akan melakukan hal-hal "ajaib"?
Marki
@Marki - terima kasih atas tipnya. / proc / net / nf_conntrack tidak ada (centos 7) jadi saya harus mencari tahu apa / mengapa / di mana.
David Wylie
2
"conntrack-tools" adalah masalahnya, dapat diinstal dari repo, lalu menjalankan "conntrack -L" tampaknya mencantumkannya. Akan melihat apa yang menghasilkan. Namun tipikal, dia berhenti. Semoga hanya jeda.
David Wylie
1
Jika memungkinkan: Cobalah untuk membatasi RELATEDuntuk -p icmp. Mungkin ini menyelesaikannya (atau merupakan pekerjaan yang sesuai di sekitar yang tidak mengharuskan Anda untuk membaca tentang pembantu pembantu).
norak
1
Anda mengacaukan berbagai hal dengan menambahkan rantai. Jika ACCEPT chain diperiksa sebelum ALLOWEDSIP kustom Anda, maka ALLOWEDSIP dapat menjadi tidak berguna.
Overmind

Jawaban:

1

Satu-satunya penjelasan yang masuk akal bagaimana cara kerjanya adalah, bahwa entah bagaimana datagram UDP yang menyinggung itu lewat --state ESTABLISHED,RELATED.

Mengingat bahwa UDP adalah protokol stateless, saya ragu bahwa statemodul memiliki pelacakan yang efektif.

Untuk menyelesaikan masalah ini, saya akan membatasi pemeriksaan status ke protokol TCP dengan:

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

Dan pra-filter ALLOWEDSIPdengan protokol UDP (dan lebih disukai, dengan port tujuan juga):

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

Anda dapat membatalkan nol. Ini harus memotong iptables.

route add 89.163.146.25 gw 127.0.0.1 lo

Periksa

netstat -nr

ATAU

route -n
remoteitguy
sumber
Dia ingin menambal lubang melawan penyerang baru, bukan hanya memblokir yang ini.
Zdenek