OSSEC is a tricky devil to automate. And what I mean by automate; is install the ossec-hids-server, install the ossec-hids agent, register the agent and have the server recognize that registration without human prompts. If you’ve done this before, you know there are lots of manual steps. The smart folks over at BinaryDefense have added some automation to that process with their auto-ossec tool
They really took a lot of work out of all of the manual steps needed to connect the client to the server, generate the key and exchange the key…
but… the process was still not as automated as I needed it to be. In AWS you don’t know what the OSSEC server IP will be, and that IP needs to be passed to auto-ossec as an arguement + placed in the ossec-hids-agent config file. Not to mention all of the repo adds, tweaks to ossec config files that must happen even for ossec to start properly.
I have written two scripts, located in my git repository, that automates the installation of the remaining pieces that auto-ossec does not; that is outfitted for AWS Linux.
The LinuxOssecServer script installs ossec-hids-server and binarydefense auto-ossec listener on the AWS Linux Ec2 instance that will be in the role of Ossec Server.
We leverage S3 as a storehouse for needed files:
The atomix file/ script that you run to install the ossec repositories: https://updates.atomicorp.com/installers/atomic would go in s3://yourbucketname.
Also, a clone of binary defense repo https://github.com/binarydefense/auto-ossec would go in s3://yourbucketname.
You need to allow your EC2 instance access to S3 and to query other instances, so EC2 instance Role required for access to S3 and EC2.
The LinuxOssecClient script installs ossec-hids-agent and and binarydefense auto-ossec and then automatically locates the AWS EC2 instance ossec-server ip (via a pre-set tag) and registers the agent and starts services on AWS Linux. Same requirements as above for the fole.
The line with ‘aws ec2 describe-instances’ must have correct region, so put your region in there. For the public version of the code, ossec server must have AWS tag of Name=tag:Role,Values=OssecMaster for script to locate the IP addr of the EC2 instance that is the ossec server, so when you start your OssecServer instance, be sure to add that tag.
You’ll notice some sleep commands I’ve put in the scripts. OSSEC initialization is a little buggy, meaning, [ see ref links 1 and 2 below ] that you have to restart the ossec-hids-server process on the server after the first agent attempts to register; once that is done, all the subsequent agents will register with no problem. I don’t know why this is and this behavior is lame – and I hated to have to code around it. I need to come up with a better way that just sleeping the script during the first agent registrations; and then running a restart after x minutes. Or maybe the next version of OSSEC will fix this so the first agent will register without a restart.
Ref .1 Issue where you have to restart OSSEC after first agent registers
Ref 2 Issue where you have to restart OSSEC after first agent registers
Also, don’t forget to configure your Security Groups correctly.
You’ll need 9654 TCP open on the OSSEC server for the auto-ossec listener
You’ll need 1514 UDP open on the OSSEC server to accept agent keep alive messages.