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

Здравейте,

хванах 2 MAC адреса, които ме помпят здраво чрез всевъзможни измислени IP адреси. Опитах се да ги филтрирам чрез следните команди:

/sbin/iptables -A INPUT -m mac --mac-source 00:30:48:67:2c:ad -j DROP
iptables -A INPUT -m mac --mac-source 00:30:48:67:2c:ad -j DROP

И на двете ми извежда следната грешка:

iptables v1.4.8: couldn't load match '--mac-source'': /lib/xtables/libipt_--mac-source.so: cannot open shared object file: no such file or directory

Липсват софтуер предполагам? Как да го фиксна?
Доколкото разбрах първата команда ще запише записа за постоянно, докато при втората ще бъде изчистен при рестарт. Не съм много на ти с iptables.

Благодаря предварително. :)

Това означава, че iptables е компилиран без поддръжка на MAC адреси. Решава се чрез снабдяване с iptables, компилиран с такава поддръжка (инсталиране на подходящ прекомпилиран пакет или ръчно компилиране).
Каква ти е дистрибуцията и откъде се сдоби с такъв iptables?

Абе те като са разбирачи, и постоянно си сменят IP-тата за да правят мискинлъци в мрежата, и MAC адресите ще вземат да си сменят. Ами ти нещо доставчик ли си им ? Или е друга хавата ? Че не си обяснил топологията при вас.

mac се филтрира в таблица 'mangle':

/sbin/iptables -t mangle -A PREROUTING -i eth0 -m mac --mac-source 00:30:48:67:2c:ad -j DROP

за да се запише при рестарт при fedora/centos:

service iptables save

mac се филтрира в таблица 'mangle':

Най-често да, но не само там - такова филтриране може да действа и във filter таблицата.

globaluty, забравих да ти кажа за запазването на правилата след рестарт. teleport вече ти е казал единия вариант. Другият вариант е да си ги опишеш в някой init скрипт (файлът rc.local или собствен скрипт в /etc/init.d). Между двете команди, които ти си показал, няма разлика в резултата от изпълнението - сами по себе си и двете няма да запазят резултата след рестарт. Разликата между двете е само пълният път до командата iptables, който пълен път може да помогне командата iptables да се изпълни, ако директорията /sbin не е описана в променливите на средата (по подразбиране много рядък случай).
И за въпросното помпене от тези адреси. С тези правила в iptables може да ограничиш достъпа им след защитната стена, но не и преди нея. Т.е., ако въпросното помпене води до претоварване на твоя компютър от техните заявки, то тези правила могат да ти помогнат за намаляване на натоварването. Но ако въпросното помпене води до препълване на интернет канала ти, то това ще продължи и при наличието на тези правила, и спасението е в правила при твоя интернет доставчик.

Здравейте,

благодаря за информацията. Наясно съм, че при препълване на канала, филтрирането по MAC няма да свърши работата. Работата е там, че ми правиха трафик общо 10Mbits с по 10 000 пакета на входящия и изходящия трафик (общо 20 000/s). И въпреки това, не успях да осъществя отдалечен достъп до машината. Процесорът работеше едва на 3-5%.
Поради тази причина реших да ги огранича по MAC.

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

По-късно ще пробвам и по начина, по който ми описахте, когато имам достъп.

Наздраве.  [_]3

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

Вариантите са твърде много и е напълно излишно да се описват така на сляпо. За целта трябва да дадеш доста по-подробна информация за системата, настройките и организацията в нея, а все още не си отговорил дори на това каква ти е дистрибуцията и откъде се сдоби с този iptables :) Бъди подробен!

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

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

:) най-много можеш да репортнеш abuse  на адреса който би ти показал who.is за IP-to ... и до там. Няма на кой да се оплачеш, още повече, че повечето "лоши" са от Китай, Тайван, Индия и от сорта.

Аз съм си правил експеримент, да репортвам скрипт кидис, на доставчика им - холандски, румънски, американски, английски, френски провайдери - никой не си мръдна пръста!

Така че - оправяме се сами.

Дистрибуцията е следната: debian-6.0.5-amd64-i386-netinst (Linux debian 2.6.32-5-amd64)

iptables е свален от там, където е зададено по default (apt-get install iptables). Мисля, че от ftp.bg.debian.org, не съм сигурен.

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

Написах същата команда на виртуална машина на моя комп. и нито грешка се появи, нито интернетът е спрял. За виртуалната машина съм използвал абсолютно същия линукс.

Казвайте с каква информация мога да помагам още.

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

Ти сигурен ли си че този MAC адрес не е на някой от интерефейсите на твоята машина, или на доставчика?
Щото ако това е адреса на флуудера то значи той ти е в broadcast domain-a и няма начин да няма начин да не можеш да го уловиш кой е и да му скъсаш ушите.

Цитат на: globaluty в Jan 23, 2013, 14:08

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

Ти сигурен ли си че този MAC адрес не е на някой от интерефейсите на твоята машина?
Щото ако това е адреса на флуудера то значи той ти е в broadcast domain-a и няма начин да няма начин да не можеш да го уловиш кой е и да му скъсаш ушите.

Мда, туко-що и аз установих същото. Няколко реда от лога:

Tue Jan 22 22:06:01 2013; ICMP; eth0; 57 bytes; source MAC address bc5ff42bce36; from 95.111.44.34 to 149.37.243.220; dest unrch (port)
Tue Jan 22 22:06:01 2013; UDP; eth0; 46 bytes; source MAC address 003048672cad; from 185.206.172.6:60096 to 95.111.44.34:www
Tue Jan 22 22:06:01 2013; ICMP; eth0; 57 bytes; source MAC address bc5ff42bce36; from 95.111.44.34 to 185.206.172.6; dest unrch (port)
Tue Jan 22 22:06:01 2013; UDP; eth0; 46 bytes; source MAC address 003048672cad; from 9.179.144.101:60101 to 95.111.44.34:www
Tue Jan 22 22:06:01 2013; ICMP; eth0; 57 bytes; source MAC address bc5ff42bce36; from 95.111.44.34 to 9.179.144.101; dest unrch (port)
Tue Jan 22 22:06:01 2013; UDP; eth0; 46 bytes; source MAC address 003048672cad; from 165.187.108.159:60105 to 95.111.44.34:www
Tue Jan 22 22:06:01 2013; ICMP; eth0; 57 bytes; source MAC address bc5ff42bce36; from 95.111.44.34 to 165.187.108.159; dest unrch (port)

bc5ff42bce36 - на моята машина
003048672cad - на суича ?

Вероятно зададените IP адреси са фалшиви, чуждестранни. Няма как да получавам пакети от чуждестранни IP адреси, след като международният ми канал е спрян и имам само BG Peering.

Тя идиотщината става пълна. И наистина е така, никой доставчик не иска да си мръдне и пръстта за юзера.

Доставчика се пресова по известните начини - 1) Аз сега ще пусна с моите приятели една контраатака срещу тия дето ме тормозят след като вие не вземате мерки, само дето вашия целия канал нищо чудно да клекне и да оставите всичките си клиенти без нет. И 2) Или ще взема да ви сменя като доставчик и да ви направя "реклама" сред клиентите. Ще обмисля дали така докато си спретвам контраатаката. Вие също ще си помислите, нали? Ще си сътрудничим, или ще си пречим?

Тия дето ще ги филтрираш по MAC са в твоята LAN, нали? Или са някъде в Интернет?

Бях се заблудил с MAC адреса, така че той отпада.

Вече кой ден чакам същият въпросен доставчик да ми обясни какво разбира под филтрация на международния канал, а в същото време те самите отчитат реален международен трафик.  ;D