Linux за българи: Форуми

Здравейте, става въпрос за блокиране на skype комуникацията на компютри намиращи се зад slackware 13 рутер? Четох в интернет и това май е мисия невъзможна...така ли е наситина?
Ще се радвам да споделите ако Вие имате някакви предложения или ако успешно сте успели да го блокирате.
Видях за вариант със качване на прозрачно Squid прокси и чрез него блокирането на метод CONNECT, т.е. нещо такова:

acl numeric_IPs urlpath_regex ^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+
acl connect method CONNECT

до колко е ефективно това, някой да го е пробвал?
Извинявам се за тъпият въпрос но със проксито конфигурирано по този начин блокира ли UDP трафикът, защото май скайп ползва и него? Или това зависи от правилото за пренасочване на iptables?

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

п.п. един ред ти липсва - http_access deny connect numeric_IPs all
п.п. НО аз все пак не съм голям разбирач, може аз да не мога да го направя. ;D

Здравейте, става въпрос за блокиране на skype комуникацията на компютри намиращи се зад slackware 13 рутер? Четох в интернет и това май е мисия невъзможна...така ли е наситина?
Ще се радвам да споделите ако Вие имате някакви предложения или ако успешно сте успели да го блокирате.
Видях за вариант със качване на прозрачно Squid прокси и чрез него блокирането на метод CONNECT, т.е. нещо такова:

Цитат

acl numeric_IPs urlpath_regex ^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+
acl connect method CONNECT

до колко е ефективно това, някой да го е пробвал?
Извинявам се за тъпият въпрос но със проксито конфигурирано по този начин блокира ли UDP трафикът, защото май скайп ползва и него? Или това зависи от правилото за пренасочване на iptables?

И аз не съм успявал да го спра до сега след многобройни опити

А някой да е пробвал L7-filter

http://l7-filter.sourceforge.net/protocols

skypeout            Skype to phone - UDP voice call (program to POTS phone) - http://skype.com
skypetoskype     Skype to Skype - UDP voice call (program to program) - http://skype.com

А някой да е пробвал L7-filter

http://l7-filter.sourceforge.net/protocols

Цитат

skypeout            Skype to phone - UDP voice call (program to POTS phone) - http://skype.com
skypetoskype     Skype to Skype - UDP voice call (program to program) - http://skype.com

Ti пробвал ли си го ? работи ли

Не съм - само питам :) Явно, не е пълно блокиране на Skype - прим. чатът май ще работи.

"Филтрирай" ip's на skype сървърите. :)

"Филтрирай" ip's на skype сървърите. :)

Знаеш ли ги

http://forum.skype.com/lofiversion/index.php/t50875.html

PDF-а е предимно за настройки на Win и групови политики... не е нищо интересно

Всъщност за какво ви е да блокирате Skype? То ако се почне със Skype трябва да се продължи с ICQ, MSN, ... Facebook, Twitter... списъкът е безкраен.

http://forum.skype.com/lofiversion/index.php/t50875.html

PDF-а е предимно за настройки на Win и групови политики... не е нищо интересно

Всъщност за какво ви е да блокирате Skype? То ако се почне със Skype трябва да се продължи с ICQ, MSN, ... Facebook, Twitter... списъкът е безкраен.

Много ми е интересно някой ако успее да спре skype  с лан политики. Имам в предив да не му се спира на човека да може да инталира , да се ходи от комп на конп и тем подобни. Или с домейн контролер.

ntrance, не е невъзможно да се netstat -nat в два тхт (които да се сравнят), при включен и спрян skype на workstation, на който временно са ограничени, до минимум, другите пуснати интернет приложения.

progmetal, не напразно, малко след създаването на програмата, openbsd запушиха възможностите за портването й върху тяхнoто дистро, не че не може.
Разправят, била конче.

Ps. Мъдрите препоръчват ползването на далеч по - ефикасния и безопасен sip, чрез Ekiga, например, но кой ти чува ...

Всъщност за какво ви е да блокирате Skype? То ако се почне със Skype трябва да се продължи с ICQ, MSN, ... Facebook, Twitter... списъкът е безкраен.

Безкраен ... не бих казал - ти сам го изброи :)

//off
И на първо място фейса  :D :D :D :D :D :D

//off
Friendface
"I feel so social!"

 >:D

