Изпечатай

[Ali Nebi]

Здравейте,

значи имам следната ситуация... На един от сървърите ни сме качили софтуер, който работи на даден порт (примерно порт 5000) и ползва UDP протокола, но по трасето, доста от междинните станции са си затворили този порт. Имали някакъв начин да се преодолее това?

[neter]

Бъди по-подробен. Според предназначението на софтуера е възможно да се налага използване на някаква тънкост. Ето, все пак, основните ми предложения:
1. Разгледай подробно дали няма настройка на този софтуер кой порт да използва и, ако има, го промени.
2. Ако няма такава настройка, следват два подслучая
а) този софтуер слуша за входящи конекции на порт 5000. Тогава пренасочваш някой друг порт, който е позволен, да отвежда конекциите към порт 5000 с командата
iptables -t nat -I PREROUTING 1 -p udp -i eth0 --dport 4000 -j DNAT --to 111.222.333.444:5000
където eth0 и 111.222.333.444 са съответно интерфейса и IP-то на картата, която е вързана към Интернет, а 4000 и 5000 са съответно позволения и непозволения порт. Тогава хората отвън ще трябва да се свързват към порт 4000, вместо към порт 5000, на който всъщност слуша софтуера.
б) този софтуер прави изходящи конекции нанякъде навън по порт 5000. Хмм... нещо нямам идея за момента за този вариант.

Все пак бъди по-подробен! Или е секретно?  '>

[laskov]

Навремето OpenVPN работеше на 5000 udp, но вече имат стандартизиран порт 1194 и в последните версии е по подразбиране. Та навремето го бях пуснал на 5001, задава се в  конфиг файла.

[Ali Nebi]

Да това за смяната на порта ще свърши работа, но имали някакъв начин да проследя какво се случва с затворения порт и защо и къде може да е затворен?

[laskov]

5000 се ползвал за някакво pnp в windows ХР. Имаше някаква уязвимост, която после беше закърпена..., но как да разбереш кой го спира ...  '>

[gat3way]

Ако е забранен на някой рутер, принципно блокирането на UDP портове се прави с правило, което връща ICMP грешка, хостът върнал грешката е виновникът. Тъй като много хора обаче тихо ги DROP-ват, върви разбери какво става. UDP протоколът не гарантира някаква обратна комуникация, примерно като пратиш SYN да ти се върне SYN-ACK или RST, така че дали е приет отсреща или издропен нямаш голяма гаранция.

Има все пак начин да се разбере кой ти discard-ва тихо пакетите. Хващаш hping3 или нещо от сорта и почваш да пускаш до хоста UDP пакети с нужния дест. порт. Първо с TTL=1, после 2,3 и т.н. В момента в който се окаже че някой не ти връща ICMP TTL exceeded, то пакетът или е достигнал до целта си, или предпоследният (TTL-1) хоп го е издропил. Всичко това при положение че някой малоумник не е хванал да реже ICMP пакетите, които рутира. Защото и такива ненормалници има.

[smelkomar]

Обикновено можеш да REJECT-неш, като върнеш пакета с друг source. Правил съм го за пробата със source gateway-a '>

Иначе аз съм от тези ненормалници, които са резнали целия ICMP '> Параноя, бейбе !

[Hapkoc]

Цитат

Иначе аз съм от тези ненормалници, които са резнали целия ICMP :) Параноя, бейбе !

Гледам си доволен от себе си. Похвално.

[gat3way]

Не искам да ставам като оня Весо дето се кара на "е-простаците", ама това наистина е леко българска работа '>

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

[Ali Nebi]

Мм да наистина е много трудно да се хване нещо такова на UDP, ужас!

[smelkomar]

Цитат (gat3way @ Март 10 2007,17:28)

Не искам да ставам като оня Весо дето се кара на "е-простаците", ама това наистина е леко българска работа '> Кое е толкова страшното на ICMP, заради което го режеш напълно и каква е важната причина да връщаш ICMP съобщения с различен източник, не вярвам да можеш да се аргументираш успешно '>

Официалната версия е, че не правя проблеми на моя доставчик, ако имаш това в предвид. Даже от време на време сам си рестартирам суича, но вече ми писна... '>

Неофициалната сами си я напишете '>

Ако трябва да се аргументирам... ми де да знам, може би заради другите "простаци" (поне 2-ма на съседния суич). Сто пъти са им казали да си проверяват компютрите дали не им окъсяват мрежарките, и сто пъти идват да рестартират суичовете. А средно между две рестартирания има постоянно arp flood

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

[gat3way]

Ма това за домашна употреба ли е? Ааа, така кажи, това оправдава всякакви експерименти '> Този твоят рутер НАТ-ва ли или не? Щото ако само forward-ва е малко кофти...Иначе, идват ми наум отсега няколко потенциални проблема на едно такова решение:

Ако имаш някакъв сайт или ftp услуга или квото и да било, което слухти зад рутера ти, на повечето клиенти с pppoe връзка, които се опитват да го достъпят ще им се случат случки, заради счупено PMTU discovery. Проблемите се задълбочават леко при UDP комуникациите, щото там няма и MSS. Така че например дори ако става въпрос за домашен рутер (не NAT-ващ, само forwarding), тогава ей така заради параноята ще си дърпаш торънтите по-бавно например, а сума ти клиенти, например на megalan, ще има да се чудят как така се връзват с теб, пък почти никакъв трансфер на данни няма '>

Като страничен  ефект, ще превърнеш UDP сканиранията отвън към машина зад рутера в кошмар, ма то тва е хубав страничен ефект де '> Ще строшиш всеки ping или traceroute, изпълнен от машинка зад рутера до навънка (и обратно).  Ще вгорчиш донякъде живота на хората, които ползват nmap зад рутера ти до навън. Ще увеличиш времето, за което някой клиент разбира дали това до което се връзва е филтрирано или не (стига да е филтрирано като хората). Понякога, това е гадно (ако например първият resolver на клиентът ти е сдал багажа, докато се сети да ползва втория ще трябва да чакаш timeout-a)

[smelkomar]

Абе не е точно баш за домашни експерименти...

Той си е pfSense from scratch, но с някои екстри '> Pf-то спира и hping при правилна настройка, tracepath може да си върви ако поискаш. Максималният размер на сегмента не би трябвало да ни бърка - всички адреси (4 на брой) са с MTU-40, поради IPv4. Проблеми с торентите нямам - 1.5~2MB/s dl.

Иначе resolver-ът сдаде ли багажа, си има OpenDNS. При публичен адрес (адреси) това е манна небесна - докато чакаш рестарта на DNS-а на ISP-то ти, вече си отворил сайтовете

Edit: ето ти нещо бързо и лесно за network boot-a '>
http://vamosproject.org/InternetBoot

[gat3way]

Ммм то hping не прави някакви специални фокуси, прави каквото му кажеш в общи линии..

[smelkomar]

Цитат (gat3way @ Март 11 2007,00:11)

Ммм то hping не прави някакви специални фокуси, прави каквото му кажеш в общи линии..

Цитат

Crafting packets will allow you to probe firewall rule-sets and find entry points into the targeted system or network.

Лоша работа мен ако питаш е туй hping, да не говорим какви поразии може да направи със счупени CRC-та (виждал съм firewall, сочен за много стабилен да товари с ~80% процесора, само за да обработи пакетите)