трънки и блогинки

Маскиране на VPN тунел

Написано на: 07.07.2010 · 8 коментара

Твърдо убеждение на хора с тоталитарен и милиционерски манталитет е, че всеки, който ползва криптография или други средства за защита на комуникацията е вероятен престъпник. Дали обектът на вниманието им наистина укрива нещо или използва здравия си разум и оценява стойността на информацията си и риска от разкриването ѝ на трети страни е без значение за тях. Нуждата от лично и интимно пространство на интереси, знания или разговори е нещо, което притежаващите властта да наблюдават, не желаят да разберат. А аргументът, че правото на анонимност е гаранция за свобода на словото, за тях е по-несъмнено доказателство за вина от самопризнанието.

При ситуация, в която отношението като към престъпник и убеждението във вероятната вина се определят единствено от отказа на субекта да осигури възможност да бъде наблюдаван и контролиран, е подходяща идея да се планира не само въвеждането и използването на средства за защита на връзката, но и прикриването на тяхното използване. Изграждането на VPN тунели е надеждно средствo за защита на тайната на обменяната информация, но фактът на самото му присъствие може да послужи като основание за привличане на внимание и да предизвиква милиционерска намеса в частния живот.

Приемайки, че най-лошия вариант е да бъдете наблюдаван от позицията на вашия интернет доставчик, искам да предложа начини за прикриване съществуването на VPN и на времето на неговото използване.

1. Маскиране на тунела
Последните версии на OpenVPN поддържат възможност за маскиране на VPN сървъра като уеб сървър, използващ SSL. От гледна точка на наблюдаващия, вашата VPN връзка ще изглежда като нормална https сесия. Ако наблюдаващия опита да зареди адреса, с който сте се свързали, може да го посрещне някаква уеб страница, която е логично да бъде защитена със SSL. Съвместяването на две услуги на един порт функционира като VPN сървъра посреща заявката, проверява протокола и авторизацията и препраща към уеб-сървъра, ако зададените изисквания не бъдат изпълнени. Функционалността на OpenVPN се нарича споделяне на порт (port-share) и това е извадка от примерна конфигурация на сървъра:

# Режим на сървър, ползващ tcp
proto tcp-server
# Порт за VPN сървъра
port 443
# При неуспешна аутентикация препраща на:
port-share 127.0.0.1 4443

Възможността на OpenVPN работи отлично, като единствения проблем, който забелязах, че когато openvpn препраща към httpd подменя и IP адреса на потребителя със своя (т.е. 127.0.0.1 в примера). Не е сериозен проблем, но трябва съобразите привидните уеб приложения, които ще прикриват VPN-a.

2. Прикриване на активността
Въпреки че наблюдаващият не може да разбере какви данни се обменят във VPN тунела, наличието активност може да му даде информация кога потребителят е ползва тунела и какви приблизителни обеми данни обменя. Ако наблюдаващият знае кога потребителя е активен и къде се намира, то това може да му послужи, за да го атакува по време, когато има най-голям шанс да достъпи обменяните данни. Сещам се за два принципни подхода да се прикрие времето активността: създаване на постоянен, непроменяем в зависимост от активността трафик и създаване на постоянен случаен по обем трафик, който да прикрие пиковете, когато връзката се ползва.
2.1. Постоянен трафик
Идеята е да имаме постоянен трафик (примерно 1 Mbps) в тунела, който да се състои от шум и полезен трафик. Шумът е с по-нисък приоритет и когато се появи полезен трафик, шумът се „свива“, като остава общият трафик от 1 Mbps непроменен. Тъй като всичко извън компютъра ви се разглежда като потенциално враждебно, приоритизацията е най-подходящо да се осъществи с tc. Не се оправям с ползването на tc и когато разпитах за възможни решения Зак и Светла ми предложиха следния скрипт:

dev=“tun0″
# Root
tc qdisc del dev $dev root
tc qdisc add dev $dev root handle 1: htb default 5 r2q 1
#Common class
tc class add dev $dev parent 1:0 classid 1:10 htb rate 1mbit burst 128k
tc qdisc add dev $dev parent 1:10 handle 10: sfq perturb 10
# ICMP
tc class add dev $dev parent 1:10 classid 1:20 htb rate 768kbit ceil 1mbit burst 96k cburst 128k
tc qdisc add dev $dev parent 1:20 handle 20: sfq perturb 10
tc filter add dev $dev parent 1:0 protocol ip prio 1 u32 match ip protocol 1 0xff flowid 1:20
# All
tc class add dev $dev parent 1:10 classid 1:30 htb rate 256kbit ceil 1mbit burst 32k cburst 128k
tc qdisc add dev $dev parent 1:30 handle 30: sfq perturb 10
tc filter add dev $dev parent 1:0 protocol ip prio 51 u32 match ipdst 0.0.0.0/0 flowid 1:30

