Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
I'm having a problem completely understanding some audit.log messages I've been seeing. There are several thousand messages being generated per minute from my user account (ldap) and from the root account. The messages are open system calls that are resulting in failures. Since this activity is on another network I'll do my best to summarize what I'm seeing:
**the ppid and pid keeps changing
**the auid is either "0" or "10481", which is my ldap account
**the uid, gid, euid, suid, fsuid, egid, sgid, and fsgid are all the same "group" id. ses=103575 comm="mysql" exe="/usr/bin/mysql"
type=CWD msg=audit(1234874638.599:5207): cwd=
type=PATH msg=audit(1234874638.599:5207): item=0 name="/etc/host.conf"
So basically it looks like my user account and the root account are the culprits. It appears that I attempted to log in to mysql, but it failed (as evidenced by the passing of the /etc/host.conf file to mysql) because I used the wrong credentials. What I don't understand is why thousands of logs are being generated. I ran ps -ef looking for mysql or a script of some sorts, but found nothing. I checked crontab and crond, but couldn't find anything that I nor root would be running that would cause this. Besides, how in the world would thousands of login attempts to mysql be made per minute? I also ran some lsof commands to try and find any mysql libraries that were open. I even looked at all ssh connections from other nodes on the network from my account but all I could find was my current connection.
I'm not sure how to kill this thing, especially since the pid and ppid keeps changing. Is there anyway to leverage the use of the "ses" (session ID) to track this thing down and stop it? Is there something else I could try?
'ausyscall 2' says it's the fork system call as in 'man fork'.
Originally Posted by reberly337
Is there anyway to leverage the use of the "ses" (session ID) to track this thing down (..)
Well 'ausearch' has a "--session" switch. Make sure to limit the search with "-ts" a specific start time like "14:30:00" or "today" or see the manual.
Originally Posted by reberly337
I'm not sure how to kill this thing, especially since the pid and ppid keeps changing.
First check if /etc/host.conf has the appropriate ownership and access rights, because MySQL may use /etc/host.conf to determine if it should read /etc/hosts. If all is OK then 'sudo auditctl -l|grep "syscall.*fork";') should show which rules are loaded that monitor syscalls, or else see /etc/audit/audit.rules, then determine if regulations require you to have that rule (other than that it's always good to check rule sets performance-wise) then determine (implications mostly) if it's allowed to either 0) add an exclusion rule, or 1) modify the syscalls it monitors or 2) if its allowed to add an exclusion for the original UID (auid).