Login | Register   
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Ensure Network Safety with Centralized Logging : Page 8

Virus definitions often can't keep up with the rapid proliferation of Windows-based worms, letting them slip under your radar. How can you keep your network safe? Use the access lists on your routers along with a centralized logging database to help you quickly find and isolate infected hosts.


advertisement
Maintenance
There are some miscellaneous items you need to configure for routine maintenance. The router maintenance is optional, however, the database maintenance is highly recommended.

First, in order to make the access list counters on the router itself worthwhile, they should be reset on a regular basis. This helps show a reasonable timeline of how often the events are happening. It should be done at least once a day, but on a busier network, possibly once an hour.

I've created a simple script to automate this process. Cut and paste the contents of the script into a file called clear-counters.sh and put it in /usr/local/bin. Then run chmod 700 /usr/local/bin/clear-counters.sh on the file. You'll need to edit the first section with your router IP address, username, password, and enable password. In the current incarnation of the script, a separate one will need to be created for each host.



#!/bin/sh ######################################## # Router's IP address # IP_ADDRESS='<router IP address>' # router username & password/enable password USERNAME='<username>' PASSWORD='<user pass>' EPASS='<enable pass>' ### # Collect data from the router # If your device doesn't have username/password for authentication, # you may need to remove the ${USERNAME} here. ### (echo "${USERNAME}";\ echo "${PASSWORD}";\ echo "term len 0";\ ### # Go into enable mode. ### echo "en";\ echo "${EPASS}";\ ### # Everything beyond this point will be in enable mode. # USE CAUTION HERE! ### echo "clear ip access-list counters";\ echo -e "\n";\ echo "q";\ sleep 30)|telnet ${IP_ADDRESS} Next, as root, run 'crontab -e' and enter in: 15 0 * * * /usr/local/bin/clear-counters.sh

The root user will get mail from that, but once you're sure it's running properly, add > /dev/null 2>&1 after it. This will eat the messages and stop the mail from coming. If you'd like to run it every hour, change the 15 0 * * *' to '0 * * * * at the beginning of the line.

Your database will quickly grow with a lot of events. I run a script nightly for basic database maintenance to delete old syslog messages. I run this script as the postgres user on the system. In the postgres user's home directory, I've created a bin directory, and the script resides inside that directory. As that user, create a script called cron_syslog_maint.sh and cut and paste the contents of this script into it. Then run chmod 700 cron_syslog_maint.sh on it. My syslog server receives a lot of events on a daily basis, so I only keep 14 days worth of data. On a network with less or more data you may want to change this. You'll also need to edit this script to reflect the PGDATA and PGHOME on your system.

#!/bin/sh # # PATH=$PATH:/usr/bin:/usr/sbin:/usr/local/bin:/etc:. LD_LIBRARY_PATH=/usr/local/lib:/usr/local/ssl/lib:/usr/local/pgsql/lib PGHOME=/usr/local/pgsql PATH=$PATH:$PGHOME/bin PGDATA=$PGHOME/data export PATH LD_LIBRARY_PATH PGHOME PGDATA /usr/local/pgsql/bin/psql -c "delete from syslog where date < current_date-14" syslog

Next, add an entry to the user's cron tab to run the delete nightly. Edit the path according to where the postgres user home path is.

15 0 * * * <postgres user home/bin/cron_syslog_maint.sh

Postgres uses a method called vacuum on databases to clean out old records and old bits of information. This should be done on a regular basis to avoid slowingyour databases down with old unsed data. I recommend doing it at least once a day:

#!/bin/sh # # PATH=$PATH:/usr/bin:/usr/sbin:/usr/local/bin:/etc:. LD_LIBRARY_PATH=/usr/local/lib:/usr/local/ssl/lib:/usr/local/pgsql/lib PGHOME=/usr/local/pgsql PATH=$PATH:$PGHOME/bin PGDATA=$PGHOME/data export PATH LD_LIBRARY_PATH PGHOME PGDATA /usr/local/pgsql/bin/vacuumdb -f ${1}

Run this cronjob as your postgres user a few times a day to clean out your database.

30 0 * * * /export/home/postgres/bin/cron_vacuum.sh nmt_db

Startup Scripts
Lastly, you'll need to create startup scripts for syslog-ng and the logging user. Paste the following script in your init scripts on your operating system, and call it c-syslog.sh. Under Linux systems, create the script in /etc/init.d. Set permissions on the script by chmod 755 /etc/init.d/c-syslog.sh. Then, link it into /etc/rc3.d by running 'ln -s /etc/init.d/c-syslog.sh /etc/rc3.d/c-syslog.sh.

#!/bin/sh case "$1" in start) su syslog -c /home/syslog/bin/pipeme.sh & sleep 5 /usr/local/sbin/syslog-ng ;; stop) echo "ERROR: Not Implemented" ;; *) echo "Usage: $0 {start|stop}" ;; esac

Using a centralized syslog server can be very helpful generally, but it is especially handy in finding virus infected hosts—when used properly. Hopefully, at this point, you have a centralized syslog server with a Web-based interface, and can find it useful in your environment.



Tim Conrad lives and works in New York City, where he supports the network infrastructure at an educational services company. In his spare time he likes to go to concerts, drink beer, play guitar, and spend quality time with his computers.
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap