Dotaz: auditctl vs tcpdump nesrovnalost

[marek]

Dobry den.

Dle dokumentace kdyz mam zaple:

# auditctl -l
-a always,exit -F arch=b64 -S socket -F a0=0x2 -F key=TEST
#

Mel bych videt vsechna volani tcp socketu.

Pokud udelam:

nc 216.58.201.78 443

skutecne v /var/log/audit/audit.log vidim:

type=SYSCALL msg=audit(1484664247.522:74459): arch=c000003e syscall=41 success=yes exit=3 a0=2 a1=1 a2=6 a3=55de58c59140 items=0 ppid=18935 pid=19137 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts22 ses=1 comm="nc" exe="/usr/bin/ncat" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="TEST"
type=PROCTITLE msg=audit(1484664247.522:74459): proctitle=6E63003231362E35382E3230312E373800343433

v tcpdump vidim odpovidajici:

15:45:02.357762 IP 172.24.146.215.34144 > 216.58.201.78.443: Flags [S], seq 2203129635, win 29200, options [mss 1460,sackOK,TS val 1204233792 ecr 0,nop,wscale 7], length 0
15:45:02.358440 IP 216.58.201.78.443 > 172.24.146.215.34144: Flags [R.], seq 1769143029, ack 2203129636, win 29200, length 0

Potud v poradku.

V tcpdump se mi ale objevuji spojeni, ke kterym neni adekvatni zaznam v /var/log/audit/audit.log:

15:50:55.349067 IP 172.24.146.215.34498 > 216.58.201.78.443: Flags [S], seq 2932252123, win 29200, options [mss 1460,sackOK,TS val 1204586783 ecr 0,nop,wscale 7], length 0
15:50:55.349663 IP 216.58.201.78.443 > 172.24.146.215.34498: Flags [R.], seq 1628348476, ack 2932252124, win 29200, length 0

Pokud nahodou to spojeni chytim pomoci ss nema vyplnen proces:

#while true; do  ss -napt; done | grep 216.58.201.78             
SYN-SENT   0      1      172.24.146.215:34872              216.58.201.78:443                
^C
#

Tusite nekdo, jak zjistim co to dela?

Marek

Odpovědi

[Michal Kubeček]

Napadají mne dva důvody, proč to v auditu nevidíte:

• může to být 32-bitová aplikace používající 32-bitový syscall
• mnohé programy (dost možná i většina) volají socket() s nulovým třetím parametrem, tj. defaultní protokol, což při kombinaci PF_INET a SOCK_STREAM je TCP
• čistě technicky by ten socket mohl patřit jádru, ale u TCP spojení na port 443 a adresu patřící Googlu bych na to moc nesázel

Možná vás ale spíš zajímá connect() než socket().

Výstup ss pravděpodobně odpovídá tomu, že jste se zrovna trefil mezi SYN a RST. Zajímavější je otázka, proč chybí informace o procesu. Moje odpověď je "nevím". :-)

Mimochodem, jedna z podstatných výhod ss oproti netstatu je v tom, že můžete specifikovat filtr, takže si jednak ušetříte nespolehlivý a neefektivní grep, jednak jádro předává příkazu informace jen o socketech, které vás zajímají (místo toho, aby se předávalo a vypisovalo všechno a pak z toho grep něco filtroval). V tomto případě např.

  ss -ntap dst 216.58.201.78
  ss -ntap dport == :443

[Michal Kubeček]

mnohé programy (dost možná i většina) volají socket() s nulovým třetím parametrem, tj. defaultní protokol, což při kombinaci PF_INET a SOCK_STREAM je TCP

Tohle ignorujte, díval jsem se na řádek z logu místo na ten z konfigurace.

[marek]

Dekuji za odpovedi.

Nakonec jsem to vyresil tak, ze jsem pomoci iptables DROPnul RST, takze ss mel vice casu a ten proces mi prozradil(necekane chrome).

Ale to nevysvetluje proc to neni v audit

Dekuji

Marek

[Michal Kubeček]

Když víte, co to je, můžete použit strace a podívat se na všechna jeho volání socket(). (Předpokládám, že jste si ověřil, že to není 32-bitový proces.)

[Vantomas]

Proč to 32bit procesy neukáže? To potom ten audit moc funkční není, když útočníkovi stačí použít 32bit binárku.

[Michal Kubeček]

Máte tam "-F arch=b64". Manuálová stránka doporučuje v případě, že se čísla syscallu liší (což je, pokud dobře vidím, i případ socket()), použít dvě pravidla, jedno s b64 a jedno s b32.

[Michal Kubeček]

Zdá se, že oprava je na cestě. :-)

[NN]

Neni to proto, ze auditd monitoruje socket() syscall a otevrena TCP session jiz zadny port nealokuje?