DHCPCD ?
42 отговора
1251 прегледа
Re: DHCPCD ?
root@HPF_FS0002:/root> traceroute 212.91.178.184
traceroute to 212.91.178.184 (212.91.178.184), 30 hops max, 38 byte packets
1 router (142.79.50.254) 1.187 ms 1.055 ms 1.355 ms
2 172.30.128.57 (172.30.128.57) 35.973 ms 24.219 ms 24.934 ms
3 192.168.80.5 (192.168.80.5) 24.615 ms 24.710 ms 25.002 ms
4 192.135.120.254 (192.135.120.254) 24.931 ms 29.330 ms 149.639 ms
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
mai po tova vreme na denonoshtieto nqma da stane :((((
root@HPF_FS0002:/root> nmap 212.91.178.184
Starting nmap V. 2.54BETA22 ( [линк] )
All 1542 scanned ports on 178184.einet.bg (212.91.178.184) are: filtered
Nmap run completed -- 1 IP address (1 host up) scanned in 141 seconds
mdaaa zad nekakyv firewall si mai
WHEN YOU PLAY WITH THE BULL YOU GET THE HORN
traceroute to 212.91.178.184 (212.91.178.184), 30 hops max, 38 byte packets
1 router (142.79.50.254) 1.187 ms 1.055 ms 1.355 ms
2 172.30.128.57 (172.30.128.57) 35.973 ms 24.219 ms 24.934 ms
3 192.168.80.5 (192.168.80.5) 24.615 ms 24.710 ms 25.002 ms
4 192.135.120.254 (192.135.120.254) 24.931 ms 29.330 ms 149.639 ms
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
mai po tova vreme na denonoshtieto nqma da stane :((((
root@HPF_FS0002:/root> nmap 212.91.178.184
Starting nmap V. 2.54BETA22 ( [линк] )
All 1542 scanned ports on 178184.einet.bg (212.91.178.184) are: filtered
Nmap run completed -- 1 IP address (1 host up) scanned in 141 seconds
mdaaa zad nekakyv firewall si mai
WHEN YOU PLAY WITH THE BULL YOU GET THE HORN
Re: DHCPCD ?
na debianite, koito polzvam programcheto se kazva dhclient. ima si configuratzionen file v koito se ukazva kolko vreme da polzva dadeno ip, ako niama server prez kolko vreme da go tarsi i t.n. tvoita programka triabva sashto da moze da se nastroiva da pravi zaiavka kam servera prez edikakvo si vreme.
пингвине, гарго рошава........
що толкова сложно и незаконно, като има IM софтуер, а? LICQ си има много хубав plugin с който изпълняваш команди. Пускаш го с акаунт дето няма права и да кихне, за да не те хакват, а после му подаваш като команда да ти пусне ssh или направо някакъв vpn към тебе. С някаква автентикация, разбира се.
Пролетта е дяволски далече............
Пролетта е дяволски далече............
време е......
да припомним понятието хакер - инженер който използва обичайни неща по необичаен начин
кракер е съвсем друго
а за юнаците с картите visa има съвсем трето понятие - advanced script kiddies.
онзи клуб май е съставен предимно от тях, наистина.
Пролетта е дяволски далече............
кракер е съвсем друго
а за юнаците с картите visa има съвсем трето понятие - advanced script kiddies.
онзи клуб май е съставен предимно от тях, наистина.
Пролетта е дяволски далече............
Re: пингвине, гарго рошава........
За такива обиди ще ти оскубя листата от корените нагоре.
А сега по темата.
> що толкова сложно
Ами на практика имаш компютър към който в едната посока за забранени каквито и да е нови връзки, а целта ти е да създадеш нова връзка. Нормално е да е сложно.
> и незаконно,
Мисля че не е. Във всеки случай не мисля че могат да ти представят каквото и да е обвинение, което ще издържи в съда.
> като има IM софтуер, а? LICQ си има много
> хубав plugin с който изпълняваш команди. Пускаш го с акаунт дето няма
> права и да кихне, за да не те хакват, а после му подаваш като команда да
> ти пусне ssh или направо някакъв vpn към тебе. С някаква автентикация,
> разбира се.
Така да, това което го дадох е пример за решение без използването на трети помощен сървър, щото в решението с licq на практика ползваш техния сървър за да организираш тунел. Т.е. още преди да организираш vpn-а, вече имаш тунел през който може да подаваш команди. Ако допуснем използването на междинни сървъри, то има много решения. Наистина обаче това с licq-то е най-елегантното, което съм чувал досега.
А сега по темата.
> що толкова сложно
Ами на практика имаш компютър към който в едната посока за забранени каквито и да е нови връзки, а целта ти е да създадеш нова връзка. Нормално е да е сложно.
> и незаконно,
Мисля че не е. Във всеки случай не мисля че могат да ти представят каквото и да е обвинение, което ще издържи в съда.
> като има IM софтуер, а? LICQ си има много
> хубав plugin с който изпълняваш команди. Пускаш го с акаунт дето няма
> права и да кихне, за да не те хакват, а после му подаваш като команда да
> ти пусне ssh или направо някакъв vpn към тебе. С някаква автентикация,
> разбира се.
Така да, това което го дадох е пример за решение без използването на трети помощен сървър, щото в решението с licq на практика ползваш техния сървър за да организираш тунел. Т.е. още преди да организираш vpn-а, вече имаш тунел през който може да подаваш команди. Ако допуснем използването на междинни сървъри, то има много решения. Наистина обаче това с licq-то е най-елегантното, което съм чувал досега.
на листата тъкмо им е време.....
та ако ти се катери, скуби.
а иначе определено оценявам метода.
btw, не мисля че ip трябва да е мъртъв - лесно ще отличиш неговите отговори от твоите
незаконно беше фигуративен израз - нямам предвид смисъла който влага юридическата сволоч в това
иначе -
помощния IP който ползваш също може да се брои за трети помощен сървър - нищо че участва само проформа :-)
Пролетта е дяволски далече............
а иначе определено оценявам метода.
btw, не мисля че ip трябва да е мъртъв - лесно ще отличиш неговите отговори от твоите
незаконно беше фигуративен израз - нямам предвид смисъла който влага юридическата сволоч в това
иначе -
помощния IP който ползваш също може да се брои за трети помощен сървър - нищо че участва само проформа :-)
Пролетта е дяволски далече............
Трудна работа, но...
Значи първия начин е и всяка от маскираните машини да поддържа по един автоматично настроен канал чрез изпращане на tcp syn пакети към някое мъртво IP. Много е важно IP-то наистина да е мъртво, иначе дошлия от немъртвата машина tcp rst пакет ще утрепе създадения канал. На практика ip conntrack модула на линукс поддържа един краен автомат за всяка следена tcp връзка и го терминира при получаването на rst пакет. Двете маскирани машини ще си обменят данни чрез icmp net unreachable съобщения. Естествено за да може да се ползва това реално, трябва това да се обвие в някакъв userspace тунел, което е лесната част защото линукса си поддържа без проблем /dev/tun устройства за тази цел. Кофтито е че пропусквателната способност на такъв тунел ще е минимална, щото icmp error съобщенията не са най-добрия начин за тунелиране на данни. Очаквам около 1/10 от генерирания трафик да е полезен. Може би още по-зле.
Втория начин е на практика да се реализира по някакъв начин tcp сесия. Трудното е инициирането и то дотолкова че на практика е невъзможно :-)
Забавих се щото досега рових из кода на netfilter-а дето прави маскарадинга.
Проблема е _принципен_. Мързи ме да ги описвам подробно затова накратко:
За да има що-годе нормална производителност трябва да има стандартна tcp връзка между двете маскиращи машини. Няма начин тази нормална tcp връзка да се организира по стандартен начин, защото едната машина трябва да прави listen, а другата connect. connect-а може да го симулираме като пращаме connect заявки от маскираната машина, но няма как да принудим някоя от маскиращите машини да направи listen (евентуално може да се направи някоя магия ако има ftp маскарадинг пуснат, ама нямам време да го разследвам). Така че трябва да се излъжат по някакъв начин всяка от маскиращите машини че уж от тях е извършена връзка към другата, а после като влязат в established state вече няма значение кои е инициирал връзката и може някак си да се синхронизират двете машини. Щеше да е възможно със спуфнати пакети, ама идващите от отсрещната машина rst пакети развалят всичко. Кофти.
Обаче подобен трик може да се направи със udp, понеже там в действителност няма истински сесии и много по лесно се постига иницииране на "връзката". Kавичките са щото в действителност не е connection oriented protocol. Трябва "сравнително" едновременно всяка от маскираните машини да инициира връзка към отсрещната (не нейната) маскираща машина. Нужно е dst порта на udp заявката да съвпадне със сорс udp порта използван от отсрещната маскираща машина за да маскира тя изходящата udp заявка на нейната си маскирана машина. Не е толкова невероятно при положение че е сравнително лесно да се предсказват номерата на изходящите udp, а и може на един опит да се пускат паралелно по 30-40 заявки съм отсрещната машина, за да се увеличат шансовете. Горе като писах "срвнително" едновременно значи разминатането във времето да не надвишава 1/2 от round-trip времето между двете машини. Мързи ме да пиша повече, затова колкото повече пиша толкова повече претупвам :-) ама няма смисъл да описвам всички детайли, освен ако не си решил да пишеш нещо такова. Естествено като се организира udp връзката трябва да се опакова в vpn тунел, ама това е най-малкия кахър. С две думи скапан проблем.
Втория начин е на практика да се реализира по някакъв начин tcp сесия. Трудното е инициирането и то дотолкова че на практика е невъзможно :-)
Забавих се щото досега рових из кода на netfilter-а дето прави маскарадинга.
Проблема е _принципен_. Мързи ме да ги описвам подробно затова накратко:
За да има що-годе нормална производителност трябва да има стандартна tcp връзка между двете маскиращи машини. Няма начин тази нормална tcp връзка да се организира по стандартен начин, защото едната машина трябва да прави listen, а другата connect. connect-а може да го симулираме като пращаме connect заявки от маскираната машина, но няма как да принудим някоя от маскиращите машини да направи listen (евентуално може да се направи някоя магия ако има ftp маскарадинг пуснат, ама нямам време да го разследвам). Така че трябва да се излъжат по някакъв начин всяка от маскиращите машини че уж от тях е извършена връзка към другата, а после като влязат в established state вече няма значение кои е инициирал връзката и може някак си да се синхронизират двете машини. Щеше да е възможно със спуфнати пакети, ама идващите от отсрещната машина rst пакети развалят всичко. Кофти.
Обаче подобен трик може да се направи със udp, понеже там в действителност няма истински сесии и много по лесно се постига иницииране на "връзката". Kавичките са щото в действителност не е connection oriented protocol. Трябва "сравнително" едновременно всяка от маскираните машини да инициира връзка към отсрещната (не нейната) маскираща машина. Нужно е dst порта на udp заявката да съвпадне със сорс udp порта използван от отсрещната маскираща машина за да маскира тя изходящата udp заявка на нейната си маскирана машина. Не е толкова невероятно при положение че е сравнително лесно да се предсказват номерата на изходящите udp, а и може на един опит да се пускат паралелно по 30-40 заявки съм отсрещната машина, за да се увеличат шансовете. Горе като писах "срвнително" едновременно значи разминатането във времето да не надвишава 1/2 от round-trip времето между двете машини. Мързи ме да пиша повече, затова колкото повече пиша толкова повече претупвам :-) ама няма смисъл да описвам всички детайли, освен ако не си решил да пишеш нещо такова. Естествено като се организира udp връзката трябва да се опакова в vpn тунел, ама това е най-малкия кахър. С две думи скапан проблем.
Re: на листата тъкмо им е време.....
> та ако ти се катери, скуби.
Размислих. Ще използвам касетъчна бомба. Само кажи квартала :-)
> btw, не мисля че ip трябва да е мъртъв - лесно ще отличиш неговите отговори от твоите
Проблема е че дошлия rst ще дропне виртуалната връзка направена от маскиращата машина.
Размислих. Ще използвам касетъчна бомба. Само кажи квартала :-)
> btw, не мисля че ip трябва да е мъртъв - лесно ще отличиш неговите отговори от твоите
Проблема е че дошлия rst ще дропне виртуалната връзка направена от маскиращата машина.
достоен отговор!
аз се бях сетил само за първия начин. второто го мислих, мислих и не стигнах до никъде (там има хешове за преодоляване, етц, етц, задачата изхакерява)
udp е добра идея, но само ако те изобщо минават (а то не е много често) - а аз изобщо не се сетих, признавам.
май ще трябва да мисля за нещо от вида ppp over icq - производително не много повече от icmp пакетите, но поне доста по-лесно
Пролетта е дяволски далече............
udp е добра идея, но само ако те изобщо минават (а то не е много често) - а аз изобщо не се сетих, признавам.
май ще трябва да мисля за нещо от вида ppp over icq - производително не много повече от icmp пакетите, но поне доста по-лесно
Пролетта е дяволски далече............
I H4V3 D4 P0W3R
4nd 3y3 4hm g01ng f0r ult1m4t3 l33tn355.
Не е лесно човек да си поддържа реномето на "самовлюбено админче" :-)
> аз се бях сетил само за първия начин. второто го мислих, мислих и не
> стигнах до никъде (там има хешове за преодоляване, етц, етц, задачата
> изхакерява)
Определено има нужда от доста сложни операции за да се направи tcp връзка. Първо трябва да се spoof-нат няколко пакета за да се симулира tcp/ip връзка, като преди това да се syn flood-не отсрещната машина за да не обърка нещата с rst отговор. Доста грубо решение, ако въобще проработи.
UDP-то е доста по лесно. Освен това vpn мрежи е по-добре да се правят върху udp, щото не ни трябва tcp връзката на vpn-а да се бърка със своя ретрансмит.
На който ip-базиран протокол му трябва ретрансмит си го резализира.
> udp е добра идея, но само ако те изобщо минават (а то не е много често) -
> а аз изобщо не се сетих, признавам.
Ами стандартния маскарадинг си поддържа UDP, така че няма проблеми. А даже и да има файъруоли, може да ги пращаш със сорс порт 53. Никъде не си казал че ще играеш честно :-)
> май ще трябва да мисля за нещо от вида ppp over icq - производително не
> много повече от icmp пакетите, но поне доста по-лесно
Ама по-добре да не е ppp, а нещо дето да ползва generic tun драйвера на линукс, щото не е нужно да имаш още и ppp обвивка на ip трафика ти.
Кофти обаче при всички случаи ще прехвърляш пакетите през icq сървъра и латентността ще е ужасна, на практика ще става за файл трансфер, ама за интерактивна работа ще е ужас.
Не е лесно човек да си поддържа реномето на "самовлюбено админче" :-)
> аз се бях сетил само за първия начин. второто го мислих, мислих и не
> стигнах до никъде (там има хешове за преодоляване, етц, етц, задачата
> изхакерява)
Определено има нужда от доста сложни операции за да се направи tcp връзка. Първо трябва да се spoof-нат няколко пакета за да се симулира tcp/ip връзка, като преди това да се syn flood-не отсрещната машина за да не обърка нещата с rst отговор. Доста грубо решение, ако въобще проработи.
UDP-то е доста по лесно. Освен това vpn мрежи е по-добре да се правят върху udp, щото не ни трябва tcp връзката на vpn-а да се бърка със своя ретрансмит.
На който ip-базиран протокол му трябва ретрансмит си го резализира.
> udp е добра идея, но само ако те изобщо минават (а то не е много често) -
> а аз изобщо не се сетих, признавам.
Ами стандартния маскарадинг си поддържа UDP, така че няма проблеми. А даже и да има файъруоли, може да ги пращаш със сорс порт 53. Никъде не си казал че ще играеш честно :-)
> май ще трябва да мисля за нещо от вида ppp over icq - производително не
> много повече от icmp пакетите, но поне доста по-лесно
Ама по-добре да не е ppp, а нещо дето да ползва generic tun драйвера на линукс, щото не е нужно да имаш още и ppp обвивка на ip трафика ти.
Кофти обаче при всички случаи ще прехвърляш пакетите през icq сървъра и латентността ще е ужасна, на практика ще става за файл трансфер, ама за интерактивна работа ще е ужас.
Re: DHCPCD ?
проблема може би не е толкова при моя компютър,а при модема,на него са закачени няколко компютъра през хъб
и някой от тях май си прави някакви експерименти и от това модема забива
като гледах лога на модема,винаги има по една грешка,когато остана без и-т
Bridge Ethernet Hook. Failed to learn CPE MAC Address.
MAC Filters. Add MAC Address can't add entry. Table is full.
живей за мига
и някой от тях май си прави някакви експерименти и от това модема забива
като гледах лога на модема,винаги има по една грешка,когато остана без и-т
Bridge Ethernet Hook. Failed to learn CPE MAC Address.
MAC Filters. Add MAC Address can't add entry. Table is full.
живей за мига