Mercurial > routeflapper
diff html/rn01re01.html @ 0:48d06780cf77
initial version
| author | Carl Byington <carl@five-ten-sg.com> |
|---|---|
| date | Tue, 13 May 2008 14:03:10 -0700 |
| parents | |
| children |
line wrap: on
line diff
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/html/rn01re01.html Tue May 13 14:03:10 2008 -0700 @@ -0,0 +1,121 @@ +<?xml version="1.0" encoding="UTF-8" standalone="no"?> +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> +<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>routeflapper</title><meta name="generator" content="DocBook XSL Stylesheets V1.65.1" /><link rel="home" href="index.html" title="routeflapper" /><link rel="up" href="index.html" title="routeflapper" /><link rel="previous" href="index.html" title="routeflapper" /><link rel="next" href="rn01re02.html" title="routeflapper.conf" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">routeflapper</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="index.html">Prev</a> </td><th width="60%" align="center"> </th><td width="20%" align="right"> <a accesskey="n" href="rn01re02.html">Next</a></td></tr></table><hr /></div><div class="refentry" lang="en" xml:lang="en"><a id="routeflapper.1"></a><div class="titlepage"><div></div><div></div></div><div class="refnamediv"><a id="name.1"></a><h2>Name</h2><p>routeflapper — detects suspicious routes</p></div><div class="refsynopsisdiv"><a id="synopsis.1"></a><h2>Synopsis</h2><div class="cmdsynopsis"><p><tt class="command">routeflapper</tt> [<tt class="option">-c</tt>] [<tt class="option">-d <i class="replaceable"><tt>n</tt></i></tt>]</p></div></div><div class="refsect1" lang="en" xml:lang="en"><a id="description.1"></a><h2>Description</h2><p><span><b class="command">routeflapper</b></span> is a daemon that monitors BGP + updates and SMTP connections to discover whether SMTP connections are + coming from ip addresses whose best route is suspicious. </p><p>The <span class="citerefentry"><span class="refentrytitle">routeflapper.conf</span>(5)</span> file specifies the syslog files + to be monitored, and the regular expressions (<span class="citerefentry"><span class="refentrytitle">regex</span>(7)</span>) to be applied to new lines in those files. </p><p>The discussion has focused on syslog files, but any ascii text + file can be used, so long as some other process appends lines to that + file, and those lines containing bgp updates can be matched + with some regular expression.</p><p>Considering syslog files in particular, these are normally rotated + via logrotate. <span><b class="command">routeflapper</b></span> properly detects and + handles this case by closing the old file, and reopening the newly + created file.</p></div><div class="refsect1" lang="en" xml:lang="en"><a id="options.1"></a><h2>Options</h2><div class="variablelist"><dl><dt><span class="term">-c</span></dt><dd><p> + Load the configuration file, print a cannonical form + of the configuration on stdout, and exit. + </p></dd><dt><span class="term">-d <i class="replaceable"><tt>n</tt></i></span></dt><dd><p> + Set the debug level to <i class="replaceable"><tt>n</tt></i>. + </p></dd></dl></div></div><div class="refsect1" lang="en" xml:lang="en"><a id="usage.1"></a><h2>Usage</h2><p><span><b class="command">routeflapper</b></span> -d 2</p></div><div class="refsect1" lang="en" xml:lang="en"><a id="configuration.1"></a><h2>Configuration</h2><p> + The configuration file is documented in <span class="citerefentry"><span class="refentrytitle">routeflapper.conf</span>(5)</span>. Any change to the config file will cause it to be + reloaded within three minutes. + </p></div><div class="refsect1" lang="en" xml:lang="en"><a id="introduction.1"></a><h2>Introduction</h2><p> + Consider the hypothetical case of a spammer who is connected via a + provider that does not filter BGP routing announcements. The spammer + then has some options to announce ip address space to be used for + sending spam. Note that we only consider cases where the spammer + simply wants to anonymously use some ip address space. This is very + different from the case where the attacker wants to use some specific + address space belonging to another organization in order to impersonate + some service provided by that other organization. + </p><p> + They can announce a more specific route, for example a /24, inside a + larger block. For example, consider 169.232.0.0/16. If the spammer + pokes around, they can probably find an unused /24 in there. So they + announce 169.232.240.0/24 and then send spam from that block. There + are two problems with this scheme. First, the announcement of such a + smaller block may be filtered out by many BGP routers, reducing their + reachability to their spam targets. Second, they may have made a + mistake, and that /24 is actually in use by some UCLA service that + will notice their hijack. + </p><p> + They can announce a less specific route, for example a /16, covering + some individual smaller blocks. For example, they could announce + 52.129.0.0/16. The spammer could then avoid the four existing + announcements inside that block, and instead spam from + 52.129.128.0/17. That gives them 32K ip addresses to work with. The + advantage here is that their announcement of a large block won't be + filtered out by as many (if any) BGP routers, giving them better reachability + to their spam targets. And they know they won't interfere with any + existing use of that address space, since there was no previous BGP + announcement of that /17 or any subset of it. + </p><p> + Or they can simply announce a prefix that is not assigned to anyone. + For example, they could simply start announcing 185.10.0.0/16. This + has many of the same advantages as the previous scheme, but some BGP + routers may be configured to drop such bogon announcements. + </p><p> + In each of these cases, the spammer can use BGP to announce some + address space, then send spam from those addresses, and then withdraw + the route annoucement. This would make it difficult for the recipient of + such spam to determine who actually sent it. + </p><p> + In a paper from 2006 published at <a href="http://www-static.cc.gatech.edu/~feamster/publications/p396-ramachandran.pdf" target="_top"> + http://www-static.cc.gatech.edu/~feamster/publications/p396-ramachandran.pdf + </a>, Ramachandran and Feamster claim evidence for the statement + that spammers are using such short-lived bogus BGP route announcements + to send spam from hijacked parts of the IPv4 address space. + </p><p> + The question is, are spammers actually doing this today, or is this + just a hypothetical spam tactic that they could use in the future? To + help answer that question, this package monitors BGP annoucements, + classifies some of them as suspicious, and logs instances of SMTP + connections from suspicious prefixes. + </p><p> + We track the history of the AS adjacency graph, by computing the union + of all AS adjacent pairs over all the announced prefixes. For example, + 137.169.0.0/16 is currently announced here with an AS path of '22298 + 19080 3549 6517 14981', so we add (22298,19080) (19080,3549) + (3549,6517) and (6517,14981) as valid adjacent AS pairs. + </p><p> + We track the history of the origin AS for each announced prefix. Both + the origin AS and AS adjacency pairs are tracked over a timescale of + 100 hours, with an exponential decay half-life of 100 hours. + </p><p> + A prefix announcement is suspicious if the origin AS is not in the + historical AS set for that prefix at least 20% of the time, or if the + AS path contains any adjacent AS pair that is not in the historical AS + adjacency graph at least 40% of the time. + </p><p> + <a href="http://phas.netsec.colostate.edu/" target="_top">PHAS</a> is another + system that attempts to detect address space hijacking, but it is not + correlated with SMTP connections or spam attempts. + </p><p> + <a href="http://cs.unm.edu/~karlinjf/IAR/index.php" target="_top">IAR</a> is + another system that attempts to detect address space hijacking, but it + is not correlated with SMTP connections or spam attempts. IAR uses + methods detailed in <a href="http://www.cs.unm.edu/~treport/tr/06-06/pgbgp3.pdf" target="_top">PGBGP</a> + to detect suspicious routes. One problem with PGBGP as applied to our + hypothetical spammer problem, is that PGBGP is primarily looking for + hijacks where the attacker actually wants some specific ip address + space, either for a denial of service, or to impersonate the actual + owner. Our hypothetical spammer does not care about that - they only + care about sending spam anonymously. In particular, PGBGP ignores + super-prefix hijacks, but it seems likely that that is the preferred + method for our hypothetical spammer. However, the PGBGP paper does provide + useful data on the required timescale to avoid most of the normal AS + origin changes. + </p></div><div class="refsect1" lang="en" xml:lang="en"><a id="todo.1"></a><h2>TODO</h2><p> + None. + </p></div><div class="refsect1" lang="en" xml:lang="en"><a id="copyright.1"></a><h2>Copyright</h2><p> + Copyright (C) 2008 by 510 Software Group <carl@five-ten-sg.com> + </p><p> + This program is free software; you can redistribute it and/or modify it + under the terms of the GNU General Public License as published by the + Free Software Foundation; either version 3, or (at your option) any + later version. + </p><p> + You should have received a copy of the GNU General Public License along + with this program; see the file COPYING. If not, please write to the + Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA. + </p></div><div class="refsect1" lang="en" xml:lang="en"><a id="version.1"></a><h2>Version</h2><p> + 1.0.1 + </p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="index.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="index.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="rn01re02.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">routeflapper </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> routeflapper.conf</td></tr></table></div></body></html>