audit not catching accept call from a 64bit sshd

hsultan at thefroid.net hsultan at thefroid.net
Tue Jan 13 23:16:25 UTC 2015


Hi,

So I'm a bit dumbfounded by what I'm seeing on my Ubuntu 14.04 Server 
LTS :

ubuntu at ip-172-31-37-137:~/test$ sudo netstat -anop |grep sshd
tcp        0      0 0.0.0.0:22              0.0.0.0:*               
LISTEN      1406/sshd        off (0.00/0/0)

Using file I verified that it's a 64bit process :

ubuntu at ip-172-31-37-137:~/test$ file /usr/sbin/sshd
/usr/sbin/sshd: ELF 64-bit LSB  shared object, x86-64, version 1 
(SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, 
BuildID[sha1]=00e04495db18849d9fa69d05f3626e66c6a6d4e1, stripped

I then ran strace on it, and launched a telnet to 127.0.0.1 : 22

ubuntu at ip-172-31-37-137:~/test$ sudo strace -p 1406
Process 1406 attached
select(7, [3 4], NULL, NULL, NULL)      = 1 (in [3])
accept(3, {sa_family=AF_INET, sin_port=htons(58853), 
sin_addr=inet_addr("127.0.0.1")}, [16]) = 5
fcntl(5, F_GETFL)                       = 0x2 (flags O_RDWR)
pipe([6, 7])                            = 0
socketpair(PF_LOCAL, SOCK_STREAM, 0, [8, 9]) = 0
clone(child_stack=0, 
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, 
child_tidptr=0x7f95cba7db10) = 6224

Clearly it is calling the accept system call.

Next I look at the audit infrastructure to see what it gives me :
ubuntu at ip-172-31-37-137:~/test$ sudo auditctl -l
LIST_RULES: exit,always arch=3221225534 (0xc000003e) 
syscall=accept,accept4

Then I use my own tool to catch every msg from the netlink (using 
audit_get_reply) port and display each and every msg that has a struct 
audit_reply->len > 0 , as well as audit msgs from netfilter/conntrack.
Just to make sure that my audit code/settings are correct, I launch a 
telnet to port 22, and another one to port 631 (cups), and here's what I 
see :

audit(1421190014.387:45784): audit_enabled=1 old=1 auid=1000 ses=16 
res=1
     [NEW] tcp      6 120 SYN_SENT src=127.0.0.1 dst=127.0.0.1 
sport=58860 dport=22 [UNREPLIED] src=127.0.0.1 dst=127.0.0.1 sport=22 
dport=58860
  [UPDATE] tcp      6 60 SYN_RECV src=127.0.0.1 dst=127.0.0.1 
sport=58860 dport=22 src=127.0.0.1 dst=127.0.0.1 sport=22 dport=58860
  [UPDATE] tcp      6 432000 ESTABLISHED src=127.0.0.1 dst=127.0.0.1 
sport=58860 dport=22 src=127.0.0.1 dst=127.0.0.1 sport=22 dport=58860 
[ASSURED]
  [UPDATE] tcp      6 120 FIN_WAIT src=127.0.0.1 dst=127.0.0.1 
sport=58860 dport=22 src=127.0.0.1 dst=127.0.0.1 sport=22 dport=58860 
[ASSURED]
  [UPDATE] tcp      6 30 LAST_ACK src=127.0.0.1 dst=127.0.0.1 
sport=58860 dport=22 src=127.0.0.1 dst=127.0.0.1 sport=22 dport=58860 
[ASSURED]
  [UPDATE] tcp      6 120 TIME_WAIT src=127.0.0.1 dst=127.0.0.1 
sport=58860 dport=22 src=127.0.0.1 dst=127.0.0.1 sport=22 dport=58860 
[ASSURED]
     [NEW] tcp      6 120 SYN_SENT src=127.0.0.1 dst=127.0.0.1 
sport=40478 dport=6031 [UNREPLIED] src=127.0.0.1 dst=127.0.0.1 
sport=6031 dport=40478
[DESTROY] tcp      6 src=127.0.0.1 dst=127.0.0.1 sport=40478 dport=6031 
[UNREPLIED] src=127.0.0.1 dst=127.0.0.1 sport=6031 dport=40478
     [NEW] tcp      6 120 SYN_SENT src=127.0.0.1 dst=127.0.0.1 
sport=36764 dport=631 [UNREPLIED] src=127.0.0.1 dst=127.0.0.1 sport=631 
dport=36764
  [UPDATE] tcp      6 60 SYN_RECV src=127.0.0.1 dst=127.0.0.1 
sport=36764 dport=631 src=127.0.0.1 dst=127.0.0.1 sport=631 dport=36764
  [UPDATE] tcp      6 432000 ESTABLISHED src=127.0.0.1 dst=127.0.0.1 
sport=36764 dport=631 src=127.0.0.1 dst=127.0.0.1 sport=631 dport=36764 
[ASSURED]
audit(1421190031.663:45785): arch=c000003e syscall=43 success=yes 
exit=15 a0=b a1=7f84aee66f7c a2=7fff960572fc a3=7f84ad2b67b8 items=0 
ppid=1 pid=22048 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 
egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="cupsd" 
exe="/usr/sbin/cupsd" key=(null)
audit(1421190031.663:45785): saddr=02008F9C7F0000010000000000000000
audit(1421190031.663:45785):

I never see the accept call for sshd ... even though connection is 
established, but I see the one for cups. The machine is pretty much 
idle, so there should be no msgs dropped.

Any idea what could be the reason ? I just can't see what I could be 
doing wrong here.

Thanks,

Hassan




More information about the Linux-audit mailing list