Изпечатай

[gat3way]

Очарован от писмото на Невен Дилков (собственикът на Нетера) до Капитал:

http://www.capital.bg/politika_i_ikonomika/bulgaria/2013/06/24/2089115_edin_cheren_den_za_bulgarskiia_internet/

Реших да си направя статистика за това по какъв начин родните провайдъри филтрират достъпа до въпросните сайтове: DNS filtering, IP filtering или пък знам ли там: някакво deep packet inspection-базирано филтриране.

За Мегалан мога да кажа, че режат достъпа до въпросните сайтове на база null-route-ване на IP трафик. Филтрирането става при един техен рутер, от който нататък всякакъв TCP и UDP трафик се терминира с "destination network unreachable".  Странно обаче, ICMP трафика минава и виждам ICMP echo reply от въпросните забранени сървъри.


Та идеята ми е да направим една статистическа справка за това кой доставчик как имплементира забраната. Това е доста просто, хващаме един от забранените сайтове (примерно http://www.bet365.com ) и правим няколко прости теста, с ползване на наличен подръчен софтуер

1)

Код:

dig www.bet365.com А

Ако отговорът съдържа нещо от сорта на:

Код:

;; ANSWER SECTION:
www.bet365.com.         10503   IN      A       5.226.176.11

Следователно DNS трафик не се филтрира (само трябва да сте сигурни че не ползвате някой чужбински DNS сървър, примерно този на google).


2) Опит за установяване на TCP връзка до хоста, примерно:

Код:

telnet www.bet365.com

Което или веднага ще приключи с connection refused (връщаме RST значи дропим с REJECT, не DROP, хм) или ще се влачи и ще каже че не може да установи връзка след известно време, в който случай, трафикът дотам просто се дроп-ва

Алтернативният вариант е това да гръмне с "network unreachable", което е доста сигурен знак че трафика се null-route-ва.


3)

Код:

traceroute www.bet365.com

Ако това завърши до някой междинен хоп, има няколко варианта, има едни "специални" символи, които отразяват резултата:

!N - някой е хванал и е null-route-нал трафика до хоста (демек следващият му хоп е примерно 127.0.0.1)

!X - малко по-рицарски начин за филтриране на трафик, рутерът ни връща ICMP communication administratively prohibited.

Или просто * * * което значи че трафикът просто си се дропва.


И сега остава последният вариант: traceroute минава, dig минава, дори се закачате с telnet на порт 80. Пишете нещо от сорта на:

Код:

GET /  HTTP/1.1
Host: www.bet365.com

И връзката се разпада без никакъв отговор. Това е най-интересният случай и означава че най-вероятно хората ползват нещо по-умно за филтриране на трафика, твърде вероятно въпросните неща с deep packet inspection наклонности. Това ще е много забавен момент. Алтернативно разбира се може да получите някакъв отговор от прокси сървър, който ви уведомява че заявката не може да бъде осъществена - в този случай ще разберете че доставчикът ви минава трафика ви през transparent proxy, което е много подло и противно според мен.


Та дайте да видим как се филтрират сайтовете в България. Кой знае, утре може да решат не само хазартни сайтове да режат, та ми е интересно кой как го прави

[kifavi8024]

Пълна простотия...
Те bet365 вече си пуснаха нов домейн allsport365.com, така че им дреме. Тези които искат наистина да останат на пазара, или ще се регистрират, или ще си пускат нови домейни/повече ip-та. Да не говорим че това отваря врати за една нова пазарна ниша на пазара за VPN услуги.

Но понеже въпроса беше, как го правят: При мен на Mtel PON (предишните SPNet PON) пак се филтрира по IP с посочения от теб метод (null-route). Пинг си има, но до там

По-интересното е че има сайтове от списъка, които са си пуснали няколко IP-та и продължават да си се достъпват

Но аз искам да поговорим и малко за самата ситуация - най-важното в държвата беше да се спрат "незаконните" залози! Всичко друго вече е ок и останаха само сайтовете за залагане!

Според мен обаче правилният начин е следния: Държавата прави официално писно до всички сайтове и ги предупреждава със срок от един месец, че ще сезира комисията на страната, която ги регулира, за да ги спре ако не се лицензират в България или ако самите сайтове не забранят залаганията от България.

Това е много по-нормален/цивилизован начин за решаване на проблема. Така поставят проблема към първоизточника (собствениците на сайтовете), а не върху косвено замесените в този проблем - доставчиците на интернет услуги. По този начин няма да има филтриране на никакви сайтове директно от доставчиците.

