DNS menyelesaikan alamat IP yang salah di satu negara

Salah satu teman saya memiliki situs web eLearning berbasis pada Claroline. Dua hari yang lalu, hanya pengguna Swiss yang mulai mengalihkan "secara acak" ke alamat IP lain saat mengakses domain situs web.

Jika saya memaksa server DNS ke 8.8.8.8 atau 9.9.9.9 di PC siswa, domain tersebut diselesaikan dengan benar. Tetapi jika saya tetap dengan Server DNS Swiss lokal, itu memutuskan untuk alamat IP yang buruk (daftar hitam).

Bagian yang aneh adalah: Bukan hanya pelanggan yang satu ini dan komputernya sendiri. Setiap siswa yang berbasis di Swiss juga terpengaruh. Tapi bukan yang Prancis.

Bagian aneh kedua adalah: Beberapa halaman merespons dari alamat IP palsu ini dengan konten yang benar. Seperti eLearning digandakan di server lain ATAU di-cache di suatu tempat.

Server adalah Ubuntu 10.04.4 LTS lama, dan mungkin tidak dilindungi / dikonfigurasikan dengan benar. Saya memiliki akses penuh pada server ini, tetapi saya tidak mengelolanya, jadi saya tidak yakin apa yang harus dicari atau bahkan apa yang harus dilakukan.

Inilah yang saya lihat / coba sejauh ini:

Memeriksa semua konfigurasi Apache 2 vhost.
Cek iptables (kosong) dan /etc/hostsdan /etc/resolv.conf(aman)
Tanya Swisscom (telekomunikasi utama Swiss) apakah mereka memasukkan daftar hitam domain atau semacamnya: Tidak Memeriksa basis kode klaroline: kelihatannya aman, tetapi sangat besar. Saya tidak dapat memeriksa semua file.

Berikut adalah nslookup di salah satu komputer Windows siswa:

C:\WINDOWS\system32>nslookup
Serveur par défaut :   UnKnown
Address:  fe80::8e59:c3ff:fecf:8d9b

> elearning.redacted-domain.ch
Serveur :   UnKnown
Address:  fe80::8e59:c3ff:fecf:8d9b

Réponse ne faisant pas autorité :
Nom :    elearning.redacted-domain.ch
Address:  195.186.210.161

Dan tentu saja, 195.186.210.161 bukan alamat IP server yang benar.

Saya bukan administrator sistem. Saya hanya membantu seorang teman, jadi saya tidak yakin apa yang harus dicari selanjutnya.

domain-name-system

— iizno
sumber

Mungkin ISP anak-anak itu berusaha melakukan caching yang cerdas dan mengganggu DNS. Apakah mereka semua di universitas yang sama misalnya? Jika Anda menggunakan HTTPS untuk server Anda, maka mereka masih dapat memodifikasi DNS, tetapi pengguna akhir akan melihat kesalahan sertifikat jika hasil DNS menunjuk ke server selain dari Anda karena mereka tidak akan memiliki kunci privat.

— David

Juga, apakah Anda yakin alamat IP server itu statis? Misalnya jika sering berubah atau baru-baru ini diubah dalam TTL dari catatan DNS maka ada kemungkinan bahwa DNS sedang diselesaikan ke yang lama (IP yang dulu valid) - meskipun itu tidak akan menjelaskan mengapa mereka melihat konten cermin. Jika Anda menggunakan alat seperti mxtoolbox.com/DNSLookup.aspx Anda mungkin dapat melihat TTL dari catatan A atau catatan CNAME yang dilampirkan ke domain.

— David

@ Davidvidate Itu bagian yang menyenangkan, siswa ada di rumah, di seluruh Perancis dan Swiss. Yang Prancis tidak punya masalah.

— iizno

@DavidGoate Server IP sudah diperbaiki dan tidak pernah berubah. dnschecker.org/#A/elearning.affis.ch tidak menunjukkan kesalahan.