Възможно е да се блокира skype, макар и да e много трудно.
решението е snort и iptables rules, като се блокира p2p skype протокола. няма смисъл да се блокират UDP портове, които се ползват от rtp (voice) пакетите.
по-добре да се прекъсне връзката между skype client i skype node, като за целта се ползва snort
snort-a следи за пакети съдържащ сигнатура: 0x17030100 - пакет който се връща от skype node / login server-a , след това този пакет се drop-ва и връзката на клиента към сървъра се прекъсва. Няма skype :)

l7 iptables patch-a не прави ли същото?

EDIT: Сега видях, че си писал за логин последователност. Предполагам, че string match-a на iptables ще се справи също толкова добре.

Възможно е да се блокира skype, макар и да e много трудно.
решението е snort и iptables rules, като се блокира p2p skype протокола. няма смисъл да се блокират UDP портове, които се ползват от rtp (voice) пакетите.
по-добре да се прекъсне връзката между skype client i skype node, като за целта се ползва snort
snort-a следи за пакети съдържащ сигнатура: 0x17030100 - пакет който се връща от skype node / login server-a , след това този пакет се drop-ва и връзката на клиента към сървъра се прекъсва. Няма skype :)

Ще дадеш ли пример ?

Кое точно му е по-безопасното на Ekiga? Че SIP съобщенията и аудио-то се размотават по мрежата некриптирани?

skype protocol e по-добър, като идея и технология от SIP-а. При SIP-a няма криптиране на връзката и по същност SIP съобщенията са почти еднакви с HTTP протокола ( това е най-общо казано).

А за блокирането на skype в snort-a има SID:5999 и той върши тази работа с блокирането на skype трафика  - http://www.snort.org/search/sid/5999

snort-a следи за пакети съдържащ сигнатура: 0x17030100 - пакет който се връща от skype node / login server-a , след това този пакет се drop-ва и връзката на клиента към сървъра се прекъсва. Няма skype :)

Това:

GeSHi (Bash):
iptables -A INPUT -p tcp -m string --hex-string "|16030100|" --algo bm -j DROP
iptables -A INPUT -p tcp -m string --hex-string "|17030100|" --algo bm -j DROP
iptables -A OUTPUT -p tcp -m string --hex-string "|16030100|" --algo bm -j DROP
iptables -A OUTPUT -p tcp -m string --hex-string "|17030100|" --algo bm -j DROP

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

(нарочно съм задал проверка в двете посоки, защото от статията, която четох не става много ясно кой пакет за къде е)

А за блокирането на skype в snort-a има SID:5999 и той върши тази работа с блокирането на skype трафика  - http://www.snort.org/search/sid/5999

Можеш ли да дадеш rule-a тук?

Абе това не е ли малко лоша идея? В смисъл тези 4 байта може да се срещнат на теория примерно в някой RPM или DEB пакет с който си ъпдейтваш системата?

Пак давам линк, но този път ми се струва полезен:

http://www.carbonwind.net/Firewalls/BlockingSkypewithPfsenseandSnort/BlockingSkypewithPfsenseandSnort.htm

Нищо не става - логвам се :) Или този стринг минава в два пакета или просто не е това в протокола вече ...

@gat3way със сигурност е кофти начин за детектване на трафик :) Би могло да се гледа дали е в пърите пакети от тази TCP сесия ...

Пак давам линк, но този път ми се струва полезен:

http://www.carbonwind.net/Firewalls/BlockingSkypewithPfsenseandSnort/BlockingSkypewithPfsenseandSnort.htm

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

Цитат на: progmetal в Dec 15, 2009, 11:16

Пак давам линк, но този път ми се струва полезен:

http://www.carbonwind.net/Firewalls/BlockingSkypewithPfsenseandSnort/BlockingSkypewithPfsenseandSnort.htm

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

Айде успех ако се справиш кажи , аз съм доста скиптично настроен :)  към спирането но ако успееш кажи

Цитат на: VladSun в Dec 15, 2009, 11:38

Цитат на: progmetal в Dec 15, 2009, 11:16

Пак давам линк, но този път ми се струва полезен:

http://www.carbonwind.net/Firewalls/BlockingSkypewithPfsenseandSnort/BlockingSkypewithPfsenseandSnort.htm

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

Айде успех ако се справиш кажи , аз съм доста скиптично настроен :)  към спирането но ако успееш кажи

Е, то и аз съм скептично настроен за снорт решението, ако то разчита само на откриването на тази байтова последователност в пакет ... Това исках да покажа.

@offtopic
Най сигорния начин е  да се разберете да не се ползва скайп и това ако не спомогне , ходиш и му казваш или порното или скайпа :) пак и това ако не помогне   ходиш му режеп кабела : >:D >:D

Аз нали обичам да фантазирам ....
Не може ли да се забрани всичко и да се пуснат само желаните услуги и после като се оплаче някой да се подхожда индивидуално ?

Аз нали обичам да фантазирам ....
Не може ли да се забрани всичко и да се пуснат само желаните услуги и после като се оплаче някой да се подхожда индивидуално ?

Да ти кажа за повечето неща става  , но найстина за скайп  и тем подони  незнам нямам на идея. Ако ставаше с иптаблес , защо да не се забрани DENY all   за свички и долу дно правилo ALLOW from  и така. За апаче за  базата данни  за интернета  за самбата и тем подобни може .

http://lists.grok.org.uk/pipermail/full-disclosure/2005-November/038646.html

Още:

I improved a bit the Squid config:

# Prevent Skype connecting HTTPs using CONNECT requests to IP addresses (those not using domain names)
acl numeric_IPs url_regex ^[0-9]+.[0-9]+.[0-9]+.[0-9]+
http_access deny CONNECT numeric_IPs all
# Prevent Skype connecting http
acl Skype_UA browser Skype
http_access deny Skype_UA
# Prevent anyone to download anything from skype website
acl Skype_domain dstdomain skype.com
http_access deny Skype_domain

Also now, can block Skype UDP traffic, based on this very good document http://www.secdev.org/conf/skype_BHEU06.handout.pdf using iptables (warning: Skype can�t work without a TCP connection - But Skype can work without UDP).

iptables −I FORWARD −p udp −m l e ng th −−l e ng th 39 −m u32 −−u32 �27&0 x8f=7� −−u32 �31=0 x527c4833 � −j DROP

Currently working on some patch to automate skype blocking configuration using the great EFW firewall (based on IPcop) http://www.efw.it

Cheers,
Nick

От прекрасния PDF по-горе:

How to block Skype UDP traffic with one rule

GeSHi (Bash):
 iptables -I FORWARD -p udp -m length --length 39 -m u32 --u32 '27&0x8f=7' --u32 '31=0x527c4833' -j DROP

How to make Skype deaf and dumb

GeSHi (Bash):
iptables -I FORWARD -p udp -m length --length 39 -m u32 --u32 '27&0x8f=7' --u32 '31=0x01020304' -j DROP

Лошото е, че при мен не излизат такива пакети :(

http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6723/prod_white_paper0900aecd80633b0a.html

..................

!---Defines Protocol Stack and Match Criteria (FPM filter to block Skype traffic)
class-map type stack match-all ip_tcp
match field IP protocol eq 6 next TCP
class-map type access-control match-all skype
match start TCP payload-start offset 0 size 4 eq 0x17030100

Мисля, че и други освен Cisco ползват този механизъм за блокиране на skype ... то и друг няма :)

Имам чувството че тази поредица "0x17030100" не е еднаква за всички потребители на скайп, и в посочения пример пише "In order to block Skype, perform the following steps" - за да блокирате скайп, изпълнете следващите стъпки.
И ми се струва че който иска да го блокира трябва сам да открие точната поредица за конкретния скайп акаунт, по реда който е описан в горния пример.

Аз пробвах и да DROP-я всички пакети от TCP сесиятта свързана с пакет с присъстващ 0x17030100 стринг - не се получи ...

71   42.875591   212.187.172.36   192.168.115.129   TCP   33033 > amx-icsp [PSH, ACK] Seq=1 Ack=6 Win=6144 Len=5