Но както винаги - по-лесно е тука да си напишем и гласуваме едно лобистко законче за парите, които сме получили от монополиста. Това е България - каквито са хората, такава е и държавата като цяло. Тъжно, но факт. Няма да се учудя грам ако почнат да филтрират и още нещо - колко му е? Въпрос на гласуване на няколко промени от парламента и създаване на още една агенция

PS: Това с хората и държавата е по повод на това, че ние българите много обичаме да си "забраняваме" разни неща помежду си. Все пак това е да притежаваш "силата" на "власта"...

[go_fire]

Аз съм на БТК от август 2006-та, преди това комутируема връзка (dial up).  Днес ми е последният ден с тях преди развода,  надявам се, Въпросният bet365 при мен се отваря нормално. Но пък и аз от доста време ползвам Open DNS по причини описвани във форума, като това, че не можех  да отварям архива на Интернет.

[Odido]

Код

GeSHi (Bash):
root@debian:/home/box# ping www.bet365.com 
PING www.bet365.com (5.226.176.11) 56(84) bytes of data.
From de-cix.spnet.net (80.81.192.229) icmp_seq=1 Destination Net Unreachable
From de-cix.spnet.net (80.81.192.229) icmp_seq=2 Destination Net Unreachable
From de-cix.spnet.net (80.81.192.229) icmp_seq=3 Destination Net Unreachable
From de-cix.spnet.net (80.81.192.229) icmp_seq=4 Destination Net Unreachable
From de-cix.spnet.net (80.81.192.229) icmp_seq=5 Destination Net Unreachable
From de-cix.spnet.net (80.81.192.229) icmp_seq=6 Destination Net Unreachable
From de-cix.spnet.net (80.81.192.229) icmp_seq=7 Destination Net Unreachable
^C
--- www.bet365.com ping statistics ---
7 packets transmitted, 0 received, +7 errors, 100% packet loss, time 10146ms
 

никакъв го няма...

[gat3way]

Гледай ти, и при мен вече резултатът е същия (а хоста, който филтрира е абсолютно същият апропо).

Мтел слухтят какво пишем в този форум бе пфу. Вчера мрънкам че ICMP трафика все пак минава, днес вече и той не минава

Да си признае бързо кой е вражеския агент!!!

[kifavi8024]

Не знам дали някой чете темата, но определено правят някакви тестове. В момента част от заявките просто не се връщат:

vm1e2@rt1e2:~$ ping http://www.bet365.com
PING http://www.bet365.com (5.226.176.11) 56(84) bytes of data.
From de-cix.spnet.net (80.81.192.229) icmp_seq=5 Destination Net Unreachable
From de-cix.spnet.net (80.81.192.229) icmp_seq=6 Destination Net Unreachable
From de-cix.spnet.net (80.81.192.229) icmp_seq=7 Destination Net Unreachable
From de-cix.spnet.net (80.81.192.229) icmp_seq=8 Destination Net Unreachable
From de-cix.spnet.net (80.81.192.229) icmp_seq=15 Destination Net Unreachable
From de-cix.spnet.net (80.81.192.229) icmp_seq=16 Destination Net Unreachable
From de-cix.spnet.net (80.81.192.229) icmp_seq=17 Destination Net Unreachable
From de-cix.spnet.net (80.81.192.229) icmp_seq=18 Destination Net Unreachable
From de-cix.spnet.net (80.81.192.229) icmp_seq=25 Destination Net Unreachable
From de-cix.spnet.net (80.81.192.229) icmp_seq=26 Destination Net Unreachable
From de-cix.spnet.net (80.81.192.229) icmp_seq=27 Destination Net Unreachable
From de-cix.spnet.net (80.81.192.229) icmp_seq=28 Destination Net Unreachable
From de-cix.spnet.net (80.81.192.229) icmp_seq=29 Destination Net Unreachable
From de-cix.spnet.net (80.81.192.229) icmp_seq=35 Destination Net Unreachable
From de-cix.spnet.net (80.81.192.229) icmp_seq=36 Destination Net Unreachable
From de-cix.spnet.net (80.81.192.229) icmp_seq=37 Destination Net Unreachable
From de-cix.spnet.net (80.81.192.229) icmp_seq=45 Destination Net Unreachable
From de-cix.spnet.net (80.81.192.229) icmp_seq=46 Destination Net Unreachable
From de-cix.spnet.net (80.81.192.229) icmp_seq=47 Destination Net Unreachable
From de-cix.spnet.net (80.81.192.229) icmp_seq=48 Destination Net Unreachable
From de-cix.spnet.net (80.81.192.229) icmp_seq=55 Destination Net Unreachable
From de-cix.spnet.net (80.81.192.229) icmp_seq=56 Destination Net Unreachable
From de-cix.spnet.net (80.81.192.229) icmp_seq=57 Destination Net Unreachable
From de-cix.spnet.net (80.81.192.229) icmp_seq=58 Destination Net Unreachable
From de-cix.spnet.net (80.81.192.229) icmp_seq=59 Destination Net Unreachable
^C
--- http://www.bet365.com ping statistics ---
61 packets transmitted, 0 received, +25 errors, 100% packet loss, time 60137ms

Докато го кажа и пак промениха положението Сега има ping...

Май нещо си правят тестове как точно да блокират сайтовете, я погледнете какво цъфна на домейна  allsport365.com ...

Дам. Почнаха да подменят заявките под някаква форма:
Това което връща като отговор заявка от тип:

GET /  HTTP/1.1
Host: http://www.allsport365.com

Отговор:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
    <head>
      <meta http-equiv="Content-Type" content="text/html;charset=Utf-8" >
      <meta http-equiv="pragma" content="no-cache" >
      <meta http-equiv="Cache-control" content="no-cache" >
    </head>
<body>

</br>
<font face ="verdana">Търсената от Вас страница е с неразрешено съдържание и достъпът Ви до нея е ограничен.
За повече информация проверете на:
<a href="http://www.dkh.minfin.bg/"> http://www.dkh.minfin.bg </a> </font><br />

</body>
</html>

През прокси/vpn изобщо не е така...

[gat3way]

О, това е интересно, нямам търпение да се прибера вкъщи и да си поиграя.

[go_fire]

Такива надписи съм  виждал само на компютри в компании, когато се опитват да отворят страници на алкохол (странно, че пивото го броят за такъв), пощи  и публични проксита.

Иначе при мен и този се отваря правилно.

[dev_urandom]

lubo@neon:~$ ping bet365.com
PING bet365.com (5.226.178.10) 56(84) bytes of data.
64 bytes from 5.226.178.10: icmp_req=1 ttl=245 time=53.2 ms
64 bytes from 5.226.178.10: icmp_req=2 ttl=245 time=53.7 ms
64 bytes from 5.226.178.10: icmp_req=3 ttl=245 time=53.5 ms
64 bytes from 5.226.178.10: icmp_req=4 ttl=245 time=48.1 ms
64 bytes from 5.226.178.10: icmp_req=5 ttl=245 time=55.5 ms
64 bytes from 5.226.178.10: icmp_req=6 ttl=245 time=50.7 ms


Обаче ако се опитам да заредя страницата ме посреща
http://www.dkh.minfin.bg/bg/pubs/2/548

Доставчика е Онлайн Директ

[gat3way]

5.226.178.10 май е истинския адрес на хоста, поне гугълските DNS-и така твърдят. Предполагам обаче че при теб просто DNAT-ват TCP трафика нанякъде. Ако имаш tcptraceroute може да го провериш. А може и да правят както тук.

Мегалан/спектрум/мтел вече не null-route-ват, а са вдигнали хост със същият IP адрес и засилват трафика натам. Това е доста грубо според мен.

[neter]

5.226.178.10 май е истинския адрес на хоста, поне гугълските DNS-и така твърдят.

Не. Просто bet365.com и http://www.bet365.com (http-то отпред е от парсера на форума) имат различни адреси (това казват и DNS сървърите от authority-то за домейна), като това без www насочва към това с www. Онлайн Директ насочват А записа на www към 93.152.160.53 (което, изглежда, е машина с Windows, ако съдим по TTL-а, макар че nmap казва Unix), където заявката приключва. Няма никакво филтриране за 5.226.178.10. За 5.226.176.11 има филтриране, което отвежда към 80.81.192.229, което вече беше споменато и за други доставчици

PING 5.226.176.11 (5.226.176.11) 56(84) bytes of data.
From 80.81.192.229 icmp_seq=1 Destination Net Unreachable
From 80.81.192.229 icmp_seq=2 Destination Net Unreachable

[dev_urandom]

root@neon:~# telnet bet365.com 21

