« Domain failure | Main | Back Online »
Tuesday, April 22, 2008
IDS/IPS Sensor Administration Utility
Introduction
This is the InfoSec Sensor Administration Utility Users Guide.
The application is designed to allow for the automated updating of the
remote sensors rules and map files. It will soon also update the master
snort.conf files as well and thus allow for easy admin of multiple ses-
nors. This application is designed to allow for the automated updating of
the remote sensors rules and map files. It will soon also update the mas-
ter snort.conf files as well
The main file here is the /etc/snort/sensors file which has a list of the
sensors that are monitored and will be updated by the script, the con-
tents of the file is as follows:
/etc/snort/sensors
New sensors can be added to this file, on the server side, the only thing
that has to be setup for the ssh keys is as follows, on the new sensors
copysensors key sensor-xxx.pub to the remote sensor into the
/root/.ssh2/hostkeys directory, and then add the following line to the
/root/.ssh2/authorization file
Key hostkeys/sensor-xxx.pub
Thats it, now go to control system and run script, it should update the
new
sensor/s without a password being needed.
Program Explanation
These are the steps and procedures we use to update the rules and signa-
tures on the currently deployed Snort Sensors.
Log into sensor as root, and cd into the /etc/snort directory
Make the required commenting out of rules from the appropriate files that
END in .rules and comment the reason for change, then save the file.
Add the new custom signature to the local.rules file located in this
directory, then save the file
Then test the configuration and signatures locally before deploying, this
will ensure the correct syntax has been used, and that the daemon process
will correctly shutdown and restart when the update is done.
Comment out any other signatures that needed to be due to false positives
or for testing from the signature files in this directory, they are all
named as normal with a .rules extension, then write and quit the file
Then while in the /etc/snort directory execute ./control, then using the
passwords in the following order to log into the sensors
Once the last sensor update is done it will go back to a shell prompt
The first subroutine goes out and updates all the standard and bleeding
edge rules as needed, this is done each time the program is run.
here is the p-code for the update routine
int update_rules() { /* Will work for any file length */ char command[512]; char command2[512]; printf("Getting New Rules.........................%s\n"); system("rm log"); sprintf(command,)-- ("/bin/oinkmaster -q -C /etc/snort/oinkmaster.conf -o snort > log" ) code from control script sprintf(command2); <-- ( ,"/bin/oinkmaster -q -C /etc/snort/bleeding-rules.conf -o snort >> log"; ) system(command); system(command2); exit(1); }
The next two subroutines used in this application are process_rules and
restart_daemons, the names should self explanatory, the first sync's the
local rules and map files to the remote system, and the second routine,
log's into each remote system and restarts the daemos on the sensors.
process_rules
- call remote sensors
- have rules changed on sensors
- update/sync only changes rules
- display rules that have changed
- disconnect from sensor, repeat
restart_daemons
- connect to sensors
- issue restart command
- display remote restart status
- disconnect from sensor, repeat
The last routine then goes out and check to insure that each of the sen-
sors successfully restarted and is functioning properly.
check_sensor_status
- call sensors from sensor list
- send status check command
- read into buffer
- display input buffer locally and copy results to log file
- disconnect from sensor and go to next one, repeat process
Merged and added logic for rules file and log file contents, If the log
file is empty, it will send an email with the following message to the
admins:
Daily Sensor Rules Update Notice
No Rules updated Today
If the logfile is not empty, it will email the resulting logfile con-
tents.