0000  00 1d 60 e7 ad c6 00 09  6b c0 48 1a 08 00 45 00   ..`..... k.H...E.
0010  00 2d 5d 2b 40 00 2a 06  4d 96 d4 bb ac 24 c0 a8   .-]+@.*. M....$..
0020  64 81 81 09 05 27 d4 ce  7d dd 8f 0b 6a 35 50 18   d....'.. }...j5P.
0030  00 0c 1f 91 00 00 17 03  01 00 00 00               ........ ....   

Oт WireShark преди 10 мин. - това е copy/paste и резултата се вижда - сложил съм го с Bold :)

Това е от мен по темата :)

По-горе съм дал, че ги match-вам тези пакети, DROP-я ги, но въпреки това Skype се връзва.

Това са 2-та SID-a от snort свързани със Skype Client login-a:

SID:5999 - 0x1703010000
SID:6001 - 0x17030100D9

пробвай да ги match-ваш и след това drop , със snort работи.

Това са 2-та SID-a от snort свързани със Skype Client login-a:

SID:5999 - 0x1703010000
SID:6001 - 0x17030100D9

пробвай да ги match-ваш и след това drop , със snort работи.

Ти нали видя iptables правилата ми?
Прекалено са прости за да бъркам, ама знае ли се :)

Погледнах ти правилата и мисля, че няма да вършат работа в случая.

Мисля че FORWARD веригата е достатъчно добро решение :)

Виж този линк и прочети по-точно това за conflicker : http://cipherdyne.org/LinuxFirewalls/AppB/

http://cipherdyne.org/blog/2009/07/disrupting-conficker-worm-traffic-with-iptables-and-fwsnort.html

Погледнах ти правилата и мисля, че няма да вършат работа в случая.

Мисля че FORWARD веригата е достатъчно добро решение :)

Виж този линк и прочети по-точно това за conflicker : http://cipherdyne.org/LinuxFirewalls/AppB/

Ъъъ.... забрави за INPUT/FORWARD разделението - при мен е локален процес Skype-a, та малко или много ми е ясно какво правя. Въпросът е в match-ването, connection tracking-a и политиката към тези пакети и свързаните с тях TCP сесии.

В тия последните два линка (прекалено дълги са за да ги разглеждам обстойно) Ctrl-F за skype не открива нищо. Можеш ли да конкретизираш точно, какво трябва да гледам в тях?

Това е snort rule за блокиране на skype:

tcp $EXTERNAL_NET any -> $HOME_NET any
(msg:"P2P Skype client login"; flow:to_client,established; flowbits:isset,skype.login; dsize:5;
content:"|17 03 01 00|"; depth:4; metadata:policy security-ips drop; classtype:policy-violation; sid:5999; rev:4;)

Ползвай линковете по-горе за да си генерираш ipables rules - на първия линк има скрипт за тази цел.
А на втория съм ти написал за какво да четеш .... гледай и чети за conflicker и си мисли за skype

идеята е същата - application level filtering  :)

Не съм много съгласен, че е L7 филтрирането, защото работиш с отделни TCP пакети, но както и да е...
Подозирам, че и iptables l7 patch-a е същата работа.

Нека отново кажа какво се случва - match-вам 0x17030100 (както и 0x16030100) в iptables ...
DROP-я ги - WireShark не ги намира.
Изчиствам iptables правилата - WireShark ги намира.

Следователно ? Match-ването е ОК. DROP-енето е ОК. Но Skype-а пак се логва, провеждат се разговори, чати се - т.е. изобщо не му преча !!!

Интересно е да се отбележи, че ако в OUTPUT (или клиент->сервер при тебе) се DROP-не 0x16030100 пакета, то 0x17030100 пакета изобщо не пристига на INPUT (или сървер->клиент при тебе). Т.е. последователността е:

 0x16030100 client -> server
 0x17030100 client <- server

Snort-a match-ва пакетите - ОК, и аз ги match-вам. Просто, според мен, DROP-енето на тези пакети не помага (вече?) срещу Skype (v. 2.1.0.47).

Значи, ако филтрирам 0х17030100 пакетът, Скайп отваря нова сесия към друго(!) ИП, с което си "говори" без тази байтова последователност. Все още не съм установил някакъв благонадежден pattern в новата сесия.

Зла програма е skype. Преди време им се радвах как успяват да дупчат NAT-ове, за да си прекарват трафика, обаче явно и нови забавни хрумвания са им хрумвали :)

Зла програма е skype. Преди време им се радвах как успяват да дупчат NAT-ове, за да си прекарват трафика, обаче явно и нови забавни хрумвания са им хрумвали :)

Тъй като разполагам с  domаin controler (server 2003)  и на него има една сложена програма kerio route , и с него не съм успявал    Единствения начин когато съм успявал и под wina i  linux да спра skypa  това беше когато   , влезна с админ права  от юсерския комп  и му махна скайпа , понеже ония от горе така наречените менежари  винаги им хрумва по някоя гениална идея сутринта когато не са се наспали добре. Аз след 1 седмица ровене и тестване   еми  казвам си го НЕУСПЯХ. След като се отвори тази тема и тук , с радост следях какво ще стане , но за сетен път се обеждавам че май няма как да го спрем скайпа. Предполагам си има начин , но изглежда все още не  е известен за нас или поне за мен

Може ли да провериш  другото IP към което се прехвърля login process-a  дали е от skype мрежата или не ( в ripe.net). Ако НЕ е от техните мрежи то най-вероятно всеки online skype клиент в един момент може да се явява, като междинен gateway/node/server/proxy (или както искате да го наречем :) )  през който "орязани" клиенти да стигат до skype node и login server-a.  Принципно този pattern 0х170.....,  който се връща от login server-a е трудно да го махнат ( от гледна точка на съвместимост и др.), но могат да заобикалят това филтриране на пакети по друг начин ползвайки P2P механизми. Мисля , че това правят в новите версии.

Може би ако няма никакво рутиране между вътрешната мрежа и интернет - всичко да минава през прокси, тогава VoIP трафика на скайпа няма как да мине. Но контролния трафик и чатовете предполагам ще продължат да могат да се прекарват през проксито, освен ако някой не измисли някакви много хитри правила, които да го блокират.

На който му се чете може да разгледа този линк и коментарите:

 http://share.skype.com/sites/en/2009/04/is_deutsche_telekom_playing_an.html

Това е от коментарите:

"It is our understanding that first applications to be blocked or at least heavily deprioritized will be protocols for p2p (e.g. BitTorrent) and Skype, in order to promote custom's telcos/providers VoIP solutions."

Щом телекоми, като DT,  а доколкото знам и China телеком са правили опити да блокират skype - Китай  - нали са народна република :)  .... НО - едно голямо НО, skype явно не са съгласни и са прави от тяхна гледна точка и имат $$$ интерес skype P2P протокола да е unbreakable! Това и правят и както по-горе казах,  а и в началото ,че блокирането на skype e трудно, а явно с новите версии е невъзможно. След всеки трик за блокиране на тарфика им - те пускат patch :)

Я, в уикипедията имало интересни неща по въпроса и референция към един pdf (обаче е стар и не знам дали е в сила това което пише там):

http://en.wikipedia.org/wiki/Skype_protocol

Това, което ми направи впечатление (не знам дали е валидно още де):

The RC4 encryption algorithm is used to obfuscate the payload of datagrams.

   1. The CRC32 of public source and destination IP, Skype's packet ID are taken
   2. Skype obfuscation layer's initialization vector (IV).

The XOR of these two 32 bit values is transformed to a 80-byte RC4 key using an unknown key engine.

A notable misuse of RC4 in skype can be found on TCP streams (UDP is unaffected). The first 14 bytes (10 of which are known) are xored with the RC4 stream. Then, the cipher is reinitialized to encrypt the rest of the TCP stream

След като знаеш първите 10 байта е елементарно да намериш първите 10 байта от RC4 keystream-a - просто ще XOR-неш две известни 10-байтови стойности. Тъй като след 14-тия байт, RC4 се реинициализира (под което предполагам се разбира reseed-ване на KSA и нулиране на PRGA броячите), могат да се декриптират 10 байта от съобщението - от 14-тия до 24-тия, без да знаеш ключа. Ако в тях се съдържа нещо, което да е характерен pattern за skype трафик, то тогава може да се направи някакъв много зъл филтър за скайп трафик.. Но това само при положение че между 14-тия и 24-тия байт от криптирания трафик има последователност, която да може със сигурност да докаже, че това е скайп комуникация.


П.П. ако на някой му е хрумнало че след като имаме 10-те първи байта от RC4 keystream-а можем да декриптираме целия трафик....така като гледам много трудно ще стане това. KSA се seed-ва с 80-байтов (640-битов) ключ, който както пише горе е уникален за всеки изпратен skype пакет, т.е включва някакъв skype packed ID и следователно не се преизползва. Можем да тръгнем да bruteforce-ваме RC4 алгоритъма, seed-вайки KSA с различни стойности, докато получим същите 10 байта keystream, до максимум 2^640 опита трябва да стане. Не че това не е изчислително невъзможно сложна задача де, ама все пак има и друг проблем - 10 байта keystream просто няма да са достатъчни. Ще има (2^640/2^80)-1 = (2^560)-1 ключа, които ще генерират същите 10 начални байта keystream, но няма да са правилния ключ. Така че този пропуск реално погледнато трудно ще доведе до компрометиране на криптираните съобщения.

Явно трябва да се пише connection tracking модул за Скай пакети (т.е. да се следят няколко последователни пакета от TCP сесията) и да се използва играта им с RC4 кодирането. Не мога да се сетя някакъв друг протокол, който да ползва подобно нещо.