Trying 5.226.178.10...
telnet: connect to address 5.226.178.10: Connection refused
root@neon:~#
root@neon:~# telnet bet365.com 22
Trying 5.226.178.10...
telnet: connect to address 5.226.178.10: Connection refused
root@neon:~# wget bet365.com
--2013-06-25 20:33:10--  http://bet365.com/
Resolving bet365.com (bet365.com)... 5.226.178.10
Connecting to bet365.com (bet365.com)|5.226.178.10|:80... connected.
HTTP request sent, awaiting response... 302 Redirect
Location: http://www.bet365.com [following]
--2013-06-25 20:33:10--  http://www.bet365.com/
Resolving http://www.bet365.com (http://www.bet365.com)... 93.152.160.53
Connecting to http://www.bet365.com (http://www.bet365.com)|93.152.160.53|:80... connected.
HTTP request sent, awaiting response... 302 Moved Temporarily
Location: http://www.dkh.minfin.bg/bg/pubs/2/548 [following]
--2013-06-25 20:33:10--  http://www.dkh.minfin.bg/bg/pubs/2/548
Resolving http://www.dkh.minfin.bg (http://www.dkh.minfin.bg)... 212.122.164.2
Connecting to http://www.dkh.minfin.bg (http://www.dkh.minfin.bg)|212.122.164.2|:80... connected.
HTTP request sent, awaiting response... 200 OK

[gat3way]

Хм, гугълския резолвър ( 8.8.8.8 ) твърди че .11 е http://www.bet365.com, а .10 e bet365.com.

Тук обаче вече няма destination host unreachable - вдигнали са машинка с IP адрес 5.226.176.11 на която са подкарали nginx, който ми сервира следното:

Търсената от Вас страница е с неразрешено съдържание и достъпът Ви до нея е ограничен. За повече информация проверете на: http://www.dkh.minfin.bg

[dev_urandom]

Selected device eth0, address xxxxxxxxxxx, port 36708 for outgoing packets
Tracing the path to bet365.com (5.226.178.10) on TCP port 80 (http), 30 hops max
 1  xxxxx.onlinedirect.bg (xxxxxxxxxxxx)  1.674 ms  3.344 ms  0.924 ms
 2  93.152.160.118  1.439 ms  1.218 ms  1.652 ms
 3  92.247.17.173  1.202 ms  0.949 ms  1.030 ms
 4  spectrum-0.r02.frnkge04.de.bb.gin.ntt.net (213.198.82.134)  36.460 ms  35.186 ms  33.779 ms
 5  xe-0-3-0-3-610.r02.frnkge04.de.bb.gin.ntt.net (213.198.82.133)  34.193 ms  34.644 ms  34.176 ms
 6  ae-4.r21.frnkge03.de.bb.gin.ntt.net (129.250.4.53)  32.171 ms  32.326 ms  31.884 ms
 7  ae-3.r22.londen03.uk.bb.gin.ntt.net (129.250.3.137)  46.993 ms  46.909 ms  46.487 ms
 8  ae-1.r02.londen03.uk.bb.gin.ntt.net (129.250.5.25)  45.653 ms  45.588 ms  45.948 ms
 9  bet365.r02.londen02.uk.ce.gin.ntt.net (83.217.238.14)  45.149 ms  45.240 ms  45.085 ms
10  178.237.173.198  42.599 ms  42.755 ms  42.562 ms
11  5.226.178.10 [open]  43.933 ms  44.401 ms  44.160 ms

root@neon:~# tcptraceroute http://www.bet365.com
Selected device eth0, address xxxxxxxxxxxxx, port 49427 for outgoing packets
Tracing the path to http://www.bet365.com (93.152.160.53) on TCP port 80 (http), 30 hops max
 1  xxxxxx.onlinedirect.bg (xxxxxxxxxxxxxx)  1.515 ms  0.904 ms  0.888 ms
 2  web.onlinedirect.bg (93.152.160.53) [open]  0.968 ms  0.674 ms  0.609 ms

UPDATE:
rroot@neon:~# dig bet365.com

; <<>> DiG 9.4.3-P4 <<>> bet365.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14778
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;bet365.com.                    IN      A

;; ANSWER SECTION:
bet365.com.             4816    IN      A       5.226.178.10

;; Query time: 2 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Tue Jun 25 20:56:55 2013
;; MSG SIZE  rcvd: 44

root@neon:~# dig http://www.bet365.com

; <<>> DiG 9.4.3-P4 <<>> http://www.bet365.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38413
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.bet365.com.                        IN      A

;; ANSWER SECTION:
http://www.bet365.com.         300     IN      A       93.152.160.53

;; Query time: 3 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Tue Jun 25 20:57:04 2013
;; MSG SIZE  rcvd: 48

[kifavi8024]

Не знам какво точно творят, но аз сътворих това точно за 2 мин: 



Толкова е смотано да се филтрира, че без DPI не виждам как нещата ще станат като хората