Изпечатай

[PAIN1]

Заменете Н с някое 3 или 4 цифрено число и ще получите какъв ерор получавам.
Ситуацията е следната, за пръв път ми се случва.
В един момент забелязвам че компютъра е доста натоварен(почти напълно)
и плюе тези грешки една след друга, а в същото време се генерират около
2.5мб вход и 2.5мб изход към eth0 (което е локалната мрежа).
Предположих аз , някой ме флооди .... ама не мога да разбера кой, жалко.
Разрових се в интернет, нямаше много полезни резултати. Пише, че когато
 компютъра работи като сървар продължително време натрупва много кеш или някаква информация, не разбрах точно и алтернативата е да се вдигне лимита в /proc/sys/net/ipv4/neigh/default/gc_thresh1
/proc/sys/net/ipv4/neigh/default/gc_thresh2
/proc/sys/net/ipv4/neigh/default/gc_thresh3,
Наистина ли е това или някой наистина ми прави проблеми. В смисъл къде да търся проблема ?
Слак 10.2
Кернел 2.6.16
Мерси.

[VladSun]

Аз имам спец. скрипт за настройване на нет параметрите:

Примерен код

echo 0 > /proc/sys/net/ipv4/conf/eth0/proxy_arp echo 0 > /proc/sys/net/ipv4/conf/eth1/proxy_arp echo 0 > /proc/sys/net/ipv4/conf/all/proxy_arp echo 0 > /proc/sys/net/ipv4/conf/default/proxy_arp echo 0 > /proc/sys/net/ipv4/conf/eth0/accept_source_route echo 0 > /proc/sys/net/ipv4/conf/eth1/accept_source_route echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route echo 0 > /proc/sys/net/ipv4/conf/default/accept_source_route echo 1 > /proc/sys/net/ipv4/conf/eth0/secure_redirects echo 1 > /proc/sys/net/ipv4/conf/eth1/secure_redirects echo 1 > /proc/sys/net/ipv4/conf/all/secure_redirects echo 1 > /proc/sys/net/ipv4/conf/default/secure_redirects echo 0 > /proc/sys/net/ipv4/conf/eth0/accept_redirects echo 0 > /proc/sys/net/ipv4/conf/eth1/accept_redirects echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects echo 0 > /proc/sys/net/ipv4/conf/default/accept_redirects echo 1 > /proc/sys/net/ipv4/conf/eth0/rp_filter echo 1 > /proc/sys/net/ipv4/conf/eth1/rp_filter echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter echo 1 > /proc/sys/net/ipv4/conf/default/rp_filter echo 0 > /proc/sys/net/ipv4/conf/eth1/log_martians echo 0 > /proc/sys/net/ipv4/conf/eth0/log_martians echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts echo 16777216 > /proc/sys/net/core/rmem_max echo 16777216 > /proc/sys/net/core/wmem_max echo 4096 65536 16777216 > /proc/sys/net/ipv4/tcp_wmem echo 4096 87380 16777216 > /proc/sys/net/ipv4/tcp_rmem echo 262144 > /proc/sys/net/ipv4/route/max_size echo 262144 > /proc/sys/net/ipv4/ip_conntrack_max echo 1 > /proc/sys/net/ipv4/tcp_no_metrics_save echo 2500 > /proc/sys/net/core/netdev_max_backlog echo 1024 > /proc/sys/net/ipv4/neigh/default/gc_thresh1 echo 2048 > /proc/sys/net/ipv4/neigh/default/gc_thresh2 echo 4096 > /proc/sys/net/ipv4/neigh/default/gc_thresh3

Събирал съм ги от много места, та... не ме карай да ти обяснявам ред по ред '>

[PAIN1]

Там е работата, че като дропнах всички пакети през този интерфейс този трафик спря. Някой ме флооди, но не мога да разбера как и къде в смисъл порт ...... Как предизвиква такъв ерор и къде да търся кой е ?

[Hapkoc]

Нищо не ти пречи да пуснеш логване на пакетите от iptables:

-A INPUT ... -j LOG "Some prefix: "

Само внимателно, че покрай атаката може да ти свърши мястото на диска. :)

[KPETEH]

Я вкарай тези редове в скрипта на стената :

Примерен код

iptables -N flood iptables -A INPUT -p tcp --syn -j flood iptables -A flood -m limit --limit 1/s --limit-burst 3 -j RETURN iptables -A flood -j DROP

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

[gat3way]

Значи проблемът е ясен - препълва ти се ARP таблицата. Очевидно или се намираш в голям етернет сегмент, или се намираш в етернет сегмент, където много (?) често интерфейсите взимат различен IP адрес, или някой идиот съвсем нарочно го прави - безкрайно лесно е да си напишеш един скрипт, който вдига интерфейса с различен phys/network адрес и ходиш да arping-ваш с новият си адрес "жертвата" докато му напълниш ARP кеша.

