Rsyslog Configuration

While working on a system that sends events to an ELA (Event Log Analyser) Server, I had to start filtering the events that were sent. I noticed this after sending all events (*.* in rsyslog) to the server and seeing 218,000 hits in 30 seconds. Apparently rsyslog logs everything from kernel events to authentication issues, and network traffic. This filled up the event log incredibly quickly. Just browsing the web for a few moments resulted in thousands of messages being saved in the event log. In addition, ever broadcast and multicast from every machine was logged. For my system and remote monitoring, this was not feasible.

As you can see, there are multiple entries for broadcast MACs. I do not want to log these. So, I set out on what would become a two-hour adventure on rsyslog and conditional filtering.

First, I discovered that Ubuntu uses rsyslog rather than the older syslog. Essentially, what I wanted to do was send all events to an ELA manager except for the broadcast and multicast messages (note: this computer is not for web browsing. If yours is, you will want to filter out web traffic as well or risk seeing millions of messages).

Before sending all of my information to an ELA Server (I remembered what happened last time I did that), I needed a way to see what messages would be sent and filtered. Enter "xconsole." Xconsole allows you to view messages that are being sent to the console. To run it, open up a command prompt and type:

sudo xconsole


This will open the console window. Leave this open while testing.

Ubunut stores its rsyslog settings in two places. The first is rsyslog.conf which is stored in /etc. However, it references/includes a file "50-default.conf" which is stored in /etc/rsyslog.d. To open that file and begin our edits type this in a command prompt (open a new command prompt tab so we don't close the xconsole)

sudo gedit /etc/rsyslog.d/50-default.conf


This will open a text editor. This file originally looks like this:

#Test logging to temp log
#*.*;kern.none    /dev/console
*.*    /dev/console

#LOG to remote host ELA
#*.* @10.10.92.33

#  Default rules for rsyslog.
#
#            For more information see rsyslog.conf(5) and /etc/rsyslog.conf

#
# First some standard log files.  Log by facility.
#
auth,authpriv.*            /var/log/auth.log
*.*;auth,authpriv.none        -/var/log/syslog
#cron.*                /var/log/cron.log
#daemon.*            -/var/log/daemon.log
kern.*                -/var/log/kern.log
#lpr.*                -/var/log/lpr.log
mail.*                -/var/log/mail.log
#user.*                -/var/log/user.log

#
# Logging for the mail system.  Split it up so that
# it is easy to write scripts to parse these files.
#
#mail.info            -/var/log/mail.info
#mail.warn            -/var/log/mail.warn
mail.err            /var/log/mail.err

#
# Logging for INN news system.
#
news.crit            /var/log/news/news.crit
news.err            /var/log/news/news.err
news.notice            -/var/log/news/news.notice

#
# Some "catch-all" log files.
#
#*.=debug;\
#    auth,authpriv.none;\
#    news.none;mail.none    -/var/log/debug
#*.=info;*.=notice;*.=warn;\
#    auth,authpriv.none;\
#    cron,daemon.none;\
#    mail,news.none        -/var/log/messages

#
# Emergencies are sent to everybody logged in.
#
*.emerg                *

#
# I like to have messages displayed on the console, but only on a virtual
# console I usually leave idle.
#
#daemon,mail.*;\
#    news.=crit;news.=err;news.=notice;\
#    *.=debug;*.=info;\
#    *.=notice;*.=warn    /dev/tty8

# The named pipe /dev/xconsole is for the `xconsole' utility.  To use it,
# you must invoke `xconsole' with the `-file' option:
#
#    $ xconsole -file /dev/xconsole [...]
#
# NOTE: adjust the list below, or you'll go crazy if you have a reasonably
#      busy site..
#
daemon.*;mail.*;\
    news.err;\
    *.=debug;*.=info;\
    *.=notice;*.=warn    |/dev/xconsole

This is the original file. We are going to be adding all of our rules to the top. Here are the edits I made to the file. These edits drop all messages matching a rule before logging them.

#Test logging to console with /dev/console.
#Then open CLI and do sudo xconsole to watch output

#Drop all packets containing information matching below. Then write.
:msg, contains, "DST=10.10.92.255"
& ~
:msg, contains, "DST=255.255.255.255"
& ~
:msg, contains, "DST=224.0.0.251"
& ~
*.*    /dev/console

#LOG to remote host ELA
*.* @10.10.92.3


The line for logging to the ELA can be commented out while you test this. The line with /dev/console will write to the xconsole window. Now we need to save it and restart the service. Save the file in the text editor, exit, and then issue:

sudo service rsyslog restart


That will begin throwing messages to your xconsole. If it works, you can comment out that line and then send the messages just to the ELA.

Here are some links that were used as sources. However, I wrote this post because none of the sources I found addressed multiple rules directly.
http://www.rsyslog.com/doc/rsyslog_conf_filter.html
http://www.rsyslog.com/doc/rsyslog_conf_examples.html
http://www.rsyslog.com/discarding-unwanted-messages/
http://people.redhat.com/pvrabec/rpms/rsyslog/rsyslog-example.conf

Potential Facebook Security Issue

Facebook introduced its tagging feature (in wall posts) not too long ago. Since then, almost everyone I know on Facebook has learned to tag their friends in both status updates and comments. But one thing that I haven't seen much of, yet something that could be a security concern, is the ability to tag pages in wall posts using the '@' reference. This works well when the page is on Facebook, such as the company's official Facebook page or a product or service. Here is an example of tagging a company's page on Facebook:

When the user presses 'enter,' the tag is converted into a link that takes anyone clicking it to the official Grooveshark Facebook page.

The word "Grooveshark" becomes a link that directs the user clicking it to the Facebook page for Grooveshark. However, not all pages are contained within Facebook. For example, prior to recent changes (Facebook changed the "liked" links into wall post stories rather than a recent activity), a "page" could be created from any page on the web with Facebook's like button installed. Here is an example from Blogspot blog with a random post.

(Keep in mind that this only works with pages that have been "liked" previously and does not work with new posts).

Clicking "Like" under the post causes a post to be made to your Facebook profile wall saying that "user x likes page y." However, in this case, it simply says "User X likes 'did that five year old I just saw have a cell phone?'" The name of the page is a clickable link redirecting to the original blog page (as it should for viral purposes). Now here is where the potential vulnerability comes into play. Since Facebook treats these older "likes" as pages, the user can "tag" the page as well.

This creates a link, which is posted on the user's wall to the original blog post.

So essentially, this creates a problem because we have links that are masked by text (the same way they are around the web). However, this is especially problematic on Facebook because users will almost always click a link posted by their friends without investigating the underlying URL. It is important to remember that the owner of the original blog post still has complete control over that web page. He or she can redirect it, add malicious code, etc., and there is nothing Facebook can do about it.

Now imagine if the above link said "This video is hilarious!" It looks like a trustworthy post from a friend. But in reality, it's a post made by a rogue application that obtained permissions to post to the user's wall. The text "This video is hilarious!" could redirect to any page on the web.

Fortunately, this problem is not a large one. First, it is hindered by the fact that very few users are aware that they can tag pages. Secondly, Facebook has stopped treating new "likes" as pages and instead treats them as links, displaying their full URLs. However, the problem can still exist on older pages, of which there are millions.

To protect against this threat, always be aware of where the link is going. On Facebook (and any other site), hovering over the link reveals the URL at the bottom of the screen.

This isn't a major security issue with Facebook, nor will it probably be corrected. However, it is important to continually monitor Facebook before clicking any links.