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мин., всичко тръгва коректно. А когато пусна пинг към друг хост _след_ прехвърлянето проблеми нямам. Има ли някакъв начин да рестартирам всичко, което ядрото помни за даден хост, защото освен проблемите с пинга може да има и други, които аз не съм хванал все още.
