Изпечатай

[saturn_vk]

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

Pri masquerading se smeniat w header-a na IP protocola samo source IP address TTL i checksum-ata. Edinstwenia nachin po koito biha mogli da razberat che sa maskirani paketite mojebi e po port-a. MASQUERADE po princip polzwa portowe s po golemi nomera. W comandite na iptables slojete neshto takowa
-j MASQUERADE --to-ports 1024-32768

No mai shte triabwa w komandite da se ukaje i protokola
-p udp
-p tcp

[the_real_maniac]

Е как така, всмисъл порт 80 е за УЕБ, ако ползва 81 , Уеб сървъра отсреща няма да му отговори ... Е благодаря все пак ще пробвам , само това ,което си написъл не разбирам много какво трябва да постигна с нещо ...    '>

MASQUERADE promenia source address e ne destination address. Taka che porta kym koito prawish connect naprimer 80 se zapazwa. Ako wytreshnata mashina prawi connect ot port 32768 kym 80 sled masquerade stawa naprimer 60980 kym 80. Gateway-a na provider-a ti wijda imenno tozi port 60980 a ne 32768.

Kolkoto do iptables imah predwid komandata da e neshto takowa:

iptables -t nat -A POSTROUTING -p udp -o ppp0 -j MASQUERADE --to-ports 1024-32768
iptables -t nat -A POSTROUTING -p tcp -o ppp0 -j MASQUERADE --to-ports 1024-32768
iptables -t nat -A POSTROUTING -p icmp -o ppp0 -j MASQUERADE


Moje da naprawish i towa:
echo "1025 32768" > /proc/sys/net/ipv4/ip_local_port_range

[the_real_maniac]

Ето го лога ( пренасочен изход на tcpdump -i ppp0 '> '> )  , така както аз го гледам май нищо не съм направил с ттл-а '>

Примерен код

#### 13:45:20.980213 195.149.254.38 > 217.9.231.130: icmp: echo request 13:45:20.982685 217.9.231.130 > 195.149.254.38: icmp: echo reply [tos 0x8] [ttl 1] 13:45:20.982835 195.149.254.38 > 217.9.231.130: icmp: time exceeded in-transit [tos 0xc8] #### 13:45:26.358127 195.149.254.38 > 217.9.231.130: icmp: echo request 13:45:26.361970 217.9.231.130 > 195.149.254.38: icmp: echo reply [tos 0x8] [ttl 1] 13:45:26.362100 195.149.254.38 > 217.9.231.130: icmp: time exceeded in-transit [tos 0xc8] ##### 13:45:31.364753 195.149.254.38 > 217.9.231.130: icmp: echo request 13:45:31.367401 217.9.231.130 > 195.149.254.38: icmp: echo reply [tos 0x8] [ttl 1] 13:45:31.367526 195.149.254.38 > 217.9.231.130: icmp: time exceeded in-transit [tos 0xc8] #### 13:45:36.371373 195.149.254.38 > 217.9.231.130: icmp: echo request 13:45:36.375169 217.9.231.130 > 195.149.254.38: icmp: echo reply [tos 0x8] [ttl 1] 13:45:36.375297 195.149.254.38 > 217.9.231.130: icmp: time exceeded in-transit [tos 0xc8] ####

Това е резултата от пинг от Уин ХП клиент ! Както добре си и личи де 4-те опита ... '> , но неуспешни , това беше iptables < докато течеше опита > .:

Примерен код

#!/bin/sh iptables -F iptables -F -t nat iptables -F -t mangle iptables -t nat -A POSTROUTING -p udp -o ppp0 -j MASQUERADE --to-ports 1024-32768 iptables -t nat -A POSTROUTING -p tcp -o ppp0 -j MASQUERADE --to-ports 1024-32768 iptables -t nat -A POSTROUTING -p icmp -o ppp0 -j MASQUERADE iptables -t mangle -A INPUT -j TTL --ttl-set 128 iptables -t mangle -A OUTPUT -j TTL --ttl-set 128 iptables -t mangle -A FORWARD -j TTL --ttl-set 128 iptables -t mangle -A POSTROUTING -j TTL --ttl-set 128

Еми това е , приложих всичко , което се сетих ... '>

Значи както виждаш само в това в прок не съм го записъл , сега ще пробвам и с него и ще ти кажа '> '>

А дано ... има успех ... Въпреки ,че така като гледам лог-а си е баш ттл-а проблема ...

[the_real_maniac]

Наложително беше да постнаа два отговора , защото са за две различни части от темата ...

Когато разбрах за ТТЛ пача бях много учуден кога има време да смени стойност-а му и да излъже едва ли не ТЦП/ип протокола !!! Защото май , така като гледам този патч може само да променя идващите от теб дейтаграми с какъв ттл-да са , т.е някой праща пинг до теб ( дейтаграма с ТТЛ 128 ) , само че ти му връщаш с 1 ...  

Въпреки че , вдействителност има резлутат нали като пингвам си личи , че вече не идва до мен с 1 , ами 128 ... или пробвах с --ttl-inc ( инкрементирах / т.е. увеличих / ) 128 = 129 и се влиае ... Еми незнам какво мислиш , какво казва лог-а ?!.

