Dotaz: security na fbsd

[PanZvedavy]

Mel bych dotaz ohledne logovani udalosti ve fbsd. Posledni dobou zaznamenavam cim dal vic utoku na sshd a pri procitani logu me zarazila jedna vec...vlastne hned nekolik. Nechavam si posilat pravidelne vypisy na mail z periodic, jenz uvadeji udaje, ktere v auth.log nejsou, jako napr. neuspesne prihlaseni se spatnym heslem apod. Jednoduse mam v mailu vypisy o neuspesnem prihlaseni skrze sshd a v auth.log ani ň. A druha vec co me vrta hlavou je hlaska: Oct 1 19:15:41 xyz lock: 1 ROOT UNLOCK FAILURE (/dev/ttyp0 on xyz) Oct 1 19:15:42 xyz lock: 2 ROOT UNLOCK FAILURES (/dev/ttyp0 on xyz) Oct 1 19:15:44 xyz lock: 3 ROOT UNLOCK FAILURES (/dev/ttyp0 on xyz) Oct 1 19:15:45 xyz lock: 4 ROOT UNLOCK FAILURES (/dev/ttyp0 on xyz) Oct 1 19:15:46 xyz lock: 5 ROOT UNLOCK FAILURES (/dev/ttyp0 on xyz) ..opet pouze vypis v periodic...auth.log nebo messegas mlci. Takze kde je problem?

Odpovědi

[cronin]

Len pre lepsiu citatelnost:

A druha vec co me vrta hlavou je hlaska:

Oct 1 19:15:41 xyz lock: 1 ROOT UNLOCK FAILURE (/dev/ttyp0 on xyz)
Oct 1 19:15:42 xyz lock: 2 ROOT UNLOCK FAILURES (/dev/ttyp0 on xyz)
Oct 1 19:15:44 xyz lock: 3 ROOT UNLOCK FAILURES (/dev/ttyp0 on xyz)
Oct 1 19:15:45 xyz lock: 4 ROOT UNLOCK FAILURES (/dev/ttyp0 on xyz)
Oct 1 19:15:46 xyz lock: 5 ROOT UNLOCK FAILURES (/dev/ttyp0 on xyz)

..opet pouze vypis v periodic...auth.log nebo messegas mlci. Takze kde je problem?

[Jaroslav Klaus]

Vyhoda opensource tkvi v tom, ze jsou k dispozici zdrojaky, takze si muzes zjistit, jak co funguje.

Neni tedy problem mrknout se do periodic/security a zjistit, kdo generuje retezec "login failures", ktery je pred kazdym takovym vypisem (800.loginfail).

Rekl bych, ze prinejmensim mirne pokrocily administrator (dost mozna i zacatecnik) by dokazal vycist, ze se zpracovava nejen auth.log, ale i jeho starsi ("archivni") verze auth.log.*

A jelikoz se skript zajima jen o zaznamy z predchoziho dne (yesterday=`date -v-1d "+%b %e "`) a rotace logu je zajistena na zaklade velikosti logu (newsyslog.conf: /var/log/auth.log 600 7 100 * JC), tak je dost mozne, ze zaznamy, ktere ma root v mailu, jsou jiz odrotovany v nekterem z "archivnich" logu (auth.log.*)

[PanZvedavy]

dekuji za reakci. To co uvadite je pravda a dokonce jsem se do skritpu co vola periodic zhruba dival:)...nicmene u me je nastavene rotovani logu dle jejich velikosti tj. 5 MB resp. 50 MB coz auth.log nema ani zdaleka. Tedy vase domenka-pointa zde nebude resenim meho problemu.

[Jaroslav Klaus]

Aha. Co tedy vrati

# zcat /var/log/auth.log.*.gz | grep -i fail

[PanZvedavy]

nevrati nic, protoze existuje jen aktualni /var/log/auth.log. Rotace vzhledem k nastavene velikosti jeste neprobehla. Porad to tlacite smerem...dotazujici-se bude nejspis lamka se zmatkem v rotovani logu. No nejspis tak trochu lamka budu, kdyz nedovedu zadat regurerni vyraz do googlu tak, aby vyhodil nejake adekvatni info. Asi zkusim fbsd mailinglist. V kazdem pripade dik za snahu.

[Jaroslav Klaus]

Nechtel jsem se vas dotknout, ale prijde mi dost divne, ze jednou v auth.log ten retezec skript (800.loginfail) najde a podruhe ne (byt ten grep se zadava rucne).

1. budto se zmenila data v auth.log a pak je otazka proc (nastavenou velkou velikost pro rotaci nemuzu brat za dukaz, ze rotace neprobehla - bylo by lepsi overit, ze log obsahuje zaznamy i pred incidentem)

2. nebo ten mail s auditem nebyl uplne koser (a pak bych se zajimal, kde se vzal)

Kazdopadne by me zajimal vysledek, pokud nejaky bude.

[JMP]

nebo tam je uz "nezvany spravce" a auth.log je upraveny... (cron to mohl stihnout odeslat pred upravou)

[PanZvedavy]

ono se jedna o pomerne sofistikovany a presne mireny utok. Nekdo si me musel vyhledat podle mx zaznamu me mail domeny, protoze mezitim se me zmenila ip mnohokrat. Zkousel pouzit 2 roky stare heslo vcetne jejich variant. Ip utocnika je v rozsahu registru ceskeho isp. Takze jen odhaduju, ze nekdo louskal hodne starou zalohu nejakeho linuchu, ktery jsem kdysi spravoval a zkousel stesti. I kdyby mel stesti, a heslo na ssh fungovalo, nebylo by mu to moc platne, protoze specialne pro pripojeni pres ssh z venku pouzivam na tuto konkretni cinnost vyhrazeny jail, ktery slouzi jen k jednomu ucelu...ostatne jako vsechny sluzby dostupne z venku(mail etc)...klidne me nazvete paranoikem:) V kazdem pripade jsem podnikl nektere zakladni protiopatreni jako nahazeni ip do pf block, omezeni pristupu na danou sluzbu jen z konkretnich ip, odtedka si nechavam syslogem vypsat(realtime) do konzole "*.err;kern.warning;auth.notice;mail.crit /dev/console" a nejak to jeste ohnu, aby me to posilalo i mail okamzite po zjisteni, ze se nekdo zkousel prihlasit. Uz mam nejakou dobu nainstalovany NIDS, ale jeste sem nemel cas-chut to rozchodit, coz se ted zmenilo:). Na toto forum jsem psal v male nadeji, ze nekdo se uz s podobnyma hlaskama a s problemem auth.log-periodic setkal. Evidentne nikoliv, nebo se tu jeste neobjevil.

[puco]

Zdravim,

mozno vam to trochu pomoze, nasiel som kt. program generuje tuto hlasku. Je to lock. Viac v zdrojakoch:

http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.bin/lock/lock.c?rev=1.18;content-type=text%2Fplain

Nesnazil sa niekto odomknut vasu session, ked ste si odbehli od terminalu?

[PanZvedavy]

k terminalu nema nikdo fyzickej pristup vyjma mne, takze to muzem vyloucit.

[puco]

Aby to tak bolo naozaj a co upratovacky Tak ci tak, pravdepodobne jediny zdroj tejto hlasky je utilita lock. Mozno by pomohlo zapnut accounting a pozret sa kto co kedy spustal.

[cronin]

Pravdepodobne bude stacit toto:

man syslog.conf
man newsyslog

Ak nie, bude v tom cosi zapeklitejsie, ale to asi budeme potrebovat presnejsie informacie.