— iizno

Hai, hal lain yang bisa terjadi, seperti yang saya lihat beberapa kesalahan seperti itu di masa lalu, itu bisa menjadi server DNS yang dikelola dengan buruk oleh ISP. Saya melihat zona DNS yang ditransfer tetapi tidak pernah terhapus di tingkat ISP, sehingga menyebabkan kesalahan aneh.

— yagmoth555

Jawaban:

Seperti yang ditulis MadHatter , ini adalah ISP pengguna akhir (Swisscom) yang merutekan ulang situs Anda melalui proxy penyaringan. Sangat mungkin bahwa semua pengguna yang berlangganan layanan Internet Guard mereka sebenarnya diproksi melalui sana, bukan hanya situs Anda.

Mereka mengatakan bahwa filter tersebut melawan malware, phishing dan virus, jadi seharusnya tidak menjadi masalah "klasifikasi", tetapi salah satu dari keamanan.

Dengan demikian, langkah pertama Anda adalah memeriksa bahwa situs tersebut belum terinfeksi. Situs PHP cenderung sangat rentan (jika seseorang menemukan cara untuk mengunggah file .php di suatu tempat dalam hierarki yang terlihat, maka itu dapat dijalankan dari jarak jauh untuk melakukan apa pun yang mereka inginkan). Ada juga banyak cara lain untuk melakukan kerusakan (injeksi SQL, XSS tersimpan ...).

Halaman beranda Anda tidak diblokir, atau setidaknya tidak sepanjang waktu, jadi:

hanya beberapa halaman yang terinfeksi
infeksi hanya muncul sebagian kecil dari waktu permintaan pengguna (strategi umum untuk terbang di bawah radar)
atau ada hal lain pada beberapa halaman yang memicu false positive

Anda dapat melihat hasilnya sendiri dengan mengarahkan alamat situs web ke alamat IP proxy. Anda dapat melakukannya dengan mengedit /etc/hostsfile Anda (detail bervariasi berdasarkan platform) dan menambahkan baris:

195.186.210.161        elearning.affis.ch

Anda kemudian dapat mengunjungi situs sebagai salah satu pengguna tersebut, dan melihat halaman mana yang diblokir atau tidak.

Setelah Anda memiliki perasaan yang lebih baik tentang halaman apa yang diblokir atau tidak, mungkin lebih mudah untuk menunjukkan masalah yang sebenarnya. Kemudian perbaiki, dan baik itu akan tiba-tiba melalui segera, atau Anda mungkin harus melaporkan positif palsu (ada tautan untuk itu di bagian bawah halaman "diblokir").

Perhatikan bahwa mencoba melaporkan positif palsu sebelum memeriksa infeksi mungkin akan menjadi kontraproduktif. Berusaha sangat keras untuk menemukan dan memperbaiki masalah terlebih dahulu.

Edit

Perhatikan bahwa versi Claroline yang Anda jalankan (1.11.9) memiliki beberapa kerentanan XSS yang dikenal sejak 2014:

Beberapa kerentanan skrip lintas situs (XSS) di Claroline 1.11.9 dan sebelumnya memungkinkan pengguna terautentikasi untuk menyuntikkan skrip web atau HTML sewenang-wenang melalui (1) bidang Pencarian dalam tindakan kotak masuk ke perpesanan / messagebox.php, (2) the " Nama depan "bidang ke auth / profile.php, atau (3) bidang Pembicara dalam tindakan rqTambahkan ke kalender / agenda.php

Jika masalahnya memang serangan XSS yang disimpan, ambil dump terbaru dari database Anda dan periksa apakah itu berisi sesuatu seperti <scripttag (jangan lupa untuk mencari case-insensitive).

— jcaron
sumber

Jika Anda mengarahkan browser ke alamat IP yang dikembalikan, http://195.186.210.161/ , Anda mendapatkan pesan "situs web berbahaya yang diblokir" Swisscom. Dugaan saya adalah bahwa sistem pemblokiran konten "internet aman" mereka berfungsi, paling tidak sebagian, dengan berbohong sebagai tanggapan terhadap permintaan DNS, dan bahwa situs web Anda salah, karena beberapa alasan.

Saya mengerti bahwa Anda bertanya kepada mereka apakah mereka menghalangi Anda, tetapi menurut pengalaman saya, bahkan dukungan teknis garis depan ISP menengah tidak tahu apa pun yang terjadi di belakang. Sangat mungkin bahwa seluruh sistem pengasuh outsourcing (atau dilakukan oleh produk komersial pihak ketiga) dan tidak ada seorang pun di Swisscom yang tahu situs mana yang diblokir pada waktu tertentu. Menanyakan kepada siswa Anda apakah ia memiliki pengaturan "pengasuh internet" apa pun mungkin lebih produktif.

Pada akhirnya, ini mungkin bukan masalah yang bisa Anda selesaikan, karena Anda bukan pelanggan ISP, dan mereka tidak berhutang apa-apa kepada Anda. Memiliki orang tua siswa memanggil dukungan ISP mereka, mengeluh keras tentang resolusi DNS yang salah, dan mengancam untuk mengubah ISP jika itu tidak diselesaikan, kemungkinan akan menjadi satu-satunya hal yang memiliki efek.

Sunting : utas ini menunjukkan bahwa mesin pemblokiran situs Swisscom bisa sedikit terlalu antusias, dan bahwa tidak selalu mudah untuk mendapatkan segala jenis resolusi positif dari mereka. Ini juga menunjukkan bahwa ini bukan filter keikutsertaan, tetapi itu berlaku untuk semua pelanggan Swisscom apakah mereka suka atau tidak, jadi menyisih dari itu mungkin terbukti sulit.

— MadHatter
sumber

Itu sebabnya saya pikir juga tetapi, mengapa beberapa halaman menampilkan konten yang benar dan lainnya hanya kehabisan waktu. ? Sepertinya mereka menggandakan beberapa halaman.

— iizno

Kami tidak tahu apa yang mereka gunakan, jadi kami tidak tahu cara kerjanya. Mungkin keputusan lini pertama diambil pada waktu resolusi DNS, tetapi sistem di 195.186.201.161 mengimplementasikan keputusan lini kedua berdasarkan pada URL apa yang diminta, mem-proxy-kan ke server sebenarnya jika dan hanya jika memutuskan kontennya "aman ". Begitu orang mulai mencoba untuk membengkokkan protokol internet dalam mengejar beberapa (tidak terjangkau) visi internet "aman", hampir semua hal bisa salah.

— MadHatter

Sepertinya masalah yang bisa diselesaikan dengan pengacara di yurisdiksi yang tepat ...

— R .. GitHub BERHENTI MEMBANTU ICE

Jika itu benar-benar sedang diproksikan dan dipindai, memaksa HTTPS bisa membantu (atau melukai). ISP paling tidak hanya akan memiliki pilihan untuk memblokir seluruh situs atau tidak sama sekali daripada memblokir beberapa halaman dan bukan yang lain. Ini dapat membuat hal-hal yang kurang membingungkan bagi pengguna.

— Joshua Dwire

Sangat mungkin bahwa seluruh sistem pengasuh outsourcing (atau dilakukan oleh produk komersial pihak ketiga) dan tidak ada seorang pun di Swisscom yang tahu situs mana yang diblokir pada waktu tertentu. Saya bekerja dengan perusahaan telekomunikasi besar yang melakukan hal ini, jadi dapat mengonfirmasi. Dukungan teknis ISP mungkin sama sekali tidak tahu, tetapi mereka harus dapat membuka tiket kepada siapa pun yang benar-benar menjalankan sistem klasifikasi jika ada masalah.

— Bakuriu