МАЙ няма спасение  ,освен проксито , мама мия ... '>

Моля ти се Добрев помагай ... '>

Iawno provider-a ti prashta paketite s TTL 1 koeto oznachawa che ne mogat da preminat prez twoia gateway poneje ttl-a triabwa da se namali s 1 pri forward. A kato stane 0 ne moje da se naprawi FORWARD.
Ne znam zashto ne se promenia ttl-a s komandite na iptables. Kompiliral li si kernel-a s opciite za TTL sled kato si go pachnal s p-o-m i polzwash li tozi kernel ?
Pusni tcpdump-a po slednia nachin
tcpdump -vvv -i ppp0
Shte pokaje poweche neshta taka. Shte widish dali paketite koito izlizat ot twoia box sa s jelania ttl. Taka pone shte widish dali --ttl-set raboti.

[the_real_maniac]

ДА пачнат е , да модулите са инсталирани ( и модинст имам предвид) , да ползвам това ядро ... ДА - точно това ,казвам и аз , сякаш ТТЛ пача не си върши работата !!! Но иначе като пингвам към дата.бг ми даваше ТТЛ=1 , сега си ми дава 128 , на колко съм го нагласил , ще пробвам това за tcpdump , айде прятел прати ми мейл да се вържа с теб , да ти дам ицю -то ... '> '> Или искаш тук да продължим , всмисъл полсе ще напиша какво сме правили .. '> Май по-добре тук да си бъде разговора ...

Еми ще пробвам '> '> Но утре , че сега е късно ... имам си друга работа '>

[the_real_maniac]

Направих ГО !!!

РАДОООООООООСТТТТТТТТТ '>))))

Както винаги нямаше особена логика сега почвам да чета за ВЕРИГАTA PREROUTING !!! ЗАЩО ли !!!

еми вече се чудех какво е и мислех и се сетих , че наскоро имаше един проблем в един друг форум за маскирането , беше друго не за ТТЛ , но добави същия ред като ПОСТРОУТИНГ в ПРЕ и аз съ милсех така и така да пробвам , да направя навсякъде , а досега навсякъде в -t mangle , освен PREROUTING бях -j TTL -нал , така да се кажа , РАДДОООООСТ !!! '>)))

Та значи първо ми дойде идеята да направя навсякъде ТТЛ инкрементиране / увеличаване и после като се сетих за това ми дойде съвсем надежда и така го направих , е преди това изпробвах tcp -v -i ppp0 значи аз пращах ТТЛ=255 , а идваше ТТЛ=1 и умираше , сега почвам да чета за PREROUTING и да видя дали само то трябва да е -j TTL '> '> Ili wsi4ki , абе има някаква логика , много ми е кеф '>

... '>)))

ети конф. файлове '>

SOON ...

Примерен код

# MY FIREWALL / NETFILTER CONF # MASQUERADEING and TTL prefuck*** XAXAXA #!/bin/sh iptables -F iptables -F -t nat iptables -F -t mangle iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE iptables -t mangle -A INPUT -j TTL --ttl-inc 128 iptables -t mangle -A OUTPUT -j TTL --ttl-inc 128 iptables -t mangle -A FORWARD -j TTL --ttl-inc 128 iptables -t mangle -A POSTROUTING -j TTL --ttl-inc 128 iptables -t mangle -A PREROUTING -j TTL --ttl-inc 128 echo "1" > /proc/sys/net/ipv4/ip_forward #От тук нататък Вие трябва да си изградите самия # FIREWALL !!! :) :P

'>

[saturn_vk]

да, наистина е било от живота на пакетите.

иначе за да могат пакетите да доживеят до вътрешните ти компютри, ти трябва само:

iptables -t mangle -A PREROUTING -j TTL --ttl-inc 128

а не всичките пет реда.

[the_real_maniac]

ДА усетих , значи снощи го установих , а днес ми го обясниха '> Че не INPUT , а PREROUTING е веригата , която първа поема пакета и затова , а аз няма да инкрементирам , а ще си сетвам '>

... -j TTL --ttl-set 128 '>

Айде упсех , сега вече не ти трябва прокси , въпреки ,че  е по-добрия вариант '> Е успех , идеята е да не се отказваш и да се бориш '>

[saturn_vk]

доколкото знам (тия неща съм се опитал сам да си ги разбера, затова може и да не са вярни), INPUT е за пакетите които отиват само към сървъра, OUTPUT е за пакетите които напускат само сървъра, а FORWARD, PRE и POST са за другите вътрешни компютри. Също така PREROUTING е правилната таблица, защото всичките неща в нея се извършват преди пакетите да бъдат препратени.

разбира се, всичко това може да е грешно, а тея неща не се обясняват много добре във manual-a на iptables.

[the_real_maniac]

Мдаа прави си ... за мануал-а / хоуто-то по-точно , само обясненията ти за веригите не ми харесаха много , но може и така '> '> Еми браво на мен и на нас .. '>  '>