Re: Automaciké rozpojení SSH při nečinnosti (delsi)

Miroslav BENES mbenes na tenez.cz
Pátek Říjen 31 09:19:06 CET 2003


> Pro rozpojeni pri neaktivite tedy slouzi promenna prostredi TMOUT v bashi.

Ooops, ale to mi nepomuze - toto funguje jen pokud je aktivni 
BASH. Ja bych to ale potreboval obecne - mame DB aplikaci s 
omezenym poctem pripojeni, rozsireni je prilis nakladne. Pritom 
uzivatele na tom "visi" cely den (aby se jim nahodou nestalo ze 
se neprihlasi az budou potrebovat) -> spousta pripojeni je 
zbytecnych. A v soucasne dobe nemuzu s tim nic delat (server 
UXWARE, klient DOS).

Protoze ale hodlame prejit na linux, doufal jsem ze to pujde po 
prechodu na linux vyresit na urovni SSH a ze by se dalo nastavit 
"obecne"  odpojovani (v popredi je aplikace a ne BASH !).

Nasel jsem jeste na Google parametry pro TCP (tcp_fin_timeout a 
tcp_keepalive_time v /proc/sys/net/ipv4) - viz 
http://docs.mandragor.org/files/Operating_systems/Linux/Securing_
And_Optimizing_Linux_The_Ultimate_Solution_en/chap6sec75.html, 
ale ani toto mi nechodi a spojeni zustava stale viset.


Poradte prosim jak na to, protoze uz si nevim rady.




P.S. Napadlo me jeste nastavit si z kazde instance aplikace 
casovac "at" a pozadat ho at me za xx minut shodi (neco jako 
watchdog). Problem by ale byl v tom, ze bych se musel opakovane 
starat o to, aby se tato naplanovana akce "preplanovala" na 
jindy (jakmile je stisknuta klavesa) => musel bych upravit 
aplikaci a takove volani dat do vsech mist kde se cte z 
klavesnice, coz je docela silene :(

P.P.S. Nedalo by se neco (o "NEaktivite") vycist z 
/proc/<PID>/stat* ? Jako ze bych si pomoci cron-u zapsal stav, 
po nejake dobe bych ho porovnal s aktualnim a kdyby se nic 
nezmenilo, znamenalo by to ze se aplikace "flaka" a je 
kandidatem na odstrel ..
BTW jak se da zjistit PID bezici aplikace ? V BASH-i je to 
jednoduche ($$) a jak tak koukam ta aplikace (binarka) spoustena 
z BASH-e ma zatim vzdycky jeho PID+1, ale urcite to nebude 
platit na 100% ..

P.P.P.S. Napada me jeste jedna podlstatne vetsi silenost - sel 
by (IMHO teoreticky ano, ale prakticky nevim jak) udelat patch 
do jadra, ktery by v /proc/<PID>/NECO vypisoval cas posledniho 
"pouziti" kernelu (tj. cas posledniho systemoveho volani). 
Predpokladam ze prikaz v aplikaci "READKEY PAUSE 0" (tedy 
neomezene cekani na klavesu) zpusobi jedine volani jadra a tak 
by tedy slo odhalit "kdo na to uz pekne dlouho nehrabnul" -> a 
ve spolupraci s CRON-em by se pak dali vyhledavat kandidati na 
odstrel ..

P.P.P.P.S. Vyse uvedeny napad by IMHO sel udelat i tak ze by se 
aplikace volala pomoci strace a vystup z strace by se 
zpracovaval on-line ... Ale nedokazu si predtavit co by na to 
rikaly CPU a disky (asi by se vsichni dost zapotily a asi celkem 
zbytecne).
Akorat mi neni jasne, jak nastavit strace aby jeho vystup sel do 
roury aniz by o tom vedela aplikace. Vystup do souboru pomoci 
parametru "-o ..." neni moc prakticky, protoze pak se tam toho 
bude zapisovat docela dost.
Krotme toho kdyz jsem toto zkusil, zjistil jsem ze se "divne" 
zpracovavaji klavesy :

Napr. sipka dolu jde dobre (aplikace reaguje jak ma) :

read(0,"\33", 1)                        = 1
read(0, "[", 1)                         = 1
read(0, "B", 1)                         = 1
write(1, "\33[14;3H\33[34;47m L. Expedice     "..., 97) = 97
write(1, "\33[15;3H\33[m\33[1;33;44m M. Evidence"..., 94) = 94
write(1, "\33[13;77H\33[m\33[m ", 15)   = 15
write(1, "\33[14;77H\33[m ", 12)        = 12
write(1, "\33[25;79H", 8)               = 8



(prikazy write prekresluji menu)

.. zatimco napr. klavesa F12 se nezpracuje vubec :

read(0, "\33", 1)                       = 1
read(0, "O", 1)                         = 1
read(0, "[", 1)                         = 1
alarm(1)                                = 0
pause()                                 = ? ERESTARTNOHAND (To 
be restarted)
--- SIGALRM (Alarm clock) ---
rt_sigaction(SIGALRM, {0x8055178, [], 0x4000000}, NULL, 8) = 0
sigreturn()                             = ? (mask now [])


Diky predem za kazdy napad.


--------------------------
Miroslav BENES
E-mail   : mbenes na tenez.cz
TENEZ Chotebor, a.s
--------------------------



Další informace o konferenci Linux