Принципно някъде беше написано - в kernelspace не се реализират големи ARP таблици, така или иначе non-pageable паметта е ценна. Има вариант с user-space ARP демон, който никога не съм пробвал и не знам доколко е решение.Ако някой го е правил може да каже повече.

Бързо подобрение на ситуацията - първо намали стойността на gc_interval, което е максималното време между две "зачиствания" на стари ARP записи в таблицата.

Второ, вдигането на gc_thresh1 не е вариант, когато проблемът се дължи на нечия малоумна шега. Накратко, gc_thresh2 е броят арп записа, при който задължително минава garbage collection механизъма за изхвърляне на "стари" стойности. Когато броят записи падне под gc_thresh1, тогава процесът на "изхвърляне" се прекратява. В момента в който това става, машината малко или много се товари да го прави постоянно.

Ако проблемът наистина се дължи на атака, това може до голяма степен да се разбере по това, което ти е в АРП таблицата - ако не можеш да си комуникираш с повечето хостове вътре в нея, значи е съмнителна работата.

Ако това се дължи на атака, нещата не се решават много ефективно с ръчкане на procfs entries. Единият вариянт е да си създадеш статични (permament) АРП ентрита за хостовете, с които искаш да си комуникираш - така никога няма да имаш проблем, поне с комуникацията с тях. Другият вариант: разиграваш се с iptables  mac match-a или с arptables и набиваш ръчно правила с кои двоики ИП-МАК адреси да си комуникираш и с кои-не. В последният случай въобще няма да ти дреме за такива атаки, но пък е и неудобен, защото ако ти трябва да си говориш с повече хостове или пък им се назначават динамично адреси от някакъв pool, нещата загрозняват.

Препълването на АРП таблицата е лошо нещо, води до невъзможност в частни случаи да комуникираш с хостове от твоят етернет сегмент. Garbage collection-a на "стари" ентрита от таблицата пък както си забелязал, тормози машината.

[PAIN1]

Мерси за подробните обяснения.

Тоест ако е така, то програмата която използва сменя мак адресите и пинква постоянно ?
Там е работата, че опитах да логвам дропнатите пакети(предварително си аксептвам няколко тръстед аипита , защото наистина съм в голяма мрежа), но syslog-a ми стои празен

Примерен код

iptables -N LOGDROP iptables -A LOGDROP -j LOG iptables -A LOGDROP -j DROP iptables -A INPUT -j LOGDROP

И все пак, ако е атака, искам да видя от къде идва?

[VladSun]

Пусни си един tcpdump в момента на атаката :

Примерен код

tcpdump -nq -iethX arp

като замениш ethX с вътрешната ти карта (преполагам, че от там идва атаката)

[Gaara]

Цитат (VladSun @ Март 19 2007,22:47)

Аз имам спец. скрипт за настройване на нет параметрите: Примерен код echo 16777216 > /proc/sys/net/core/rmem_max echo 16777216 > /proc/sys/net/core/wmem_max echo 4096 65536 16777216 > /proc/sys/net/ipv4/tcp_wmem echo 4096 87380 16777216 > /proc/sys/net/ipv4/tcp_rmem echo 262144 > /proc/sys/net/ipv4/route/max_size echo 262144 > /proc/sys/net/ipv4/ip_conntrack_max echo 1 > /proc/sys/net/ipv4/tcp_no_metrics_save echo 2500 > /proc/sys/net/core/netdev_max_backlog echo 1024 > /proc/sys/net/ipv4/neigh/default/gc_thresh1 echo 2048 > /proc/sys/net/ipv4/neigh/default/gc_thresh2 echo 4096 > /proc/sys/net/ipv4/neigh/default/gc_thresh3 Събирал съм ги от много места, та... не ме карай да ти обяснявам ред по ред '>

VladSun, може ли малко пояснение по тези редове. Ако правилно съм разбрал това е някакъв вид tunning:
/proc/sys/net/core/rmem_max - максимално получен tcp window
/proc/sys/net/core/wmem_max - максимално изпратен tcp window
като им задаваш стойност, която зависи от интернет връзката и пропускателна способност (16mbit). Прочетох малко, нищо почти не разбрах, но се казва, че не е хубаво и да се пипат tcp_rmem (запазена памет за tcp буфера за получаване) и tcp_wmem (за изпращане), а ти задаваш точно определени стойности (4kbit 64kbit 16mbit). Също така видях, че трябва да се зададе и 0 на tcp_timestamps. Може ли малко пояснение, че ми грабна интереса?

[VladSun]

Дадох съдържанието на скрипт писан преди 3 години ... честно казано не помня кой знае какво за него - имам спомени, че съм го писал по документи намерени от google за "tcp tune linux", но не съм 100% сигурен. Съжалявам, че не мога да помогна '>