I followed the thread and set everything up as Typepad, Google AdSense and Feedburner recommended. I saw that ads were now getting pumped to my feed, but not to my blog and it didn't matter what I did.

Members of the AdSense community help forum were very unhelpful and even a bit rude. I was hoping that a Google employee could verify if the functionality was still available or not and didn't get any such support.

I opened a support ticket with Typepad and they let me know that the links that I had used were probably out of date and that feature was likely no longer available.

So there you have it. If you have a Pro Basic Typepad account like I do, it's not currently possible for you to have ads on each blog post.

Although it does seem possible to get rsyslog to change the way it handles certain kinds of logs...I'll have to do some digging to see if I can find instructions for doing this with OSSEC.

**Update: My friend Mike recommends http://www.ossec.net/doc/syntax/head_ossec_config.syslog_output.html?highlight=syslog#syslog_output for a possible solution.

Prerequisites

These instructions are specific to CentOS 6.2. If you are using a different distro, many of the installation commands and paths to files will be different from what I've documented below. I strongly suggest that you document the steps to perform a similar install for your distro.

You will need to install the prerequisites by using the following commands:

yum install httpd
yum install mysql
yum install mysql-server
yum install php
yum install php-mysql
yum install php-gd
yum install rsyslog
yum install rsyslog-mysql
/usr/bin/updatedb 

The '/usr/bin/updatedb' command updates the file index so that the 'find' and 'locate' commands work properly. If you've already properly set up your system to index the files daily, this will be unnecessary.

If your distro of Linux is using a different syslog server such as syslog-ng or sysklogd, you'll need to remove it.

MySQL

Set up MySQL

/sbin/chkconfig --levels 235 mysqld on
/etc/init.d/mysqld start
/usr/bin/mysql_secure_installation

Hit enter key after last command has run since no password has yet been set for root MySQL account. Hit 'y' and enter when asked to set up a root password and type in a strong password. Hit 'y' and enter for the following questions: "Remove anonymous users?", "Disallow root login remotely?", "Remove test database and access to it?", and "Reload privilege tables now?"

Set up database and tables

Create the user/database/table and table schema:

Log in to mysql:

mysql -u root -p

Create a user:

CREATE USER rsyslog;
SET PASSWORD FOR rsyslog= PASSWORD('yourpasswordgoeshere');

Set up database and table schema:

CREATE DATABASE rsyslogdb;
USE rsyslogdb;

Paste contents below to mysql to set up the schema:

CREATE TABLE SystemEvents
(
 ID int unsigned not null auto_increment primary key,
 CustomerID bigint,
 ReceivedAt datetime NULL,
 DeviceReportedTime datetime NULL,
 Facility smallint NULL,
 Priority smallint NULL,
 FromHost varchar(60) NULL,
 Message text,
 NTSeverity int NULL,
 Importance int NULL,
 EventSource varchar(60),
 EventUser varchar(60) NULL,
 EventCategory int NULL,
 EventID int NULL,
 EventBinaryData text NULL,
 MaxAvailable int NULL,
 CurrUsage int NULL,
 MinUsage int NULL,
 MaxUsage int NULL,
 InfoUnitID int NULL ,
 SysLogTag varchar(60),
 EventLogType varchar(60),
 GenericFileName VarChar(60),
 SystemID int NULL
);
CREATE TABLE SystemEventsProperties
(
 ID int unsigned not null auto_increment primary key,
 SystemEventID int NULL ,
 ParamName varchar(255) NULL ,
 ParamValue text NULL
);

Next, we need to grant permissions to the rsyslog account we created earlier:

GRANT ALL PRIVILEGES ON `rsyslogdb`.* TO 'rsyslog'@'%' IDENTIFIED BY 'yourpasswordgoeshere';
flush privileges;

Leave MySQL:

exit

Configure rsyslog

Setting up

How to configure rsyslog:

nano /etc/rsyslog.conf

Make your #### Modules #### section the same as the following:

#### MODULES ####

$ModLoad ommysql        # provides support for MySQL
$ModLoad imuxsock.so    # provides support for local system logging (e.g. via logger command)
$ModLoad imklog.so      # provides kernel logging support (previously done by rklogd)
#$ModLoad immark.so     # provides --MARK-- message capability

# Provides UDP syslog reception
$ModLoad imudp.so
$UDPServerRun 514

# Provides TCP syslog reception
$ModLoad imtcp.so
$InputTCPServerRun 514

Just above ### begin forwarding rule ### section add info similar to the following line to limit IP addresses that can send syslog info to the server, for each class C subnet the server will be collecting from, you'll need to enter the subnet info followed by /24 (such as 172.18.22.0/24) to allow that subnet to send syslog data. Alternatively, you can limit by single IP addresses. The 127.0.0.1 is necessary so the server can send logs to itself:

$AllowedSender TCP, 127.0.0.1, 172.18.22.0/24
$AllowedSender UDP, 127.0.0.1, 172.18.22.0/24

Add the following line to the ### begin forwarding rule ### section. Replace the "<yourrsyslogpasswordhere>" bit with the password you set for rsyslog MySQL user above:

*.*       :ommysql:127.0.0.1,rsyslogdb,rsyslog,<yourrsyslogpasswordhere>

When done modifying the file, hit Ctrl+x, then y and then enter to save the file.

Restart the rsyslog service:

service rsyslog restart

Test rsyslog

Check if messages are arriving at the syslog server:

tail -f /var/log/messages

Check if messages are being stored in mysql database:

mysql -u root -p
use rsyslogdb;
select * from SystemEvents;

If you see anything other than “empty set” it’s working. Exit out of MySQL:

exit

Configure Apache

Configure CentOS to start the web server at bootup and manually start the service:

chkconfig --levels 235 httpd on
service httpd start

modify 2 lines to match your server's respective ip and fqdn in /etc/httpd/conf/httpd.conf

nano /etc/httpd/conf/httpd.conf
from:
Listen 80
to:
Listen ip.address.of.server:80
and from:
#ServerName www.example.com:80
to:
ServerName fully.qualified.domian.name:80

Hit CTRL+x, then Y and then enter to save and exit the file.

Restart the server:

/etc/init.d/httpd restart

Set up IPTables

Edit the iptables file:

nano /etc/sysconfig/iptables

Add these lines to the /etc/sysconfig/iptables file (before the COMMIT line):

-I INPUT -p tcp --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT
-I OUTPUT -p tcp --sport 80 -m state --state ESTABLISHED -j ACCEPT

You'll need to enter lines similar to the following based on your network environment. For more info on how to use IPTables in CentOS see http://wiki.centos.org/HowTos/Network/IPTables:

-I INPUT -p tcp --dport 514 -s 172.18.22.0/24 -j ACCEPT
-I INPUT -p udp --dport 514 -s 172.18.22.0/24 -j ACCEPT

Restart the network service and IPTables:

/etc/init.d/network restart
/etc/init.d/iptables restart

Configure LogAnalyzer

Install LogAnalyzer

Check for the latest stable release by going to http://loganalyzer.adiscon.com/downloads in a browser. Current latest release is http://loganalyzer.adiscon.com/downloads/loganalyzer-3-4-2-v3-stable

Download it on your CentOS server by doing the following:

cd /tmp
wget http://download.adiscon.com/loganalyzer/loganalyzer-3.4.2.tar.gz

Uncompress the file:

tar -xvzf loganalyzer-3.4.2.tar.gz

Copy the source directory to the Apache html directory and create config.php file:

cd loganalyzer-3.4.2/src
rm -R -f /var/www/html
mkdir /var/www/html
cp -R * /var/www/html
cd /tmp/loganalyzer-3.4.2/contrib/
cp * /var/www/html
cd /var/www/html
chmod +x configure.sh secure.sh
./configure.sh

The last line will create a blank “config.php” file, and will give everyone write access to it. It won´t generate any output.

Check if the config.php file has been created (initial setup via browser will make changes to this file):

ls

Create LogAnalyzer MySQL user and database:

mysql -u root -p
create database loganalyzerdb;
CREATE USER loganalyzer;
SET PASSWORD FOR loganalyzer= PASSWORD('yourpasswordgoeshere');
GRANT ALL PRIVILEGES ON `loganalyzerdb`.* TO 'loganalyzer'@'%' IDENTIFIED BY 'yourpasswordgoeshere';
flush privileges;
exit

Initial setup of Log Analyzer, Step One:

On a client system go to the Log server's URL using a web browser (http://yoursystemnamehere.blah.org).

A message stating "Critical Error Occurred: Error main configuration file is missing! Click here to install Adiscon LogAnalyzer!" will appear in browser. Click on the word "here" to start the install.

Click "Next" twice and you should get to the "Basic Configuration" screen. The recommend settings are:

• Number of syslog messages per page: 200 (set this lower if the log server is on a slow system)
• Message character limit for main view: 80 (default)
• Character display limit for all string fields: 80
• Show message details popup: Yes (default)
• Automatically resolved IP Addresses (inline): Yes (default)
• Enable User Database: Yes
• Database Host: localhost (default)
• Database Port: 3306 (default)
• Database Name: loganalyzerdb
• Table prefix: logcon_
• Database User: loganalyzer
• Database Password: <enter in the loganalyzer database user password that you set earlier here>
• Require user to be logged in: Yes

Click "Next".

Initial setup of Log Analyzer, Step Two:

Click "Next" on the "Create Tables" page, then click "Next" on the "Check SQL Results" page and then set up the admin user:

• Username: <enter in the username here that you want>
• Password: <enter in the user password that you want to use>
• Repeat Password: <re-enter in the user password that you want to use>

Click "Next".

Initial setup of Log Analyzer, Step Three:

The recommended settings for the "Create the first source for syslog messages" page are:

• Name of the source: All Syslog Sources
• Source type: MySQL Native
• Select view: Syslog Fields (default)
• Table type: MonitorWare
• Database host: localhost (default)
• Database name: rsyslogdb
• Database table name: SystemEvents
• Database user: rsyslog
• Database password: <enter in the rsyslog database user password that you set earlier here>
• Enable row counting: "Yes"

Click "Next" and then click "Finish".

The install of LogAnalyzer has now been completed. Now other users can be created and there are many settings that can be tweaked as needed.

Point all of the syslog capable devices to the new log server and begin analyzing the aggregated logs.

References

The following sites were used to help figure this all out

http://en.tiagomarques.info/2011/07/centos-syslog-server-rsyslog-mysql-and-loganalyzer/

http://www.pantz.org/software/mysql/mysqlcommands.html

http://pkgs.fedoraproject.org/repo/pkgs/phplogcon/README.fedora/5aa1ea186764ba0a7ea239131141734a/README.fedora

http://www.linuxhelp.in/2010/10/how-to-configure-syslog-server-or.html

http://www.beguelin.com/2009/05/locate-and-updatedb-on-centos.html

Chris Borte's brain

Among other people such as my dad, I owe my love of computers and video games to Steve Jobs. Our first computer was an Apple II+ and I used that thing and the Apple IIe that preceded it as much as I could. Without that exposure, I don't think I would have gotten on to the path that lead me to where I am today.

How many other people out there are where they are today because of the vision of Steve Jobs?

Who else is profoundly sad that Steve Jobs has died?

Rest in peace, Steve.

They do have RPMs for Snort if you'd rather go that route, but Sourcefire (the makers of Snort) recommend that you install by compiling from source, which is what this instructional blog post is about.

The first thing you'll want to do is install CentOS 5.6 and run the autoupdater.

Next you'll want to download the following source packages:

Snort http://www.snort.org/downloads/867

Daq http://www.snort.org/downloads/860

Libpcap http://www.tcpdump.org/release/libpcap-1.1.1.tar.gz

TCPDump http://www.tcpdump.org/release/tcpdump-4.1.1.tar.gz

Libpcre http://sourceforge.net/projects/pcre/files/pcre/8.12/pcre-8.12.tar.gz/download

Libdnet http://libdnet.googlecode.com/files/libdnet-1.12.tgz

After downloading those files, you'll want to extract them. It's your choice where to extract them, but I just do it in the same folder that I downloaded them to.

Open up a terminal (command line) window and log in as root using

su - root

and enter your root password.

Make sure that gcc and the c++ module for gcc are installed:

yum install gcc

yum install gcc-c++

Change directories to where the libpcap source files were extracted to using the cd command, in my case the command is:

cd /home/alex/downloads/cd libpcap-1.1.1

Follow that with the following commands (these commands assume that libpcap 0.9.4 was installed per the default CentOS 5.6 install):

./configure

make

make install

That finishes the install of libpcap, so now we have to remove the links to the old version and create the new symbolic links.

cd /usr/lib

rm libpcap.so.0

rm libpcap.so.0.9

ln -s /usr/local/lib/libpcap.so.1.1.1 /usr/lib/libpcap.so.1.1.1

ln -s /usr/lib/libpcap.so.1.1.1 /usr/lib/libpcap.so.1

ln -s /usr/lib/libpcap.so.1 /usr/lib/libpcap.so

And now to the extracted directories from above for the daq source files and to do the install of daq:

cd /home/usr/alex/downloads/daq-0.5

./configure

make

make install

Next we need to install libpcre:

cd /home/usr/alex/downloads/pcre-8.12

./configure

make

make install

Next we need to install libdnet:

cd /home/usr/alex/downloads/libdnet-1.12

./configure

make

make install

And finally we can install snort:

cd /home/usr/alex/downloads/snort-2.9.0.5

./configure

make

make install

And you are done with the installation of Snort. You can now run it by doing this command:

/usr/local/bin/snort -v

You should now see information on the console for any packets that are received by your system's network adapters. You use ctrl-c command to exit from Snort.

The biggest problem is that NIDS can't detect attacks within encrypted traffic. If an organization is tasked with protecting web based services that require HTTPS or SSL connections, any attacks done over those connections (cross site scripting, injections attacks (SQL or URL), or other attacks) will not be noticed by the NIDS systems. This means that many attacks will fly under the radar of organizations that don't employ other methods of security monitoring along side their NIDS.

Another issue with NIDS is that they are notoriously noisy. Since they typically need to monitor all network traffic and report on any anomalies found within those packets many ordinary behaviors will be trapped as possibly suspicious. This eats up precious manpower as analysts must routinely determine which reported items are noise and which are truly suspicious.

Which brings us to tuning of the NIDS. This can be a tricky task as you cannot simply disregard all traffic from trusted servers, because an insider (or a very crafty hacker) could compromise a trusted system and use it to perform attacks and again you would be none the wiser. However, without proper tuning the high number of false positives will render it extremely difficult to tell when real attacks have happened.

So what's the point of all this? That Intrustion Detection Systems can play an important role in helping an organization monitor network traffic for suspicious activity, however that they should be part of an overall layered defense strategy and should not be overly relied on to provide insights in to malicious attack attempts.

I recommend that NIDS be accompanied by systems that can monitor encrypted web traffic (web server log monitoring) as well as systems that monitor the configuration of all servers in a datacenter to ensure that they don't get out of compliance with organization configuration standards and security hardening best practices.

They think this because a switch is a point to point device, which is to say that your computer only talks to the specific endpoint on the switch that it needs to and doesn't ordinarily have access to all traffic on the switch.

Unfortunately, in the real world, there are hacking/penetration tools such as Cain that allow someone running the tools to do what is called ARP (address resolution protocol) poisoning. Basically, it works by fooling the network switch in to thinking that all traffic going through the switch needs to go through the hacker's computer almost as if that computer were the gateway router for the switched segment.

This allows anyone running these tools to sniff all traffic going through a switch or to even change traffic that they are seeing (perform a man-in-the-middle attack).

Pretty scary stuff, eh?

But there are ways to mitigate this sort of risk. Many modern managed switch makers such as Cisco, Extreme, Dlink and others include a feature called DHCP snooping with their switches that allows switches to monitor MAC addresses and sense if DHCP enabled clients change their MAC addresses. Of course, since it can only monitor DHCP enabled systems, there may be workarounds to this solution by simply giving an attacking system a static IP address.

There are other solutions out there, but they can be costly (ArpDefender) or allow for monitoring only (ArpWatch).

At the end of the day, people put too much trust in the security of their systems by default when most of the systems and protocols that we use on a daily basis on the internet were designed not for security, but rather for ease of use and interoperability.

This isn't just important for those of us who might be managing IT security for corporations, but also for individuals who use public wifi hotspots on a regular basis.