Re: lug-bg: ip_conntrack dropping packet
On Saturday 11 June 2005 21:02, George Danchev wrote: > [1] http://www.wallfire.org/misc/netfilter_conntrack_perf.txt > / ако искаш да налагаш ограничения / Благодаря. Този документ изчерпва напълно въпроса ми. Сега остава да видим резултатите от експериментите;) -- Nikola ANTONOV, Linux for Bulgarians -- Public GnuPG key at http://wwwkeys.pgp.net ftp://ftp.logos-bg.net/pub/Linux-BG.org/GPG_Keys/ Fingerprint: AD64 2468 0AB4 B298 E7E3 92DA 15F5 7AC5 A05E 0F63 -- pgpcrygmcLer9.pgp Description: PGP signature
Re: lug-bg: zor sas SQUID {to Evgeni Genchev}
On Sunday 12 June 2005 01:52, Evgeni Gechev wrote: > ggg wrote: > >aa tui dobre ama az imam oshte procesi deto sa > >sobstvennost na nobody i imat trrafik (apacha naprimer > >- toi ima paketi ot vsi4ki GWs kum i ot nego) kakvo > >shte stane s tiah ? > > > >g. > > > >>Ðко squid-а е Ñ > >>натройките по > >>подразбиране (user nobody): > >>iptables -t mangle -A OUTPUT -m owner --uid-owner > >>nobody -j MARK > >>--set-mark 0x01 > >>ip r a via GW3 t 253 > >>ip ru a from tcp_outgoing_address_NA_SQUIDA fwmark > >>0x01 t 253 > > > >__ > >Yahoo! Mail > >Stay connected, organized, and protected. Take the tour: > >http://tour.mail.yahoo.com/mailtour.html > > Ми смени user-а на squid-а с друг де, и за това ли > искаш пример?:) А не може ли просто да напишеш : ip ru add from $ip t 100 ip r a default via $gw t 100 като $ip ти е ип-то за към ADSL а $gw ти е самия ADSL без да маркираш пакети и да драскаш допълнителни tables отделно ако искаш по тоя начин можеш да си пуснеш и допълнителни услуги на тва IP след като каките от БТК ти FORWARD необходимите портове. -- =+==+==+==+==+==+==+==+==+==+==+==+= Dragomir Zhelev Network Administrator & IT Support Varna,Bulgaria [EMAIL PROTECTED] =+==+==+==+==+==+==+==+==+==+==+==+=
lug-bg: Един ping, source routing и два SNAT-а.
Здравейте, след много ровене из google, малко питане и безсмислени и безрезултатни проби стигнах до тук. Имам следната ситуация: eth0 - local net (192.168.0.x) eth1 - ISP1 eth2 - ISP2 И на eth1 и на eth2 има пуснат SNAT: >> Chain POSTROUTING (policy ACCEPT 223K packets, 19M bytes) >> pkts bytes target prot opt in out source destination >> 188K 12M SNAT all -- anyeth1anywhere anywhereto:85.x.x.x >> 823 50110 SNAT all -- anyeth3anywhere anywhereto:10.0.0.51 На практика IPS2 не се използва изобщо. Всичко минава през IPS1. В определени моменти искам да прекарам един и точно един хост от локалната мрежа да ползва ISP2. За целта използвам policy routing: ip rule add from 192.168.0.7 table viphost ip route add default via 10.0.0.1 table vipohost ip route flush cache Всичко изглежда нормално, нали? Но това се случва в реално време и всички работещи сесии от машината 192.168.0.7 започват да излизат от eth2. Особеното е, че те излизат през eth2 SNAT-нати ___със IP адреса на eth1___. Това първоначално ме шокира. В последствие си го обясних с факта, че ядрото естествено следи сесиите и не може просто така да ги промени. След като въпросните сесии умрат, всички нови дошли на тяхно място излизат правилно. Това се отнася като цяло за всички нови сесии. Проблемът идва в това, че от 192.168.0.7 работи пинг към yahoo.com например, постоянно. След като пренасоча 192.168.0.7 през eth2 пингът продължава да излиза с адреса на eth1. Спирам го, пускам го, но той продължава да излиза грешно. Едва когато го спра за дълго време, например 10мин., всичко тръгва коректно. А когато пусна пинг към друг хост _след_ прехвърлянето проблеми нямам. Има ли някакъв начин да рестартирам всичко, което ядрото помни за даден хост, защото освен проблемите с пинга може да има и други, които аз не съм хванал все още.
Re: lug-bg: ps ax|grep sth
On Fri, Jun 10, 2005 at 11:27:35AM +0300, Ivan Ralenekov wrote: > Здравейте, > > Имам един въпрос: защо на едната дистрибуция се получава така, че > "grep"-a хваща и себе си като процес а на другата не? Проблемът е във > версията на grep или трябва някаква донастройка? По принцип това зависи от много неща - от това колко бързо се изпълнява процесът ps и дали шелът изобщо *успява* да пусне grep, преди ps да е завършил, през купчина други възможни причини, та чак до начина, по който работи scheduler-ът в ядрото. В крайна сметка се оказва, че дори и с трикове от сорта на egrep '[p]rocess' не е много ясно дали винаги ще се получи това, което искаш. Друга причина да не е ясно дали ще се получи това, което искаш, е, че с ps | grep на практика винаги има опасност от false positives - други процеси, които много, ама много приличат на това, което търсиш, ама не са точно това, или просто други процеси, абсолютно несвързани с това, което търсиш, които просто съдържат низа, който търсиш, в името на програмата или като параметър. Има няколко начина да се справиш с това: 1. Пак ps, но доста да стесниш обхвата на търсенето, като например му кажеш да показва само process ID-то и името на командата, която се изпълнява - без параметри, без потребителско име, без нищо друго. Под FreeBSD и с повечето Linux-ки реализации на ps(1) това става с 'ps axco pid,command' - като всъщност важната опция е 'o pid,command'. Следващата стъпка е да обясниш на grep да търси *точно* това, което ти трябва, а не всичко, което съдържа това, което ти трябва, като някаква част от името, например нещо като ps axco pid,command | egrep ' mozilla-bin$' или дори ps axco pid,command | awk '$2 == "mozilla-bin" {print $1}' 2. Една малка програмка, която се казва 'pidof', и обикновено е част от пакет с името sysvinit или, ако не, то нещо като pstools, psmisc или нещо такова. Тя ще ти даде само process ID-тата на всички процеси, името на които съвпада *точно* с параметъра, който й подаваш, така че на практика прави същото като последните две ps|egrep и ps|awk команди, само че по-бързо и по-лесно - и дори е малко по-portable :) 3. Най-правилният начин: намери някакъв начин да обясниш на процеса, който търсиш, че ще е много добра идея той *сам* да си записва process ID-то някъде, или намери някакъв друг начин да го контролираш, да го пускаш и спираш с някакво инструментче, което следи и помни и знае process ID-тата на наследниците си. За първия вариант - повечето daemons имат възможност да стане с нещо като си записват process ID-тата във файл, чието име ти си избираш да им укажеш на командния ред. За втория - имам предвид нещо като пакета daemontools и програмката supervise в него, която пуска един процес, който *не* преминава във фонов режим, и след това можеш да подаваш на supervise команди за това какво точно да прави с пуснатия и следен от нея процес. Много програми се поддават на такова отношение - на практика е достатъчно да можеш да им обясниш, че не трябва да преминават във фонов режим; sshd -D, squid -N, fetchmail -b, ntpd -n и т.н. Тогава имаш наистина ясен и сигурен начин да пращаш сигналчета точно и само на този процес, който те интересува. Поздрави, Петър -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If there were no counterfactuals, this sentence would not have been paradoxical. pgpVbh0P7prGH.pgp Description: PGP signature
Re: lug-bg: ps ax|grep sth
On Sunday 12 June 2005 16:58, Peter Pentchev wrote: > On Fri, Jun 10, 2005 at 11:27:35AM +0300, Ivan Ralenekov wrote: > > Здравейте, Драсти, /* нарочно не съм рязал щото това е като за учебник и e archive-friendly */ > > Имам един въпрос: защо на едната дистрибуция се получава така, че > > "grep"-a хваща и себе си като процес а на другата не? Проблемът е във > > версията на grep или трябва някаква донастройка? > > По принцип това зависи от много неща - от това колко бързо се изпълнява > процесът ps и дали шелът изобщо *успява* да пусне grep, преди ps да е > завършил, през купчина други възможни причини, та чак до начина, по > който работи scheduler-ът в ядрото. В крайна сметка се оказва, че дори > и с трикове от сорта на egrep '[p]rocess' не е много ясно дали винаги ще > се получи това, което искаш. > > Друга причина да не е ясно дали ще се получи това, което искаш, е, че с > ps | grep на практика винаги има опасност от false positives - други > процеси, които много, ама много приличат на това, което търсиш, ама не > са точно това, или просто други процеси, абсолютно несвързани с това, > което търсиш, които просто съдържат низа, който търсиш, в името на > програмата или като параметър. Има няколко начина да се справиш с това: > > 1. Пак ps, но доста да стесниш обхвата на търсенето, като например му > кажеш да показва само process ID-то и името на командата, която се > изпълнява - без параметри, без потребителско име, без нищо друго. Под > FreeBSD и с повечето Linux-ки реализации на ps(1) това става с 'ps axco > pid,command' - като всъщност важната опция е 'o pid,command'. > Следващата стъпка е да обясниш на grep да търси *точно* това, което ти > трябва, а не всичко, което съдържа това, което ти трябва, като някаква > част от името, например нещо като > ps axco pid,command | egrep ' mozilla-bin$' > или дори > ps axco pid,command | awk '$2 == "mozilla-bin" {print $1}' <допълнение, в случай, че с awk се почувства power disturbance Ако ще се филтрува изхода на ps --options може да се вземе и примерното решение дадено като psgrep от Perl Cookbook / Глава 1, Низове, Програмата: psgrep / достъпен на (и много други работи са достъпни от там): http://pleac.sourceforge.net/include/perl/ch01/psgrep http://examples.oreilly.com/perlckbk2/ т.е. може да се правят всевъзможни сечения и/или обединения по всички полета от изхода на ps (FLAGS UID PID PPID PRI NICE SIZE RSS WCHAN STAT TTY TIME COMMAND) и програмката може да бъде "дописвана on-the-fly", например мачваме дума, двоеточие, интервал, дума, интервал, цифра от COMMAND полето с PID > 1000 за всички простосмъртни: ./psgrep 'command =~ m/\w+:(\s+\w+)\s*\d+/' 'pid > 1000 && uid != 1' и излавяме kdeinit: kio_pop3 pop3 /tmp/ksocket. накратко: нашите заявки се оценяват през: eval "sub is_desirable { наша заявка } " . 1 ; в книгата има други примери, този незнам доколко е смислен де, разбира се може да се променя и сорса ако изхода на ps не ни устройва нещо /> > 2. Една малка програмка, която се казва 'pidof', и обикновено е част от > пакет с името sysvinit или, ако не, то нещо като pstools, psmisc или > нещо такова. Тя ще ти даде само process ID-тата на всички процеси, > името на които съвпада *точно* с параметъра, който й подаваш, така че на > практика прави същото като последните две ps|egrep и ps|awk команди, > само че по-бързо и по-лесно - и дори е малко по-portable :) > > 3. Най-правилният начин: намери някакъв начин да обясниш на процеса, > който търсиш, че ще е много добра идея той *сам* да си записва process > ID-то някъде, или намери някакъв друг начин да го контролираш, да го > пускаш и спираш с някакво инструментче, което следи и помни и знае > process ID-тата на наследниците си. За първия вариант - повечето > daemons имат възможност да стане с нещо като си записват process ID-тата > във файл, чието име ти си избираш да им укажеш на командния ред. За > втория - имам предвид нещо като пакета daemontools и програмката > supervise в него, която пуска един процес, който *не* преминава във > фонов режим, и след това можеш да подаваш на supervise команди за това > какво точно да прави с пуснатия и следен от нея процес. Много програми > се поддават на такова отношение - на практика е достатъчно да можеш да > им обясниш, че не трябва да преминават във фонов режим; sshd -D, squid > -N, fetchmail -b, ntpd -n и т.н. Тогава имаш наистина ясен и сигурен > начин да пращаш сигналчета точно и само на този процес, който те > интересува. Понеже можа да се окаже трудно да се влияе на всевъзможни приложения по този начин може да се пита и ядрото от /proc/ обхождайки го за число/[stat|exe| cmdline|...] / разбира се за kernel threads exe ще е празно, за това по-добре да се гледа stat за pid (thread) / защото ps и pidof от там вземат тази инфо. Според мен това е най-сигурно защото ядрото най-добре пази и знае и абсолютен път, и работна директория и т.н. странни неща. -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint1AE7 7C66 0A26 5
lug-bg: treason unloacked
Здравейте отново, Става дума Apache 2.0.54 (Debian 3.1 Sarge). Машината е P4 2.8Ghz, 2GB RAM. От известно време насам имам проблем с уебсървър, който хоства популярен сайт. Няколко пъти в рамките на две-три седмици се случва да заваря apache неработещ. Последното съобщение, записано в журнала, е: caught SIGTERM, shutting down Понеже не за първи път ми се случва тази машина да е обект на DoS, започнах да търся подозрителни съобщения. Във /var/log/kernel.log се натъкнах на доста интензивна поредица съобщения от типа: kernel: TCP: Treason uncloaked! Peer xx.xx.xx.xx:32875/80 shrinks window 3845616564:38456193 24. Repaired. IP-то не съм показал. Става дума за хост в чужбина, който нищо не ми говори. Не е задължително това да има нещо общо с авариите на apache (възможно е да е DoS, но е възможно съвсем несъзнателно да изпраща лоши пакети). Спецовете по сигурността могат да си кажат думата, ако представлява интерес за тях. Както и да е. Накрая реших да отрежа този хост като подозрителен на ниво firewall. Интересното е, че въпреки невъзможността да достъпи 80 порт, продължава да бълва същите заявки до 80 порт (около 7-8 на минута, но с непостоянна честота). Заявките се блокират с iptables и сега вече пълнят други логове:) Интересува ме някой знае ли нещо повече за съобщението "kernel: TCP: Treason uncloaked!" и ако това е причина за периодичния срив на apache, има ли начин да се предотврати, без да се стига до блокиране на хостове с netfilter? -- Nikola ANTONOV, Linux for Bulgarians -- Public GnuPG key at http://wwwkeys.pgp.net ftp://ftp.logos-bg.net/pub/Linux-BG.org/GPG_Keys/ Fingerprint: AD64 2468 0AB4 B298 E7E3 92DA 15F5 7AC5 A05E 0F63 -- pgpGeVtuDQnT9.pgp Description: PGP signature
Re: lug-bg: POSTGRES "truncate all"
Daniel Ivanov wrote: > Изникна един въпрос. След като инкрементиран ъпдейт не е решение за една > база, защото старите данни са модифицирани до неузнаваемост ми се иска > да знам дали има лесен начин за TRUNCATE на всяка таблица в дадена схема. Има. #!/bin/sh PGHOST="db" PGDATABASE="test" PGUSER="user" PGPASSWORD="pass" export PGHOST PGDATABASE PGUSER PGPASSWORD PATH="/usr/bin:/usr/local/bin:/usr/local/pgsql/bin" PSQL=`which psql` tables=`$PSQL -t $PGDATABASE -c "SELECT DISTINCT c.oid::pg_catalog.regclass FROM pg_catalog.pg_index x JOIN pg_catalog.pg_class c ON c.oid = x.indrelid JOIN pg_catalog.pg_namespace n ON c.relnamespace = n.oid WHERE nspname NOT LIKE 'pg_%'"` IFS=' ' for table in $tables; do $PSQL $PGDATABASE -c "TRUNCATE $table" done -- Georgi Chorbadzhiyski http://georgi.unixsol.org/
Re: lug-bg: POSTGRES "truncate all"
Става. Но си го написах на перлата. Georgi Chorbadzhiyski wrote: Daniel Ivanov wrote: Изникна един въпрос. След като инкрементиран ъпдейт не е решение за една база, защото старите данни са модифицирани до неузнаваемост ми се иска да знам дали има лесен начин за TRUNCATE на всяка таблица в дадена схема. Има. #!/bin/sh PGHOST="db" PGDATABASE="test" PGUSER="user" PGPASSWORD="pass" export PGHOST PGDATABASE PGUSER PGPASSWORD PATH="/usr/bin:/usr/local/bin:/usr/local/pgsql/bin" PSQL=`which psql` tables=`$PSQL -t $PGDATABASE -c "SELECT DISTINCT c.oid::pg_catalog.regclass FROM pg_catalog.pg_index x JOIN pg_catalog.pg_class c ON c.oid = x.indrelid JOIN pg_catalog.pg_namespace n ON c.relnamespace = n.oid WHERE nspname NOT LIKE 'pg_%'"` IFS=' ' for table in $tables; do $PSQL $PGDATABASE -c "TRUNCATE $table" done
Re: lug-bg: Един ping, source routing и два SNAT-а.
Да, най-болезнено става с "изваждането на ip_conntrack модула от ядрото и слагането му обратно". Предполагам знаеш, че това подлежи на dependencies - ipt_MASQUERADE, iptable_nat, ipt_state трябва да са вън от кернела също. Това обаче е много болезнено по простите 2 причино - първо трябва да махне всичките stateful правила от firewall-a и после трябва да сложи или DROP, или REJECT полици на филтер таблцита. Един cheat за който се сещам е просто да пратиш по един RST пакет на връзките в conntrack-a и да очакваш, че от сега нататък всичко ще излиза през новия гейт :) Трети, но доста труден вариант е да се поровиш в нетфилтер листите, където видях методи за манипулация на conntrack таблицата и триене на записи. Rossen Antonov wrote: Здравейте, след много ровене из google, малко питане и безсмислени и безрезултатни проби стигнах до тук. Имам следната ситуация: eth0 - local net (192.168.0.x) eth1 - ISP1 eth2 - ISP2 И на eth1 и на eth2 има пуснат SNAT: >> Chain POSTROUTING (policy ACCEPT 223K packets, 19M bytes) >> pkts bytes target prot opt in out source destination >> 188K 12M SNAT all -- anyeth1anywhere anywhereto:85.x.x.x >> 823 50110 SNAT all -- anyeth3anywhere anywhereto:10.0.0.51 На практика IPS2 не се използва изобщо. Всичко минава през IPS1. В определени моменти искам да прекарам един и точно един хост от локалната мрежа да ползва ISP2. За целта използвам policy routing: ip rule add from 192.168.0.7 table viphost ip route add default via 10.0.0.1 table vipohost ip route flush cache Всичко изглежда нормално, нали? Но това се случва в реално време и всички работещи сесии от машината 192.168.0.7 започват да излизат от eth2. Особеното е, че те излизат през eth2 SNAT-нати ___със IP адреса на eth1___. Това първоначално ме шокира. В последствие си го обясних с факта, че ядрото естествено следи сесиите и не може просто така да ги промени. След като въпросните сесии умрат, всички нови дошли на тяхно място излизат правилно. Това се отнася като цяло за всички нови сесии. Проблемът идва в това, че от 192.168.0.7 работи пинг към yahoo.com например, постоянно. След като пренасоча 192.168.0.7 през eth2 пингът продължава да излиза с адреса на eth1. Спирам го, пускам го, но той продължава да излиза грешно. Едва когато го спра за дълго време, например 10мин., всичко тръгва коректно. А когато пусна пинг към друг хост _след_ прехвърлянето проблеми нямам. Има ли някакъв начин да рестартирам всичко, което ядрото помни за даден хост, защото освен проблемите с пинга може да има и други, които аз не съм хванал все още.