2.2. Случаен трафик
Постоянният трафик може да ви се струва като разхищение, да вярвате повече на случайността, да нямате възможност да осигурите постоянен канал или да имате някаква друга причина да не харесвате горното решение. Случайните пикове и спадове също могат да направят полезния трафик неотличим за външен наблюдател, като един от най-лесните начини да се създаде случаен шум е следния bash скрипт, който Васил предложи:

while /bin/true ; do num=$RANDOM; len=$RANDOM; ping -c $num -s $len remote & ; sleep 1; done

И в този и в горния случай предпочитам да използвам ICMP за създаване на шум в тунела, защото той може да бъде по-лесно моделиран и отделен от „нормалния“ трафик.

За това се сещам, но съм сигурен, че има други и по-добри начини да се направи. Ако имате корекции и допълнения – ще ги науча с интерес.

Категория: всякакви

8 коментара ↓

  • Хубаво ми е, когато хората коментират. Чета внимателно всеки коментар и отговарям, когато имам какво да кажа.

  • Пламен на 07.07.2010г. в 11:20ч.

    Технологията е позната на военните от години. Цифровите апаратури за засекретена връзка при свързочните поделения работят на същия принцип. Слушаш канала и независимо дали някой го ползва той си бърбори. Практически на слух не може да се направи разлика кога по него текат данни и кога не. Алгоритмите на кодиране ако помня добре осигуряват ниво на защитеност близко до идеалното, т.е трябват много години компютърно време за разбиване. Не съм чел в детайли теорията но съм убеден че може да се намери в мрежата. Далаверата е свързана с теорията на сигналите и управление на ентропията . Доста математика но съм виждал как работи. Нямам идея до каква степен обаче е популярна като реализация в цивилни проекти. Магията се състои в синхронизацията на приемната и предаващата страна, така че и двете да знаят какво минава в момента. Друго с което мога да помогна е че двете страни естествено и имат ключове , които в никаква част не се предават по канала в момента на комуникация, както и че се сменят през определен период. Такива работи.

  • singu на 07.07.2010г. в 11:48ч.

    Няколко други техники, които позволяват използването на VPN, дори и там където се опитват да го забранят:

    VPN, който се маскира като DNS: http://www.dnstunnel.de/
    VPN, който се маскира като ICMP трафик: http://github.com/jakkarth/icmptx

  • Милен на 07.07.2010г. в 17:12ч.

    МВР vs Civil Society :) Пейо, започваш да ставаш оперативно интересен :)

  • Zaya на 19.07.2010г. в 01:41ч.

    Мда и ще бъдеш „разработван“ :)

  • Съновник на 27.07.2010г. в 13:51ч.

    A при wi fi кое е по – добро криптиране. WEP, WPA, WPA-PSK и WPA2-PSK и т.н.

  • deep на 13.09.2010г. в 15:59ч.

    Идеята е проста:
    Прекарване на VPN сесия посредством PING чрез ptunnel и OpenVPN.
    Дали на някой му е известно за портната версия на ping tunnel за Windows?
    http://www.cs.uit.no/~daniels/PingTunnel/
    Последната версия поддържа UDP на порт 53 ;)
    Просто ползвам Windows и не ми се мигрира на Linux ;)
    …и как може да се тунелира с него OpenVPN сесия не ми стана много ясно!
    Мерси предварително!

  • singu на 16.09.2010г. в 12:02ч.

    колега deep, правите много лоша реклама на фирмата си, като не четете… от линка, който сам сте дал:

    Wouter van der Veer has been kind enough to provide a compiled Windows binary on his website, which you can download here ( http://vps.galway.nl/ptunnel/ptunnel.exe )

  • deep на 16.09.2010г. в 14:27ч.

    Съгласен съм, може би некоректно от моя страна е неправилното задаване на въпрос, без да се оправдавам с бързина, но уви…
    Поръсвам си главата с пепел, та питането ми беше основно за НОВА версия, на ptunnel (0.71), като текущата в момента е 0.70.
    Наистина singu сте прав за лошата реклама и си вземам поука.
    Остава висящ въпроса за прекарването на OpenVPN сесия чрез ползването на ptunnel и трябва ли да има ptunnel от двете страни предвид, че на рутера е сложена версия на DD-WRT.
    Отново се извинявам за некоректно зададеният от мен въпрос!