Tajemniczy źle skierowany ruch chiński: Jak mogę dowiedzieć się, jakiego serwera DNS użyło żądanie HTTP?


24

Przez ostatni tydzień otrzymywałem ogromny strumień ruchu z szerokiej gamy chińskich adresów IP. Ten ruch wydaje się pochodzić od normalnych ludzi, a ich żądania HTTP wskazują, że myślą, że jestem:

  • Facebook
  • The Pirate Bay
  • różne trackery BitTorrent,
  • strony porno

Wszystko to brzmi jak rzeczy, do których ludzie używaliby VPN. Lub rzeczy, które rozzłościłyby Wielki Mur Chiński.

Programy klienckie obejmują przeglądarki internetowe, Android, iOS, FBiOSSDK, Bittorrent. Adresy IP są normalnymi komercyjnymi chińskimi dostawcami.

Mam Nginx zwracający 444, jeśli host jest niepoprawny lub agent użytkownika jest oczywiście niepoprawny:

## Deny illegal Host headers
if ($host !~* ^({{ www_domain }})$ ) {
   return 444;
}
## block bad agents
if ($http_user_agent ~* FBiOSSDK|ExchangeWebServices|Bittorrent) {
    return 444;
}

Mogę teraz poradzić sobie z obciążeniem, ale zdarzały się impulsy do 2k / minutę. Chcę dowiedzieć się, dlaczego do mnie przychodzą i przestać. Mamy również legalny ruch CN, więc zakazanie 1/6 planety Ziemi nie wchodzi w grę.

Możliwe, że jest złośliwy, a nawet osobisty, ale może to być źle skonfigurowany DNS.

Moja teoria jest taka, że ​​to źle skonfigurowany serwer DNS lub niektóre usługi VPN, których ludzie używają, aby ominąć Wielki Fire Wall.

Podany adres IP klienta:

183.36.131.137 - - [05/Jan/2015:04:44:12 -0500] "GET /announce?info_hash=%3E%F3%0B%907%7F%9D%E1%C1%CB%BAiF%D8C%DE%27vG%A9&peer_id=%2DSD0100%2D%96%8B%C0%3B%86n%8El%C5L%11%13&ip=183.36.131.137&port=11794&uploaded=4689970239&downloaded=4689970239&left=0&numwant=200&key=9085&compact=1 HTTP/1.0" 444 0 "-" "Bittorrent"

Ja mogę wiedzieć:

descr:          CHINANET Guangdong province network
descr:          Data Communication Division
descr:          China Telecom
  • Jak mogę dowiedzieć się, jakiego serwera DNS używają ci klienci?
  • Czy w ogóle można ustalić, czy żądanie HTTP pochodzi z VPN?
  • Co się tu naprawdę dzieje?

5
Widziałem już ten problem, zarówno jako cel ruchu, jak i ruch przeznaczony dla mojego serwera wysyłany gdzie indziej. Nie mam jednak żadnych odpowiedzi. Zmniejszyłem wpływ pierwszego problemu z zaporą ogniową, a drugiego z rozwiązaniem programowym, które było możliwe tylko w naszej konkretnej sytuacji (nasze oprogramowanie wysyła żądania). Podczas inicjowania okazało się, że niektóre serwery DNS odmawiają przestrzegania bardzo niskich wartości TTL, zamiast tego buforują wynik przez miesiące, co może wyjaśniać listę witryn, dla których odwiedzany jest ruch.
Xofer,

1
Sprawdź także to pytanie. Miałem ten sam problem serverfault.com/questions/656093/ ... Jestem tylko ciekawy, dlaczego dostawca usług internetowych zrobiłby coś takiego. Nie widzę wartości w.
Cha0s,

4
Z mojego doświadczenia wynika, że ​​są to próby znalezienia otwartych proxy internetowych. Niektóre serwery internetowe pozwalają na żądanie dowolnego adresu URL; Kiedyś zadzwoniono do mnie, aby poradzić sobie z jednym z nich, który przekroczył swój (hojny) miesięczny przydział przepustowości, zanim jeszcze był w użyciu. Grupa studentów z Nanjing Institute of Technology odkryła, że ​​mogą nawiązywać z nim połączenia HTTPS i prosić o dowolną stronę internetową, a tym samym z niecierpliwością wymykali się całym swoim porno za Wielką Zaporą. Jeśli faktycznie nie udostępniasz żądanych treści, wszystko powinno być w porządku.
MadHatter obsługuje Monikę

1
Zazwyczaj tak. Cytowano tylko jeden wpis w dzienniku, więc pomyślałem, że warto o tym wspomnieć; nie jest to zamierzona pełna, przemyślana odpowiedź, w przeciwnym razie podałbym ją jako jedną!
MadHatter obsługuje Monikę

1
1. Czy próbowałeś kiedyś znaleźć sysadminów dla zarejestrowanej domeny tutaj w USA? Jeśli tak, to wiesz, jakie to może być trudne. Wyobrażam sobie, że to do cholery niemożliwe, aby nie tylko znaleźć odpowiednią osobę do rozmowy w „Chinanet”, ale także właściwą osobę, która naprawdę troszczy się o to, by ci pomóc.
Michael Martinez,

