<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" media="screen" href="/~d/styles/rss2full.xsl"?><?xml-stylesheet type="text/css" media="screen" href="http://feeds.feedburner.com/~d/styles/itemcontent.css"?><rss xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:feedburner="http://rssnamespace.org/feedburner/ext/1.0" version="2.0"><channel><title>Stephen Reese</title><link>http://www.rsreese.com</link><atom10:link xmlns:atom10="http://www.w3.org/2005/Atom" rel="self" type="application/rss+xml" href="http://feeds.feedburner.com/rsreese" /><description>My Dark Cloud Kung Fu</description><language>en</language><lastBuildDate>Sun, 05 Feb 2012 15:35:15 PST</lastBuildDate><generator>http://wordpress.org/?v=3.3.1</generator><sy:updatePeriod xmlns:sy="http://purl.org/rss/1.0/modules/syndication/">hourly</sy:updatePeriod><sy:updateFrequency xmlns:sy="http://purl.org/rss/1.0/modules/syndication/">1</sy:updateFrequency><atom10:link xmlns:atom10="http://www.w3.org/2005/Atom" rel="self" type="application/rss+xml" href="http://feeds.feedburner.com/rsreese" /><feedburner:info uri="rsreese" /><atom10:link xmlns:atom10="http://www.w3.org/2005/Atom" rel="hub" href="http://pubsubhubbub.appspot.com/" /><geo:lat>30.092346</geo:lat><geo:long>-81.60274</geo:long><feedburner:emailServiceId>rsreese</feedburner:emailServiceId><feedburner:feedburnerHostname>http://feedburner.google.com</feedburner:feedburnerHostname><item><title>Block Command and Control requests using ASA 5500</title><link>http://feedproxy.google.com/~r/rsreese/~3/qVJ2vDuVTYo/</link><category>internet</category><category>security</category><category>asa</category><category>bot</category><category>cisco</category><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Stephen Reese</dc:creator><pubDate>Fri, 09 Dec 2011 18:26:28 PST</pubDate><guid isPermaLink="false">http://www.rsreese.com/?p=839</guid><content:encoded xmlns:content="http://purl.org/rss/1.0/modules/content/"><![CDATA[<p>I recently came across a <a href="http://packetpushers.net/netting-the-botnets-with-cisco-asa-without-a-license/">blog</a> post demonstrating how to use the <a href="http://rules.emergingthreats.net/fwrules/">Emerging Threats</a> rule sets in order to block malware calls to command and control (C&amp;C) hosts. Using the script referenced in the blog post may work fine, but I want to review and update when I feel like it via SSH. Per the Emerging Threats <a href="http://doc.emergingthreats.net/bin/view/Main/EmergingFirewallRules">wiki</a> these rules probably only need to be updated once a week but YMMV.</p>
<p>Setup the ASA (one time):</p>
<pre style="overflow: auto;"><code>configure terminal
access-list dynamic-filter_acl extended permit ip any any 
dynamic-filter enable interface outside classify-list dynamic-filter_acl 
dynamic-filter drop blacklist interface outside 
dynamic-filter blacklist </code></pre>
<p>Download the C&amp;C list from Emerging Threats:</p>
<pre style="overflow: auto;"><code>$ wget http://rules.emergingthreats.net/fwrules/emerging-PIX-CC.rules</code></pre>
<p>Convert the list to the required format:</p>
<pre style="overflow: auto;"><code>$ sed 's/ET-drop/ET-cc/g' emerging-PIX-CC.rules | egrep "^access-list ET-cc deny" \
emerging-PIX-CC.rules | sed 's/access-list ET-cc deny ip/address/g;s/host //g;s/any \
/255.255.255.255/g' | awk '{print $1,$2,$3}' &gt; emerging-PIX-CC.rules.asa</code></pre>
<p>Paste the list using Putty or similar. At current there are around 3000 rules so it takes a minute:</p>
<pre style="overflow: auto;"><code>configure terminal
no dynamic-filter blacklist
blacklist dynamic-filter blacklist
address x.x.x.x y.y.y.y</code></pre>
<p>Finally, it is important to note that there could be performance implications with implementing too many rules. Be warned you may shun legitimate sites on shared hosting providers and the like.</p>
<img src="http://feeds.feedburner.com/~r/rsreese/~4/qVJ2vDuVTYo" height="1" width="1"/>]]></content:encoded><description>I recently came across a blog post demonstrating how to use the Emerging Threats rule sets in order to block malware calls to command and control (C&amp;#38;C) hosts. Using the script referenced in the blog post may work fine, but &amp;#8230; &lt;a href="http://www.rsreese.com/block-command-and-control-requests-using-asa-5500/"&gt;Continue reading &lt;span class="meta-nav"&gt;&amp;#8594;&lt;/span&gt;&lt;/a&gt;</description><wfw:commentRss xmlns:wfw="http://wellformedweb.org/CommentAPI/">http://www.rsreese.com/block-command-and-control-requests-using-asa-5500/feed/</wfw:commentRss><slash:comments xmlns:slash="http://purl.org/rss/1.0/modules/slash/">0</slash:comments><feedburner:origLink>http://www.rsreese.com/block-command-and-control-requests-using-asa-5500/</feedburner:origLink></item><item><title>Amazon S3 Server-Side Encryption using GSUtil</title><link>http://feedproxy.google.com/~r/rsreese/~3/XaDFo6fE1SA/</link><category>security</category><category>encryption</category><category>gsutil</category><category>s3</category><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Stephen Reese</dc:creator><pubDate>Sat, 29 Oct 2011 07:39:11 PDT</pubDate><guid isPermaLink="false">http://www.rsreese.com/?p=786</guid><content:encoded xmlns:content="http://purl.org/rss/1.0/modules/content/"><![CDATA[<p>If you would like to enable <a href="http://docs.amazonwebservices.com/AmazonS3/latest/dev/UsingServerSideEncryption.html">server-side encryption</a> which is a relatively new <a href="http://aws.typepad.com/aws/2011/10/new-amazon-s3-server-side-encryption.html">feature</a> for your Amazon S3 data using GSUtil then you need specify the header value when pushing files to their cloud.</p>
<pre style="overflow: auto;"><code>$ gsutil -h "x-amz-server-side-encryption: AES256" cp /backups/files* s3://bucket</code></pre>
<p>Note that server-side encryption protects your data at rest and that Amazon is managing the keys on your behalf by default, see post <a href="http://alan.blog-city.com/amazon_s3_encryption.htm">here</a>. A better practice is to provide the encryption and decryption before and after you send and receive your data from S3.</p>
<img src="http://feeds.feedburner.com/~r/rsreese/~4/XaDFo6fE1SA" height="1" width="1"/>]]></content:encoded><description>If you would like to enable server-side encryption which is a relatively new feature for your Amazon S3 data using GSUtil then you need specify the header value when pushing files to their cloud. $ gsutil -h "x-amz-server-side-encryption: AES256" cp &amp;#8230; &lt;a href="http://www.rsreese.com/amazon-s3-server-side-encryption-using-gsutil/"&gt;Continue reading &lt;span class="meta-nav"&gt;&amp;#8594;&lt;/span&gt;&lt;/a&gt;</description><wfw:commentRss xmlns:wfw="http://wellformedweb.org/CommentAPI/">http://www.rsreese.com/amazon-s3-server-side-encryption-using-gsutil/feed/</wfw:commentRss><slash:comments xmlns:slash="http://purl.org/rss/1.0/modules/slash/">0</slash:comments><feedburner:origLink>http://www.rsreese.com/amazon-s3-server-side-encryption-using-gsutil/</feedburner:origLink></item><item><title>Block IRC and other communications with McAfee VirusScan</title><link>http://feedproxy.google.com/~r/rsreese/~3/NkPJ5FooTog/</link><category>security</category><category>antivirus</category><category>irc</category><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Stephen Reese</dc:creator><pubDate>Fri, 14 Oct 2011 22:01:27 PDT</pubDate><guid isPermaLink="false">http://www.rsreese.com/?p=765</guid><content:encoded xmlns:content="http://purl.org/rss/1.0/modules/content/"><![CDATA[<p>After taking a peak at some McAfee&#8217;s logs I decided to try mucking about with some of the Access Protection functionality, specifically IRC communication. I noticed there were a number of useful entries that could be sent to log or even block attempts and said settings are not enabled by default (see end of post). A test environment was setup using a IRC daemon on <a href="http://zeltser.com/remnux/">Remnux</a> and a <a href="http://nmap.org">Nmap</a> plug-in called <a href="http://nmap.org/svn/scripts/irc-info.nse">irc-info.nse</a>. An initial baseline scan/connect is made to confirm that a service does reside on the virtual guest.</p>
<p><a href="http://www.rsreese.com/wp-content/uploads/2011/10/scan_win.png"><img class="alignnone size-full wp-image-773" title="scan_win" src="http://www.rsreese.com/wp-content/uploads/2011/10/scan_win.png" alt="" width="545" height="459" /></a></p>
<p>The host indeed has a IRC server running. We do not want our host communicating with IRC daemons so we can leverage McAfee to help us block this attempt. First, open up the Auto Protect settings in the VirusScan console.</p>
<p><a href="http://www.rsreese.com/wp-content/uploads/2011/10/vs0.png"><img class="alignnone size-full wp-image-766" title="Virus Scan console" src="http://www.rsreese.com/wp-content/uploads/2011/10/vs0.png" alt="" width="535" height="299" /></a></p>
<p>Next, &#8220;Prevent IRC communication&#8221; was enabled as this hosts processes should not be making outgoing requests. If there were such requests from a process it could be indicative of malicious software contacting a C&amp;C.</p>
<p><a href="http://www.rsreese.com/wp-content/uploads/2011/10/vs1.png"><img class="alignnone size-full wp-image-767" title="IRC communications" src="http://www.rsreese.com/wp-content/uploads/2011/10/vs1.png" alt="" width="574" height="382" /></a></p>
<p>Now the policy is being enforced, we again test the ability to connect the remote hosts IRC service.</p>
<p><a href="http://www.rsreese.com/wp-content/uploads/2011/10/scan_fail.png"><img class="alignnone size-full wp-image-772" title="scan_fail" src="http://www.rsreese.com/wp-content/uploads/2011/10/scan_fail.png" alt="" width="570" height="375" /></a></p>
<p>Nmap is able to elicit responses from the host but is unable to complete a connection to interact with the IRC server. The last screen shot depicts log entries; a reporting, and a blocking and reporting entry.</p>
<p><a href="http://www.rsreese.com/wp-content/uploads/2011/10/vs_log.png"><img class="alignnone size-full wp-image-774" title="vs_log" src="http://www.rsreese.com/wp-content/uploads/2011/10/vs_log.png" alt="" width="609" height="159" /></a></p>
<p>Be cautious of shunning all processes for a specific check as some applications may inadvertently use a port that a malicious process would typically use. Instead, consider white-listing those or one selecting known evil.</p>
<img src="http://feeds.feedburner.com/~r/rsreese/~4/NkPJ5FooTog" height="1" width="1"/>]]></content:encoded><description>After taking a peak at some McAfee&amp;#8217;s logs I decided to try mucking about with some of the Access Protection functionality, specifically IRC communication. I noticed there were a number of useful entries that could be sent to log or &amp;#8230; &lt;a href="http://www.rsreese.com/block-irc-and-other-communications-with-mcafee-virusscan/"&gt;Continue reading &lt;span class="meta-nav"&gt;&amp;#8594;&lt;/span&gt;&lt;/a&gt;</description><wfw:commentRss xmlns:wfw="http://wellformedweb.org/CommentAPI/">http://www.rsreese.com/block-irc-and-other-communications-with-mcafee-virusscan/feed/</wfw:commentRss><slash:comments xmlns:slash="http://purl.org/rss/1.0/modules/slash/">0</slash:comments><feedburner:origLink>http://www.rsreese.com/block-irc-and-other-communications-with-mcafee-virusscan/</feedburner:origLink></item><item><title>Variance in rwfilter results from netflow v5 and YaF</title><link>http://feedproxy.google.com/~r/rsreese/~3/2eylxanA9RY/</link><category>security</category><category>netflow</category><category>silk</category><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Stephen Reese</dc:creator><pubDate>Mon, 03 Oct 2011 07:04:41 PDT</pubDate><guid isPermaLink="false">http://www.rsreese.com/?p=750</guid><content:encoded xmlns:content="http://purl.org/rss/1.0/modules/content/"><![CDATA[<p>Looking over some netflow data I notice some variance between the two sensors. Sensor s0 is v5 netflow data from a Cisco switch, s1 is from a network tap listening between a Router on a Stick and said Cisco switch. The latter is a capture from YaF listening on a promiscuous network interface. I needed some data so a movie streaming took care of this for me. Here is the first difference between the two data sources.</p>
<pre style="overflow:auto;"><code>$ rwfilter --start-date=$today --end-date=$today --proto=0-255 --pass=stdout --sensor=s0 | rwstats --protocol --top --count=5 --flows
INPUT: 675 Records for 1 Bin and 675 Total Records
OUTPUT: Top 5 Bins by Records
pro|   Records|  %Records|   cumul_%|
  6|       675|100.000000|100.000000|
