* audit not catching accept call from a 64bit sshd
@ 2015-01-13 23:16 hsultan
2015-01-15 17:25 ` Steve Grubb
0 siblings, 1 reply; 3+ messages in thread
From: hsultan @ 2015-01-13 23:16 UTC (permalink / raw)
To: linux-audit
Hi,
So I'm a bit dumbfounded by what I'm seeing on my Ubuntu 14.04 Server
LTS :
ubuntu@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@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@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@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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: audit not catching accept call from a 64bit sshd
2015-01-13 23:16 audit not catching accept call from a 64bit sshd hsultan
@ 2015-01-15 17:25 ` Steve Grubb
2015-01-15 20:25 ` hsultan
0 siblings, 1 reply; 3+ messages in thread
From: Steve Grubb @ 2015-01-15 17:25 UTC (permalink / raw)
To: linux-audit; +Cc: hsultan
On Tuesday, January 13, 2015 03:16:25 PM hsultan@thefroid.net wrote:
> Hi,
>
> So I'm a bit dumbfounded by what I'm seeing on my Ubuntu 14.04 Server
> LTS :
>
> ubuntu@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@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@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@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.
Make sure you have both a 32 and 64 bit rule. That's all I can think of. Also,
check to see if you have audit=1 on your kernel boot parameters. There is a
chance that sshd is starting before auditd and then its marked inauditable.
But, it works fine on my system.
-Steve
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: audit not catching accept call from a 64bit sshd
2015-01-15 17:25 ` Steve Grubb
@ 2015-01-15 20:25 ` hsultan
0 siblings, 0 replies; 3+ messages in thread
From: hsultan @ 2015-01-15 20:25 UTC (permalink / raw)
To: linux-audit
On 2015-01-15 09:25, Steve Grubb wrote:
> On Tuesday, January 13, 2015 03:16:25 PM hsultan@thefroid.net wrote:
>> Hi,
>>
>> So I'm a bit dumbfounded by what I'm seeing on my Ubuntu 14.04
>> Server
>> LTS :
>>
>> ubuntu@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@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@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@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.
>
> Make sure you have both a 32 and 64 bit rule. That's all I can think
> of. Also,
> check to see if you have audit=1 on your kernel boot parameters.
> There is a
> chance that sshd is starting before auditd and then its marked
> inauditable.
> But, it works fine on my system.
Thanks that did it, not sure how I missed that, should have been
obvious :(
Hassan
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2015-01-15 20:25 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-01-13 23:16 audit not catching accept call from a 64bit sshd hsultan
2015-01-15 17:25 ` Steve Grubb
2015-01-15 20:25 ` hsultan
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox