NEW conntrack pada paket ACK: apa yang tidak dibuktikannya
ACK berlabel NEW berarti pelacak tidak punya status yang cocok, bukan bahwa VPN membuka sesi. Baca hook, tuple, dan jendela tangkapan.
Di log firewall ada satu baris yang tidak Anda duga: paket ACK, status conntrack NEW, alamat sumber yang bukan milik Anda, port tujuan terbuka. Godaannya adalah membacanya sebagai koneksi masuk baru yang tidak diizinkan siapa pun. Yang sebenarnya dikatakan baris itu lebih sempit: saat paket itu mencapai hook ini, pelacak tidak punya status yang cocok, dan paket itu membawa ACK. Itu dua fakta tentang dua hal berbeda, dan keduanya bukan transkrip jabat tangan yang lengkap. Berikut urutan yang saya lalui sebelum menarik kesimpulan.
Mulai dari paketnya, bukan putusannya
Pisahkan pengamatan sebelum menafsirkannya. Flag TCP menjelaskan paket ini, status pelacak menjelaskan apa yang diketahuinya di hook itu, dan tangkapan Anda hanya menjelaskan jendela yang Anda rekam.
Mencampur ketiganya adalah cara sebuah ACK berubah menjadi “penyedia membiarkan seseorang masuk”.
Apa arti NEW sebenarnya di hook
pencocokan conntrack iptables mendokumentasikan NEW sebagai paket yang memulai koneksi, atau paket yang terkait dengan koneksi yang belum melihat lalu lintas di kedua arah. ESTABLISHED berarti pelacak telah melihat paket di kedua arah. Tidak satu pun definisi itu mengatakan paket tersebut SYN, atau bahwa ia datang tanpa riwayat.
Pelacak yang mulai mengamati aliran di tengah mengklasifikasikan paket berikutnya menurut apa yang diketahuinya, dan itu bisa saja tidak ada. Itu pernyataan tentang memori pelacak, bukan tentang niat host jauh.
Pelacakan longgar menjelaskan sebagian besar kejutan ACK
Kernel mendokumentasikan nf_conntrack_tcp_loose, yang memungkinkan pelacak mengambil koneksi TCP yang tidak dilihat awalnya. Dengan pengaturan pada nilai bawaannya, ACK dari tengah aliran dapat diterima sebagai aliran yang sudah terbentuk. Matikan, dan paket yang sama lebih mungkin diklasifikasikan INVALID alih-alih NEW. Kedua hasil menjelaskan aturan pelacak, bukan riwayat aplikasi.
Jadi periksa pengaturan itu sebelum membangun teori di atas label.
Singkirkan penyebab membosankan dalam urutan ini
Sebagian besar peristiwa NEW-pada-ACK yang saya kejar berakhir pada salah satu dari ini, dan semuanya murah diperiksa:
- Tabel conntrack dikosongkan, atau pelacak dimulai ulang.
- Host di-reboot, atau aliran berpindah ke namespace atau perangkat lain.
- Perutean asimetris mengirim SYN keluar melalui jalur yang tidak Anda tangkap.
- NAT menulis ulang tuple, sehingga entri tidak lagi cocok dengan yang Anda baca.
- Tangkapan dimulai terlambat dan tidak pernah melihat awalnya.
Masing-masing menyingkirkan paket sebelumnya dari pandangan pelacak sambil membiarkan paket berikutnya utuh. Reboot atau pengosongan tabel paling mudah dikonfirmasi dari uptime dan log. Perutean asimetris tampak sebagai tangkapan satu arah. NAT adalah yang licik, karena tuple yang disimpan pelacak bukan tuple yang tercetak di log.
Catat mana yang Anda singkirkan, dan bagaimana, sebelum melanjutkan.
Baca tuple, antarmuka, dan hook
Entri conntrack dikunci oleh alamat, port, dan protokol, jadi setiap terjemahan mengubah entri mana yang cocok. Catat juga antarmuka dan hook, karena paket yang terlihat di antarmuka yang salah atau setelah rantai berbeda memberi tahu bahwa jalurnya bukan seperti di diagram. Saat peristiwa melibatkan VPN, tentukan apakah Anda melihat paket dalam atau pembawa luar. Lalu bandingkan dengan apa yang dicatat gateway untuk tuple lima bagian yang sama.
Dua pandangan atas satu aliran yang tidak sepakat lebih informatif daripada salah satunya sendiri.
Kapan layak dieskalasi
Eskalasi bila Anda dapat menunjukkan layanan yang dapat dijangkau dan seharusnya tidak, beserta aliran, kebijakan yang mengizinkannya, dan bukti dari kedua ujung. Jangan melaporkan cacat penyedia berdasarkan satu label status atau satu tangkapan sebagian, karena laporan itu akan ditutup dengan penjelasan yang baru saja Anda baca. Jika layanan itu memang terbuka, pemilik batas itulah orang yang tepat untuk memperbaikinya, dan pemetaan port yang didelegasikan atau pendengar tak sengaja lebih mungkin menjadi penyebab daripada bug.
Lalu tutup celah visibilitas yang membuat satu paket tampak seperti seluruh sesi.