$ rwfilter --start-date=$today --end-date=$today --proto=0-255 --pass=stdout --sensor=s1 | rwstats --protocol --top --count=5 --flows
INPUT: 2640 Records for 3 Bins and 2640 Total Records
OUTPUT: Top 5 Bins by Records
pro|   Records|  %Records|   cumul_%|
 17|      1927| 72.992424| 72.992424|
  6|       712| 26.969697| 99.962121|
  1|         1|  0.037879|100.000000|
</code></pre>
<p>The difference between the flow data here is the v5 data only shows TCP connections at this point where as the tap is seeing ICMP, TCP and UDP. The next set of queries are from a streaming movie which the output has been cut for brevity.</p>
<pre style="overflow:auto;"><code>$ rwfilter --start-date=$today --end-date=$today --sensor=s0 --type=all --proto=1,6,17 --pass=stdout --daddress=172.16.0.10 | rwsort --fields=bytes | rwcut --fields=sip,sport,dip,dport,bytes
                           69.241.37.66|   80|                            172.16.0.10|65184|  57713601|
                           69.241.37.66|   80|                            172.16.0.10|65183|  58666986|
                           69.241.37.66|   80|                            172.16.0.10|65183| 146904926|
                           69.241.37.66|   80|                            172.16.0.10|65184| 153098218|

$ rwfilter --start-date=$today --end-date=$today --sensor=s1 --type=all --proto=1,6,17 --pass=stdout --daddress=172.16.0.10 | rwsort --fields=bytes | rwcut --fields=sip,sport,dip,dport,bytes
                           69.241.37.66|   80|                            172.16.0.10|65183| 110759034|
                           69.241.37.66|   80|                            172.16.0.10|65184| 111370758|
                           69.241.37.66|   80|                            172.16.0.10|65183| 148760315|
                           69.241.37.66|   80|                            172.16.0.10|65184| 150597449|
</code></pre>
<p>The item to note here is the v5 netflow is reporting more bytes than the network tap for similar source and IP addresses for the respective destination IP addresses. Same results with the next filter.</p>
<pre style="overflow:auto;"><code>$ rwfilter --start-date=$today --end-date=$today --protocol=1,6,17 --sensor=s0 --type=all --pass=stdout --saddress=69.241.37.66 --daddress=172.16.0.10 | rwstats --count=10 --fields=sip,dip,scc,bytes,sport
INPUT: 4 Records for 4 Bins and 4 Total Records
OUTPUT: Top 10 Bins by Records
                                    sIP|                                    dIP|scc|     bytes|sPort|   Records|  %Records|   cumul_%|
                           69.241.37.66|                            172.16.0.10| us| 111370758|   80|         1| 25.000000| 25.000000|
                           69.241.37.66|                            172.16.0.10| us| 150597449|   80|         1| 25.000000| 50.000000|
                           69.241.37.66|                            172.16.0.10| us| 110759034|   80|         1| 25.000000| 75.000000|
                           69.241.37.66|                            172.16.0.10| us| 148760315|   80|         1| 25.000000|100.000000|
$ rwfilter --start-date=$today --end-date=$today --protocol=1,6,17 --sensor=s1 --type=all --pass=stdout --saddress=69.241.37.66 --daddress=172.16.0.10 | rwstats --count=10 --fields=sip,dip,scc,bytes,sport
INPUT: 4 Records for 4 Bins and 4 Total Records
OUTPUT: Top 10 Bins by Records
                                    sIP|                                    dIP|scc|     bytes|sPort|   Records|  %Records|   cumul_%|
                           69.241.37.66|                            172.16.0.10| us|  57713601|   80|         1| 25.000000| 25.000000|
                           69.241.37.66|                            172.16.0.10| us| 153098218|   80|         1| 25.000000| 50.000000|
                           69.241.37.66|                            172.16.0.10| us| 146904926|   80|         1| 25.000000| 75.000000|
                           69.241.37.66|                            172.16.0.10| us|  58666986|   80|         1| 25.000000|100.000000|
</code></pre>
<p>The output difference between the two sensors are minimal in most cases and a large portion could be due to traffic that the tap may have better insight to report though more analysis needs to be done using tcpdump or Wireshark. Nevertheless this should be considered when determine the senor requirements and the type of data that you would like to view reporting for. That said, any reporting is be better than none.</p>
<img src="http://feeds.feedburner.com/~r/rsreese/~4/2eylxanA9RY" height="1" width="1"/>]]></content:encoded><description>Looking over some netflow data I notice some variance between the two sensors. Sensor s0 is v5 netflow data from a Cisco switch, s1 is from a network tap listening between a Router on a Stick and said Cisco switch. &amp;#8230; &lt;a href="http://www.rsreese.com/variance-in-rwfilter-results-from-netflow-v5-and-yaf/"&gt;Continue reading &lt;span class="meta-nav"&gt;&amp;#8594;&lt;/span&gt;&lt;/a&gt;</description><wfw:commentRss xmlns:wfw="http://wellformedweb.org/CommentAPI/">http://www.rsreese.com/variance-in-rwfilter-results-from-netflow-v5-and-yaf/feed/</wfw:commentRss><slash:comments xmlns:slash="http://purl.org/rss/1.0/modules/slash/">0</slash:comments><feedburner:origLink>http://www.rsreese.com/variance-in-rwfilter-results-from-netflow-v5-and-yaf/</feedburner:origLink></item><item><title>Configure YAF on Linux for NetFlow collection from a network tap or SPAN</title><link>http://feedproxy.google.com/~r/rsreese/~3/XY1T5pFUDQ0/</link><category>security</category><category>debian</category><category>netflow</category><category>silk</category><category>yaf</category><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Stephen Reese</dc:creator><pubDate>Fri, 26 Aug 2011 14:27:54 PDT</pubDate><guid isPermaLink="false">http://www.rsreese.com/?p=738</guid><content:encoded xmlns:content="http://purl.org/rss/1.0/modules/content/"><![CDATA[<p>In a previous <a href="http://www.rsreese.com/2011/08/configure-silk-on-linux-for-netflow-collection-from-a-cisco-router/">post</a> SiLK was setup on a Debian host using NetFlow v5 from a Cisco switch. This worked well but I also have a network tap and said Cisco switch is capable of capturing data via SPAN port(s). This got me thinking about what difference I may see between the two NetFlow sources. This guide walks through setting up YAF on a Debian Linux host to receive data from a network tap or Switched Port Analyzer (SPAN) and converting it using <a href="http://tools.netsa.cert.org/yaf/index.html">Yet Another Flowmeter (YAF)</a>.</p>
<p>First, your host will need to obtain data from your network tap or SPAN port. I have two network interface cards in my box so I connected the non-management interface to the tap and started the interface without an IP in promiscuous mode. If you would like to use a SPAN port seek guidance <a href="https://www.cisco.com/en/US/products/hw/switches/ps708/products_tech_note09186a008015c612.shtml">here</a>.</p>
<p>Note that this guide assumes that you already have compiled and successfully built SiLK. If not checkout this <a href="http://www.rsreese.com/2011/08/configure-silk-on-linux-for-netflow-collection-from-a-cisco-router/">post</a>.</p>
<p>You first need <em>libfixbuf</em> &#8211; <a href="http://tools.netsa.cert.org/fixbuf/index.html">IPFIX Protocol Library</a>. Before building IPFIX will need glib2 and its respective development libraries, I did not have the latter so a little APT action takes care of that for me.</p>
<pre style="overflow:auto;"><code>$ sudo apt-get install libglib2-dev</code></pre>
<p>Building libfixbuf is straigtforward once the prerequetes are in place.</p>
<pre style="overflow:auto;"><code>$ ./configure --prefix=/usr
$ make
$ make install
</code></pre>
<p>Next we are going to build <a href="http://tools.netsa.cert.org/yaf/index.html">YAF is Yet Another Flowmeter</a> which has several prerequisites. <em>libpcap</em> needs to be installed along with its respective development libraries. I also installed the required <em>PCRE</em> required libraries for application labeling.</p>
<pre style="overflow:auto;"><code>$ sudo apt-get install libpcap-dev
$ sudo apt-get install libpcre3-dev
</code></pre>
<p>Next we can build YAF.</p>
<pre style="overflow:auto;"><code>$ ./configure --prefix=/usr --enable-applabel
$ make
$ sudo make install
</code></pre>
<p>Now that everything is ready to go we have a little housekeeping to do on the YAF configuration files. I placed the YAF configuration file in <em>/etc/silk/yaf.conf</em>. This file contains all of the setting such as which interface to listen on, IPFIX port, etc.<em><br />
</em></p>
<pre style="overflow:auto;"><code>## ------------------------------------------------------------------------
## yaf.conf
## YAF daemon startup script configuration file
## ------------------------------------------------------------------------
## Copyright (C) 2007-2011 Carnegie Mellon University. All Rights Reserved.
## ------------------------------------------------------------------------
## Authors: Brian Trammell
## ------------------------------------------------------------------------
## GNU General Public License (GPL) Rights pursuant to Version 2, June 1991
## Government Purpose License Rights (GPLR) pursuant to DFARS 252.227-7013
## ------------------------------------------------------------------------

# Must be non-empty to start YAF
ENABLED=yes

##### Capture Options ##########################################################

# Live capture type. Must be pcap, or dag for Endace DAG if YAF was built
# with libdag.
YAF_CAP_TYPE=pcap

# Live capture interface name.
YAF_CAP_IF=eth0

##### Export Options ###########################################################

# IPFIX transport protocol to use for export. Must be one of tcp or udp, or
# sctp if fixbuf was built with SCTP support.
YAF_IPFIX_PROTO=tcp

# Hostname or IP address of IPFIX collector to export flows to.
YAF_IPFIX_HOST=localhost

# If present, connect to the IPFIX collector on the specified port.
# Defaults to port 4739, the IANA-assigned port for IPFIX
YAF_IPFIX_PORT=18000

##### Logging and State Options ################################################

# Path to state location directory; contains the log and pidfiles unless
# modified by the following configuration parameters.
# Defaults to ${prefix}/var.
#YAF_STATEDIR=

# Path to PID file for YAF. Defaults to YAF_STATEDIR/yaf.pid
#YAF_PIDFILE=

# File or syslog facility name for YAF logging. If file, must be an absolute
# path to a logfile. Defaults to YAF_STATEDIR/yaf.log
#YAF_LOG=

# File or syslog facility name for YAF airdaemon logging. If file, must be an
# absolute path to a logfile. Defaults to YAF_STATEDIR/airdaemon-yaf.log
#YAF_DAEMON_LOG=

##### Miscellaneous Options ####################################################

# If present, become the specified user after starting YAF
#YAF_USER=

# Additional flags to pass to the YAF process. Use --silk --ip4-only for
# export to SiLK rwflowpack or SiLK flowcap.
YAF_EXTRAFLAGS="--silk"
</code></pre>
<p>Made sure there was a sensor definition in the <em>/netflow/silk.conf</em>.</p>
<pre style="overflow:auto;"><code>
sensor 0 s0    "v5 netflow from router"
sensor 1 s1    "YAF converted from tap"

class all
    sensors s0 s1
end class
</code></pre>
<p>The <em>/etc/silk/sensor.conf</em> configuration file also need to be updated with the new sensor definition. In this case s1 is our tap.</p>
<pre style="overflow:auto;"><code>probe s0 netflow-v5
    listen-on-port 9990
    protocol udp
    accept-from-host 172.16.0.1
end probe

sensor s0
    netflow-v5-probes s0
    internal-ipblocks 172.16.0.0/24
    external-ipblocks remainder
end sensor

probe s1 ipfix
    listen-on-port 18000
    protocol tcp
    accept-from-host 127.0.0.1
end probe

sensor s1
    ipfix-probes s1
    internal-ipblocks 172.16.0.0/24
    external-ipblocks remainder
end sensor
</code></pre>
<p>Lastly, start YAF assuming that you have rwflowpack running from the SiLK package per the previous <a href="http://www.rsreese.com/2011/08/configure-silk-on-linux-for-netflow-collection-from-a-cisco-router/">post</a>.</p>
<pre style="overflow:auto;"><code>$ sudo yaf --silk --ipfix=tcp --live=pcap --in=eth0 --out=127.0.0.1 --ipfix-port=18000 &amp;
</pre>
<p></code><br />
You should now be capturing data and converting into a format that SiLK can process via YAF.</p>
<img src="http://feeds.feedburner.com/~r/rsreese/~4/XY1T5pFUDQ0" height="1" width="1"/>]]></content:encoded><description>In a previous post SiLK was setup on a Debian host using NetFlow v5 from a Cisco switch. This worked well but I also have a network tap and said Cisco switch is capable of capturing data via SPAN port(s). &amp;#8230; &lt;a href="http://www.rsreese.com/configure-yaf-on-linux-for-netflow-collection-from-a-network-tap-or-span/"&gt;Continue reading &lt;span class="meta-nav"&gt;&amp;#8594;&lt;/span&gt;&lt;/a&gt;</description><wfw:commentRss xmlns:wfw="http://wellformedweb.org/CommentAPI/">http://www.rsreese.com/configure-yaf-on-linux-for-netflow-collection-from-a-network-tap-or-span/feed/</wfw:commentRss><slash:comments xmlns:slash="http://purl.org/rss/1.0/modules/slash/">0</slash:comments><feedburner:origLink>http://www.rsreese.com/configure-yaf-on-linux-for-netflow-collection-from-a-network-tap-or-span/</feedburner:origLink></item><item><title>Configure SiLK on Linux for NetFlow collection from a Cisco router</title><link>http://feedproxy.google.com/~r/rsreese/~3/bRr4ykpTchE/</link><category>security</category><category>cisco</category><category>debian</category><category>netflow</category><category>silk</category><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Stephen Reese</dc:creator><pubDate>Sun, 14 Aug 2011 17:43:57 PDT</pubDate><guid isPermaLink="false">http://www.rsreese.com/?p=695</guid><content:encoded xmlns:content="http://purl.org/rss/1.0/modules/content/"><![CDATA[<p>This guide walks through configuring <a href="http://tools.netsa.cert.org/silk/index.html">SiLK</a> from a source install on a <a href="http://www.debian.org/">Debian</a> 6 host in order to collect <a href="https://www.cisco.com/en/US/products/ps6601/products_ios_protocol_group_home.html">NetFlow</a> data from a Cisco router. The guides <a href="http://tools.netsa.cert.org/silk/install-handbook.html#x1-130002">here</a> and <a href="https://tools.netsa.cert.org/confluence/display/tt/Configure+SiLK+for+NetFlow+collection+from+a+Cisco+router">here</a> written by CERT <a href="https://www.cert.org/netsa/">NetSA</a> are quite good but lack some detail specific to the Debian distribution which required a bit of mucking about to get everything functioning correctly. This assumes that you have a Cisco router to send NetFlow data to a host on your network, in this case, a Debian host.</p>
<p><span style="text-decoration: underline;">Installation:</span></p>
<p>First install a prerequisite.</p>
<pre style="overflow:auto;"><code>$ sudo apt-get install libpcap-dev</code></pre>
<p>Next untar and change into the SiLK directory. For Debian I found that using the <em>/usr</em> directory worked well. By default the configure script uses <em>/usr/local</em> in which it places the binaries, libraries, etc outside of Debian&#8217;s default paths.</p>
<pre style="overflow:auto;"><code>$ ./configure --prefix=/usr --sysconfdir=/etc/silk --enable-data-rootdir=/netflow \
--enable-ipv6 --enable-output-compression</code></pre>
<p>Your output should be something along the following:</p>
<pre style="overflow:auto;"><code>    * Configured package:           SiLK 2.4.5
    * Host type:                    x86_64-unknown-linux-gnu
    * Source files ($top_srcdir):   .
    * Install directory:            /usr
    * Root of packed data tree:     /netflow
    * Packing logic:                via run-time plugin
    * Timezone support:             UTC
    * Default compression method:   SK_COMPMETHOD_ZLIB
    * IPv6 support:                 YES
    * IPFIX collection support:     YES (-pthread -lfixbuf -lgthread-2.0 -lrt -lglib-2.0)
    * Transport encryption support: NO (gnutls not found)
    * IPA support:                  NO
    * LIBPCAP support:              YES (-lpcap)
    * ADNS support:                 NO
    * Python support:               NO
    * Build analysis tools:         YES
    * Build packing tools:          YES
    * Compiler (CC):                gcc
    * Compiler flags (CFLAGS):      -I$(srcdir) -I$(top_builddir)/src/include -I$(top_srcdir)/src/include -DNDEBUG -O3 -fno-strict-aliasing -Wall -W -Wmissing-prototypes -Wformat=2 -Wdeclaration-after-statement -Wpointer-arith
    * Linker flags (LDFLAGS):
    * Libraries (LIBS):             -lz -ldl -lm</code></pre>
<p>Lastly:</p>
<pre style="overflow:auto;"><code>$ make
$ sudo make install
</code></pre>
<p><span style="text-decoration: underline;">Configuration:</span></p>
<p>Example files are available in the tarball that you extracted. Modified versions or notes for Debian and similar architectures available below.</p>
<p><em>/netflow/silk.conf</em> in your data directory, the default is <em>/data</em> but I used /netflow as you can see in the configure toggle above. The changes I made were to reduce the number of sensors.</p>
<pre style="overflow:auto;"><code>
# The syntactic format of this file
#    version 2 supports sensor descriptions, but otherwise identical to 1
version 2

sensor 0 s0    "Description for sensor S0"
sensor 1 s1

class all
    sensors s0 s1
end class

# Editing above this line is sufficient for sensor definition.
</code></pre>
<p><em>/etc/silk/sensor.conf</em> is the definition for the data coming in from your Cisco router:</p>
<pre style="overflow:auto;"><code>
probe s0 netflow-v5
    listen-on-port 9990
    protocol udp
    accept-from-host 172.16.0.1
end probe

sensor s0
    netflow-v5-probes s0
    internal-ipblocks 172.16.0.0/24
    external-ipblocks remainder
end sensor
</code></pre>
<p><em>/etc/silk/rwflowpack.conf</em>:</p>
<pre style="overflow:auto;"><code>
### Packer configuration file  -*- sh -*-
##
## The canonical pathname for this file is /usr/local/etc/rwflowpack.conf
##
## RCSIDENT("$SiLK: rwflowpack.conf.in 16306 2010-09-15 18:14:41Z mthomas $")
##
## This is a /bin/sh file that gets loaded by the init.d/rwflowpack
## wrapper script, and this file must follow /bin/sh syntax rules.

# Set to non-empty value to enable rwflowpack
ENABLED=yes

# These are convenience variables for setting other values in this
# configuration file; their use is not required.
statedirectory=/var/lib/rwflowpack

# If CREATE_DIRECTORIES is set to "yes", the directories named in this
# file will be created automatically if they do not already exist
CREATE_DIRECTORIES=yes

# Full path of the directory containing the "rwflowpack" program
BIN_DIR=/usr/sbin

# The full path to the sensor configuration file.  Used by
# --sensor-configuration.  YOU MUST PROVIDE THIS (the value is ignored
# when INPUT_MODE is "respool").
SENSOR_CONFIG=/etc/silk/sensor.conf

# The full path to the root of the tree under which the packed SiLK
# Flow files will be written.  Used by --root-directory.
DATA_ROOTDIR=/netflow

# The full path to the site configuration file.  Used by
# --site-config-file.  If not set, defaults to silk.conf in the
# ${DATA_ROOTDIR}.
SITE_CONFIG=/netflow/silk.conf

# Specify the path to the packing-logic plug-in that rwflowpack should
# load and use.  The plug-in provides functions that determine into
# which class and type each flow record will be categorized and the
# format of the files that rwflowpack will write.  When SiLK has been
# configured with hard-coded packing logic (i.e., when
# --enable-packing-logic was specified to the configure script), this
# value should be empty.  A default value for this switch may be
# specified in the ${SITE_CONFIG} site configuration file.  This value
# is ignored when INPUT_MODE is "respool".
PACKING_LOGIC=

# Data input mode.  Valid values are:
#  * "stream" mode to read from the network or from probes that have
#    poll-directories
#  * "fcfiles" to process flowcap files on the local disk
#  * "respool" to process SiLK flow files maintaining the sensor and
#    class/type values that already exist on those records.
INPUT_MODE=stream

# Directory in which to look for incoming flowcap files in "fcfiles"
# mode or for incoming SiLK files in "respool" mode
INCOMING_DIR=${statedirectory}/incoming

# Directory to move input files to after successful processing.  When
# in "stream" mode, these are the files passed to any probe with a
# poll-directory directive.  When in "fcfiles" mode, these are the
# flowcap files.  When in "respool" mode, these are the SiLK Flow
# files.  If not set, the input files are not archived but are deleted
# instead.
ARCHIVE_DIR=${statedirectory}/archive

# When using the ARCHIVE_DIR, normally files are stored in
# subdirectories of the ARCHIVE_DIR.  If this variable's value is 1,
# files are stored in ARCHIVE_DIR itself, not in subdirectories of it.
FLAT_ARCHIVE=0

# Directory to move an input file into if there is a problem opening
# the file.  If this value is not set, rwflowpack will exit when it
# encounters a problem file.  When in "fcfiles" mode, these are the
# flowcap files.  When in "stream" mode, these are the files passed to
# any probe with a poll-directory directive.
ERROR_DIR=  #${statedirectory}/error

# Data output mode.  Valid values are "local" and "remote".  "local"
# writes the hourly data files to the local disk.  "remote" creates
# small files (called incremental files) that must be processed by
# rwflowappend to create the hourly files.
OUTPUT_MODE=local

# Directory in which the incremental files are written when the
# OUTPUT_MODE is "remote".  Typically there is an rwsender deamon that
# polls this directory for new incremental files.
SENDER_DIR=${statedirectory}/sender-incoming

# Temporary directory in which to build incremental files prior to
# handing them to rwsender.  Used only when OUTPUT_MODE is "remote".
INCREMENTAL_DIR=${statedirectory}/incremental

# The type of compression to use for packed files.  Left empty, the
# value chosen at compilation time will be used.  Valid values are
# "best" and "none".  Other values are system-specific (the available
# values are listed in the description of the --compression-method
# switch in the output of rwflowpack --help).
COMPRESSION_TYPE=best

# Interval between attempts to check the INCOMING_DIR or
# poll-directory probe entries for new files, in seconds.  This may be
# left blank, and will default to 15.
POLLING_INTERVAL=

# Interval between periodic flushes of open SiLK Flow files to disk,
# in seconds.  This may be left blank, and will default to 120.
FLUSH_TIMEOUT=

# Maximum number of SiLK Flow files to have open for writing
# simultaneously.  This may be left blank, and will default to 64
FILE_CACHE_SIZE=

# Whether rwflowpack should use advisory write locks.  1=yes, 0=no.
# Set to zero if messages like "Cannot get a write lock on file"
# appear in rwflowpack's log file.
FILE_LOCKING=1

# Whether rwflowpack should include the input and output SNMP
# interfaces and the next-hop-ip in the output files.  1=yes, 0=no.
# The default is no, and these values are not stored to save disk
# space.  (The input and output fields contain VLAN tags when the
# sensor.conf file contains the attribute "interface-values vlan".)
PACK_INTERFACES=0

###

# The type of logging to use.  Valid values are "legacy" and "syslog".
LOG_TYPE=syslog

# The lowest level of logging to actually log.  Valid values are:
# emerg, alert, crit, err, warning, notice, info, debug
LOG_LEVEL=info

# The full path of the directory where the log files will be written
# when LOG_TYPE is "legacy".
LOG_DIR=/var/log

# The full path of the directory where the PID file will be written
PID_DIR=${LOG_DIR}

# The user this program runs as; root permission is required only when
# rwflowpack listens on a privileged port.
USER=root
#USER=`whoami`  # run as user invoking the script

# Extra options to pass to rwflowpack
EXTRA_OPTIONS=
</code></pre>
<p><em>/etc/init.d/rwflowback</em> directory, the only change was to line 38 in order to change to the configuration specified in the configure statement.</p>
<pre><code>SCRIPT_CONFIG_LOCATION="/etc/silk" </code></pre>
<p>With everything installed in their respective locations it is time to move on to setting up the Cisco device.</p>
<pre><code>Router(config)# ip cef
Router(config)# ip flow-export source Loopback0
Router(config)# ip flow-export version 5
Router(config)# ip flow-export destination x.x.x.x 9990
Router(config)# interface  f1/0
Router(config-if)# ip flow ingress
Router(config-if)# ip flow egress </code></pre>
<p>I hope this helps. If you have any comments or questions, leave a comment below.</p>
<img src="http://feeds.feedburner.com/~r/rsreese/~4/bRr4ykpTchE" height="1" width="1"/>]]></content:encoded><description>This guide walks through configuring SiLK from a source install on a Debian 6 host in order to collect NetFlow data from a Cisco router. The guides here and here written by CERT NetSA are quite good but lack some &amp;#8230; &lt;a href="http://www.rsreese.com/configure-silk-on-linux-for-netflow-collection-from-a-cisco-router/"&gt;Continue reading &lt;span class="meta-nav"&gt;&amp;#8594;&lt;/span&gt;&lt;/a&gt;</description><wfw:commentRss xmlns:wfw="http://wellformedweb.org/CommentAPI/">http://www.rsreese.com/configure-silk-on-linux-for-netflow-collection-from-a-cisco-router/feed/</wfw:commentRss><slash:comments xmlns:slash="http://purl.org/rss/1.0/modules/slash/">2</slash:comments><feedburner:origLink>http://www.rsreese.com/configure-silk-on-linux-for-netflow-collection-from-a-cisco-router/</feedburner:origLink></item><item><title>Setting Google Storage object ACL for authenticated downloads</title><link>http://feedproxy.google.com/~r/rsreese/~3/SVMJAJW98CQ/</link><category>internet</category><category>acl</category><category>google storage</category><category>gsutil</category><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Stephen Reese</dc:creator><pubDate>Sat, 16 Jul 2011 20:06:20 PDT</pubDate><guid isPermaLink="false">http://www.rsreese.com/?p=680</guid><content:encoded xmlns:content="http://purl.org/rss/1.0/modules/content/"><![CDATA[<p>Google&#8217;s <a href="http://code.google.com/apis/storage/docs/gsutil.html">gsutil</a> is a great tool for pushing, retrieving and setting permissions on objects uploaded to Google Storage. I was reviewing the documentation on the <a href="https://code.google.com/apis/storage/docs/collaboration.html#browser">Sharing and Collaboration</a> page, specifically the <em>Authenticated Browser Download</em> section and realized there were a couple of small mistakes, err typos. I wanted to give someone read privileges to an object via their email address. The correct format is posted in this <a href="http://pastebin.com/3KFKwnVm">Paste</a>.</p>
<p>The <strong>EmailAddress</strong> tag needs to be closed and the <strong>Permission</strong> tags need to be moved outside of the <strong>Scope</strong> tag. With all of this said I later came across <a href="https://code.google.com/apis/storage/docs/accesscontrol.html">Access Control</a> page which is documented correctly. Go figure.</p>
<img src="http://feeds.feedburner.com/~r/rsreese/~4/SVMJAJW98CQ" height="1" width="1"/>]]></content:encoded><description>Google&amp;#8217;s gsutil is a great tool for pushing, retrieving and setting permissions on objects uploaded to Google Storage. I was reviewing the documentation on the Sharing and Collaboration page, specifically the Authenticated Browser Download section and realized there were a &amp;#8230; &lt;a href="http://www.rsreese.com/setting-google-storage-object-acl-for-authenticated-downloads/"&gt;Continue reading &lt;span class="meta-nav"&gt;&amp;#8594;&lt;/span&gt;&lt;/a&gt;</description><wfw:commentRss xmlns:wfw="http://wellformedweb.org/CommentAPI/">http://www.rsreese.com/setting-google-storage-object-acl-for-authenticated-downloads/feed/</wfw:commentRss><slash:comments xmlns:slash="http://purl.org/rss/1.0/modules/slash/">0</slash:comments><feedburner:origLink>http://www.rsreese.com/setting-google-storage-object-acl-for-authenticated-downloads/</feedburner:origLink></item><item><title>Running NIX Retina and Nessus vulnerability scans with least privileges</title><link>http://feedproxy.google.com/~r/rsreese/~3/WtfjL1fxz2c/</link><category>security</category><category>linux</category><category>vulnerability scanning</category><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Stephen Reese</dc:creator><pubDate>Thu, 16 Jun 2011 19:46:23 PDT</pubDate><guid isPermaLink="false">http://www.rsreese.com/?p=589</guid><content:encoded xmlns:content="http://purl.org/rss/1.0/modules/content/"><![CDATA[<p>When you are running those vulnerability scans of Linux and UNIX hosts I hope that you are following best practices for keeping a host secure during the process. Both <a href="http://www.eeye.com/Products/Retina/Network-Security-Scanner.aspx">Retina</a> and <a href="http://www.tenable.com/products/nessus">Nessus</a> rely upon SSH in order to connect to a remote host and run a number of commands to compare the query&#8217;s to their respective databases of known issues, vulns and configuration faults. Removing the directive in the sshd_config file to enable root login is definitely not best practice, and is borderline &#8220;hacking naked&#8221;. Lucky for us both Tenable and eEye have documented the methods for running scans with su or sudo (the latter preferred).</p>
<ul>
<li><a href="http://www.eeye.com/Support/Knowledge-Base/Article.aspx?id=KB000883">Retina: How to enable SUDO support for Retina</a></li>
<li><a href="http://blog.tenablesecurity.com/2010/05/nessus-spotlight-susudo-feature.html">Nessus Spotlight: su+sudo Feature</a></li>
</ul>
<p>As the Retina publication states, you may want to limit the commands that the sudo user may run. To do this you can look at the Retina logs on your Windows client; or after a successful scan with take a peek at the NIX user history in order to determine what commands were run. This could also be useful for scripting up a self-scan for a host that may lack a SSH service. Another method may beside reviewing the scanners logs might be to check the history of the secure or messages log to determine what commands were run and successfully returned a response.</p>
<p>After determining what commands the host needs to correctly run a credentialed scan you can limit the users&#8217; <em>sudo</em> privileges in the <em>/etc/sudoers</em> file. This allows users bob and alice to execut cmd0, cmd1 and cmdn, though disables su and the ability to change to a shell that may not log correctly.</p>
<pre style="border: 1px dashed #999999; padding: 5px; overflow: auto; font-family: Andale Mono,Lucida Console,Monaco,fixed,monospace; color: #000000; background-color: #eeeeee; font-size: 12px; line-height: 14px; width: 100%;"><code>Cmnd_Alias    SHELLS = /usr/bin/sh,  /usr/bin/csh, \
/usr/bin/ksh, /usr/local/bin/tcsh, \
/usr/bin/rsh, /usr/local/bin/zsh
Cmnd_Alias    RETINA = /usr/sbin/cmd0, /usr/sbin/cmd1, /usr/sbin/cmdn
User_Alias    RETINA_USERS = alice, bob
RETINA_USERS  ALL = !/usr/bin/su, !SHELLS, RETINA</code></pre>
<p>As usual, YMMV so let me know if this is helpful or misinforming.</p>
<img src="http://feeds.feedburner.com/~r/rsreese/~4/WtfjL1fxz2c" height="1" width="1"/>]]></content:encoded><description>When you are running those vulnerability scans of Linux and UNIX hosts I hope that you are following best practices for keeping a host secure during the process. Both Retina and Nessus rely upon SSH in order to connect to &amp;#8230; &lt;a href="http://www.rsreese.com/running-nix-retina-and-nessus-vulnerability-scans-with-least-privileges/"&gt;Continue reading &lt;span class="meta-nav"&gt;&amp;#8594;&lt;/span&gt;&lt;/a&gt;</description><wfw:commentRss xmlns:wfw="http://wellformedweb.org/CommentAPI/">http://www.rsreese.com/running-nix-retina-and-nessus-vulnerability-scans-with-least-privileges/feed/</wfw:commentRss><slash:comments xmlns:slash="http://purl.org/rss/1.0/modules/slash/">0</slash:comments><feedburner:origLink>http://www.rsreese.com/running-nix-retina-and-nessus-vulnerability-scans-with-least-privileges/</feedburner:origLink></item><item><title>Use Facebook CDN to host website photo gallerys</title><link>http://feedproxy.google.com/~r/rsreese/~3/szQZxMXXBx4/</link><category>coding</category><category>facebook</category><category>photo gallery</category><category>php</category><category>web design</category><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Stephen Reese</dc:creator><pubDate>Tue, 19 Apr 2011 16:23:39 PDT</pubDate><guid isPermaLink="false">http://www.rsreese.com/?p=558</guid><content:encoded xmlns:content="http://purl.org/rss/1.0/modules/content/"><![CDATA[<p>I was thinking about how to retrieve photos from Facebook photo gallery&#8217;s and came across a number of solutions. Most of the solutions were for blog or CMS and furthermore required caching your credentials in a database along with a few other hoops in order to access your albums and display them on a third party site. I thought this was a bit odd as if you want to share photos on your blog or site you should be able to just make the album public and use Facebooks API to connect since they are going to be public at that point. After poking around this ended up being much easier than expected and it works with Facebook Fan Pages which is where I think this would be most useful.</p>
<ol>
<li>You need to create a Facebook <a href="http://developers.facebook.com/">application account</a> which will provide you with your <strong>appId</strong> and <strong>secret</strong>.</li>
<li>Next you need to get the PHP SDK from <a href="https://github.com/facebook/php-sdk/">GitHub</a>. All you need is the facebook.php page but feel free to grab the ZIP and explore. There is an example to experiment with.</li>
<li>Lastly you can use the <a href="https://code.google.com/p/facebook-cdn-photo-gallery/source/browse/trunk/index.php">code</a> provided on <a href="https://code.google.com/p/facebook-cdn-photo-gallery/">Google Code</a> as a basic start to implementing a photo gallery on your site.</li>
</ol>
<p>The code displays thumbnails, source images along with name&#8217;s (caption&#8217;s) below each image that have them and finally the source which you can use to derive other goodies that you might want to use in you gallery. Some examples are different size thumbnails, id, comments, etc.</p>
<p>*Note that the script does not parse double quotes in photo captions well at this point.</p>
<p>If you notice any issues, room for improvement or features feel free to leave a comment or post an issue over at the Google Code page.</p>
<img src="http://feeds.feedburner.com/~r/rsreese/~4/szQZxMXXBx4" height="1" width="1"/>]]></content:encoded><description>I was thinking about how to retrieve photos from Facebook photo gallery&amp;#8217;s and came across a number of solutions. Most of the solutions were for blog or CMS and furthermore required caching your credentials in a database along with a &amp;#8230; &lt;a href="http://www.rsreese.com/use-facebook-cdn-to-host-website-photo-gallerys/"&gt;Continue reading &lt;span class="meta-nav"&gt;&amp;#8594;&lt;/span&gt;&lt;/a&gt;</description><wfw:commentRss xmlns:wfw="http://wellformedweb.org/CommentAPI/">http://www.rsreese.com/use-facebook-cdn-to-host-website-photo-gallerys/feed/</wfw:commentRss><slash:comments xmlns:slash="http://purl.org/rss/1.0/modules/slash/">9</slash:comments><feedburner:origLink>http://www.rsreese.com/use-facebook-cdn-to-host-website-photo-gallerys/</feedburner:origLink></item><item><title>New blog header image</title><link>http://feedproxy.google.com/~r/rsreese/~3/lU0QCekPVfs/</link><category>web design</category><category>blog</category><category>xen</category><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Stephen Reese</dc:creator><pubDate>Tue, 12 Apr 2011 06:13:46 PDT</pubDate><guid isPermaLink="false">http://www.rsreese.com/?p=554</guid><content:encoded xmlns:content="http://purl.org/rss/1.0/modules/content/"><![CDATA[<p>I would like to take a moment and thank the guys over at <a title="Xen" href="http://www.xen.org/">Xen</a> for allowing me to use their &#8220;light bike&#8221; <a title="logo" href="http://www.xen.org/images/logos/xenhackatron_cambridge11_desktop.png">logo</a> for my blog&#8217;s header image. Please take a moment to checkout their <a title="site" href="http://www.xen.org/">site</a> for your virtualization needs.</p>
<img src="http://feeds.feedburner.com/~r/rsreese/~4/lU0QCekPVfs" height="1" width="1"/>]]></content:encoded><description>I would like to take a moment and thank the guys over at Xen for allowing me to use their &amp;#8220;light bike&amp;#8221; logo for my blog&amp;#8217;s header image. Please take a moment to checkout their site for your virtualization needs.</description><wfw:commentRss xmlns:wfw="http://wellformedweb.org/CommentAPI/">http://www.rsreese.com/new-blog-header-image/feed/</wfw:commentRss><slash:comments xmlns:slash="http://purl.org/rss/1.0/modules/slash/">0</slash:comments><feedburner:origLink>http://www.rsreese.com/new-blog-header-image/</feedburner:origLink></item></channel></rss>