Odpowiedzi:


31

Istnieje jeden teoretyczny sposób określania resolwera DNS twoich klientów, ale jest on dość zaawansowany i nie znam żadnego gotowego oprogramowania, które zrobiłoby to za ciebie. Na pewno będziesz musiał uruchomić w tym celu autorytatywny serwer DNS oprócz swojego nginx.

W przypadku, gdy nagłówek hosta HTTP jest niepoprawny, podaj dokument błędu i dołącz żądanie do dynamicznie utworzonej, unikalnej nazwy FQDN dla każdego żądania, które logujesz do bazy danych. na przykład.

http://e2665feebe35bc97aff1b329c87b87e7.example.com/img.png

Tak długo, jak świetna zapora ogniowa Chinas nie będzie majstrować przy tym żądaniu, a klient zażąda dokumentu z tego unikalnego identyfikatora FQDN + URI, każde żądanie spowoduje nowe wyszukiwanie DNS w autorytatywnym systemie DNS na przykład.com, gdzie można zalogować adres IP Program rozpoznawania nazw DNS, a później koreluje to z dynamicznie generowanymi identyfikatorami URI.


6
Sugerowałbym to samo podejście, choć uważam, że do jego działania potrzebny byłby inny poziom domen. Jeśli domeną podstawową jest example.com, utworzyłbyś rekord NS dla jednej subdomeny, takiej jak ns-detect.example.com. Następnie utworzyłbyś unikalną nazwę pod tą nazwą domeny, taką pełną domeną e2665feebe35bc97aff1b329c87b87e7.ns-detect.example.com.
kasperd

1
To ciekawe podejście. Podejrzewam teraz, że przekierowanie jest celowe (ponieważ nie tylko ja to widzę). Zakładam więc, że różne chińskie serwery DNS nie zadałyby sobie trudu, by sprawdzić autorytatywny serwer w celu uzyskania subdomeny. Nie miałoby to dla nich sensu.
Felix

Jeśli używają białej listy, prawdopodobnie masz rację. Jeśli są na czarnej liście, to właściwie nie ma powodu, by nie szukać niewinnie wyglądającej nazwy FQDN. Oczywiście może to wynikać również z bardziej zaawansowanych technik filtrowania niż po prostu zabawy z odpowiedziami DNS.
r_3

1
+1 za pomysł Kasperda na utworzenie subdomeny z własnym NS, aby przechowywać logi dla tego osobno od normalnego DNS. I zrobić to z mniejszą szansą na zepsucie twoich normalnych rzeczy. Jeśli widzisz żądania HTTP dotyczące nazw hostów, które nie zostały wyszukane w twoim systemie DNS przez nikogo, oznacza to, że serwer DNS, którego używają Twoi źli klienci, fałszuje odpowiedzi DNS (i robi to źle, ponieważ prawdopodobnie chcieli wysłać ten ruch w inne miejsce Może może chiński administrator gdzieś wpisał adres IP w konfiguracji?).
Peter Cordes,

Przyjmowanie, ponieważ najbardziej dokładnie odpowiada pierwsze pytanie. Naprawdę nie rozwiązuje problemu, dlaczego otrzymujemy ruch, ale wymiana stosów nie pozwala na niejasne pytania.
felix

5

Słyszałem, że świetna zapora sieciowa przekierowywała „zablokowany” ruch do garstki fałszywych adresów IP, ale powodowało to, że ich bloki były łatwe do wykrycia (nie jestem pewien, czy pozwoliło to na łatwą subwersję). W każdym razie administratorzy zaczęli przekierowywać na losowe adresy IP. Doprowadziło to do tego, że niektórzy chińscy użytkownicy otrzymywali pornografię zamiast Facebooka lub VPN.

Podejrzewam, że jeden z twoich adresów IP okazał się być odbiorcą zablokowanego chińskiego ruchu - stąd widzisz agentów użytkowników Facebook IPI.

Oznacza to, że sprawdzenie nagłówka hosta powinno być dobre. Większość programów klienckich obsługuje obecnie SNI, więc powinieneś być w stanie ograniczyć ruch bez nagłówka hosta ze względną bezkarnością.

Edycja: http://www.infosecurity-magazine.com/news/great-firewall-upgrade-redirects/


4

Jak mogę dowiedzieć się, jakiego serwera DNS używają ci klienci?

Skontaktuj się z Chinanet i zapytaj? Poważnie, DNS można konfigurować po stronie klienta. Większość ludzi otrzymuje ustawienia DNS przez DHCP, ale OpenDNS i oferta DNS Google'a nie miałyby modelu biznesowego, gdybyś nie mógł ich zmienić.

Czy w ogóle można ustalić, czy żądanie HTTP pochodzi z VPN?

Nie bardzo, z wyjątkiem tego, że adres IP będzie VPN, a nie użytkownikiem końcowym w Chinach.

Co się tu naprawdę dzieje?

Tego nie mogę powiedzieć, ale być może w Wielkiej Zaporze Chińskiej jest jakaś błędna konfiguracja ?

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.