Stefan Viljoen
2015-Jan-08 07:24 UTC
[asterisk-users] Asterisk executable suddenly about 40KB larger - modules
Hi guys Thanks for the pointers - I'll look into the possible compromise scenario though I've got no idea how I'll counter it -if- I manage to detect it...! I've disabled prelinking (thanks Tony!) and I'll see if that helps. Interesting thing I've now discovered (had this failure again at the head office this morning) is the "growth" in the file's size is precipitated by Asterisk crashing with (in /var/log/messages): Jan 8 06:13:27 veridial kernel: asterisk[7856]: segfault at 00002aaaaaae0900 rip 00002aaaaaae0900 rsp 0000000041e9ad88 error 15 So the sequence is the running Asterisk segfaults, and when it is restarted ODBC functionality is broken and the executable in /usr/sbin is += 40kb larger than before. As for the segfault, when it happened yesterday the address and rip were the SAME, only the rsp (stack pointer?) values were different, with the same error 15, e. g. yesterday it was Jan 7 07:27:12 veridial kernel: asterisk[16462]: segfault at 00002aaaaaae0900 rip 00002aaaaaae0900 rsp 000000004309c428 error 15 Also, the fix I used yesterday (copying the previously compiled asterisk executable from src/main to /usr/sbin) did NOT work - the file in /src/main had the same +40kb size / was -already- compromised. So I did a make clean;make and copied the file from src/main to /usr/sbin and only -then- did my setup start working again with ODBC CDRs / CELs running correctly. I'll also now try Doug's chattr suggestion to try and "freeze" the live executable. Thanks for the replies and assistance. Regards Stefan
Andres
2015-Jan-08 14:06 UTC
[asterisk-users] Asterisk executable suddenly about 40KB larger - modules
On 1/8/15 2:24 AM, Stefan Viljoen wrote:> Hi guys > > Thanks for the pointers - I'll look into the possible compromise scenario > though I've got no idea how I'll counter it -if- I manage to detect it...! > > I've disabled prelinking (thanks Tony!) and I'll see if that helps. > > Interesting thing I've now discovered (had this failure again at the head > office this morning) is the "growth" in the file's size is precipitated by > Asterisk crashing with (in /var/log/messages): > > Jan 8 06:13:27 veridial kernel: asterisk[7856]: segfault at > 00002aaaaaae0900 rip 00002aaaaaae0900 rsp 0000000041e9ad88 error 15 > > So the sequence is the running Asterisk segfaults, and when it is restarted > ODBC functionality is broken and the executable in /usr/sbin is += 40kb > larger than before. > > As for the segfault, when it happened yesterday the address and rip were the > SAME, only the rsp (stack pointer?) values were different, with the same > error 15, e. g. yesterday it was > > Jan 7 07:27:12 veridial kernel: asterisk[16462]: segfault at > 00002aaaaaae0900 rip 00002aaaaaae0900 rsp 000000004309c428 error 15 > > Also, the fix I used yesterday (copying the previously compiled asterisk > executable from src/main to /usr/sbin) did NOT work - the file in /src/main > had the same +40kb size / was -already- compromised. > > So I did a make clean;make and copied the file from src/main to /usr/sbin > and only -then- did my setup start working again with ODBC CDRs / CELs > running correctly. > > I'll also now try Doug's chattr suggestion to try and "freeze" the live > executable. > > Thanks for the replies and assistance.I would also start by putting an audit rule on the binary. Something like this: auditctl -w /usr/sbin/asterisk -p war -k asterisk-bin then you can get a report on who modified it and when by using: ausearch -f /usr/sbin/asterisk Its a start, but eventually you might need to monitor even keystrokes with pam_tty_audit.so to understand who is doing this: http://poorlydocumented.com/2014/05/enabling-pam_tty_audit-on-rhel-centos-or-scientific-linux/> Regards > > Stefan > > >-- Technical Support http://www.cellroute.net