DNS вирішує неправильну IP-адресу в одній країні

Один мій друг має веб-сайт eLearning, заснований на Claroline. Два дні тому лише користувачі Швейцарії почали отримувати переадресацію "випадковим чином" на іншу IP-адресу під час доступу до домену веб-сайту.

Якщо я змушую DNS-сервер до 8.8.8.8 або 9.9.9.9 на ПК студентів, домен вирішено правильно. Але якщо я залишаюсь на локальному швейцарському DNS-сервері, він вирішить погану (в чорний список) IP-адресу.

Дивна частина: це не лише цей один клієнт і власний комп'ютер. Кожен студент, що мешкає у Швейцарії, також зазнає впливу. Але не французькі.

Друга дивна частина: Деяка сторінка відповідає на цю помилкову IP-адресу з правильним вмістом. Можливо, eLearning дублювався на іншому сервері АБО кудись кешовано.

Сервер - це стара Ubuntu 10.04.4 LTS, і він, ймовірно, неправильно захищений / налаштований. У мене є повний доступ на цьому сервері, але я не керував ним, тому не знаю, що шукати або навіть що робити.

Ось що я подивився / спробував поки що:

• Перевірив усі конф. Конф. Ahoche 2
• Перевірені iptables (порожні) та /etc/hostsта /etc/resolv.conf(безпечні)
• Запитав Swisscom (головний швейцарський телеком), чи вони внесли в чорний список домен чи щось таке: Nope перевірив базу коду клароліну: це виглядає безпечно, але це величезна кількість. Я не можу перевірити всі файли.

Ось nslookup на одному з учнівських комп'ютерів Windows:

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

І звичайно, 195.186.210.161 - не правильна IP-адреса сервера.

Я не системний адміністратор. Я просто допомагаю другу, тож я не впевнений, що шукати далі.

Як писав MadHatter , це провайдер кінцевих користувачів (Swisscom), який перенаправляє ваш сайт через проксі-сервер для фільтрування. Цілком ймовірно, що всі користувачі, які підписалися на їх послугу Internet Guard, насправді проксі проходять там, а не лише на вашому сайті.

Вони кажуть, що фільтр проти зловмисного програмного забезпечення, фішингу та вірусів, тому це не повинно бути проблемою "класифікації", а безпекою.

Таким чином, вашим першим кроком має стати перевірка того, що сайт не був заражений. Сайти PHP, як правило, досить вразливі (якщо хтось знаходить спосіб завантажити .php файл десь у видимій ієрархії, він може бути виконаний віддалено, щоб робити все, що завгодно). Існує також багато інших способів заподіяти шкоду (ін'єкції SQL, збережений XSS ...).

Ваша домашня сторінка не заблокована або, принаймні, не весь час, так що:

• заражені лише деякі сторінки
• інфекція виявляється лише частину часу на запити користувачів (загальна стратегія літати під радари)
• або на деяких сторінках є щось інше, що викликає помилковий позитив

Ви можете побачити результат самостійно, вказавши адресу веб-сайту на IP-адресу проксі. Це можна зробити, відредагувавши свій /etc/hostsфайл (деталі залежать від платформи) та додавши рядок:

195.186.210.161        elearning.affis.ch

Потім ви можете відвідати сайт як один із цих користувачів і побачити, які сторінки заблоковані чи ні.

Як тільки ви відчуєте, які сторінки заблоковані чи ні, може бути простіше точно визначити фактичну проблему. Потім виправте це, або він раптом пройде відразу, або, можливо, вам доведеться повідомити про помилковий позитив (у нижній частині "заблокованої" сторінки є посилання на це).

Зауважте, що спроба повідомити про помилковий позитив перед перевіркою на зараження, ймовірно, буде контрпродуктивною. Спробуйте спочатку дуже важко знайти та виправити проблему.

Редагувати

Зауважте, що у запущеної вами версії Claroline (1.11.9) є кілька вразливих місць XSS :

Багаторазові вразливості міжсайтових сценаріїв (XSS) у Claroline 1.11.9 і новіших версіях дозволяють віддаленим користувачам з автентифікацією вводити довільну веб-скрипт або HTML за допомогою (1) поля пошуку в дії вхідних повідомлень для обміну повідомленнями / messagebox.php, (2) " Ім'я "поле для auth / profile.php або (3) поле Speakers у дії rqAdd до календаря / agenda.php

Якщо проблема справді є збереженою атакою XSS, візьміть останній дамп вашої бази даних і перевірте, чи містить вона щось на зразок <scriptтегу (не забудьте шукати регістр без чутливості).

Якщо ви вкажете браузер на повернуту IP-адресу, http://195.186.210.161/ , ви отримаєте повідомлення "небезпечний веб-сайт заблокований" Swisscom. Я здогадуюсь, що їхня система блокування контенту "безпечного Інтернету" працює, принаймні частково, лежачи у відповідь на запити DNS, і що ваш веб-сайт чомусь оскаржує їх.

Я розумію, що ви запитували їх, чи блокують вони вас, але, на мій досвід, навіть середня технологічна підтримка провайдерів не має найменшого уявлення про те, що відбувається назад. Цілком можливо, що вся система нянь перебуває в аутсорсингу (або робиться стороннім комерційним продуктом) і ніхто з Swisscom не має уявлення, які сайти заблоковані в будь-який момент. Запитати вашого учня, чи (-ла) у нього є якісь налаштування «няні в Інтернеті», може бути більш продуктивним.

Зрештою, це може бути не проблемою, яку ви можете вирішити, оскільки ви не клієнт Інтернет-провайдера, і вони вам нічого не зобов'язані. Батьки учня зателефонують у службу підтримки Інтернет-провайдера, голосно скаржаться на неправильну роздільну здатність DNS та погрожують змінити Інтернет-провайдера, якщо це не вирішено, ймовірно, це буде єдине, що має будь-який ефект.

Редагувати : цей потік говорить про те, що механізм блокування сайтів Swisscom може бути трохи захоплений, і отримати не тільки позитивне рішення від них не завжди просто. Він також дозволяє припустити, що це не фільтр для відключення, але він застосовується до всіх клієнтів Swisscom, їм це подобається чи ні, тому відмовитися від нього може виявитися важким.