Mercurial > routeflapper

comparison html/rn01re01.html @ 0:48d06780cf77

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
initial version
author Carl Byington <carl@five-ten-sg.com>
date Tue, 13 May 2008 14:03:10 -0700
parents
children
comparison
equal deleted inserted replaced
-1:000000000000 0:48d06780cf77
1 <?xml version="1.0" encoding="UTF-8" standalone="no"?>
2 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
3 <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
4 updates and SMTP connections to discover whether SMTP connections are
5 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
6 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
7 file can be used, so long as some other process appends lines to that
8 file, and those lines containing bgp updates can be matched
9 with some regular expression.</p><p>Considering syslog files in particular, these are normally rotated
10 via logrotate. <span><b class="command">routeflapper</b></span> properly detects and
11 handles this case by closing the old file, and reopening the newly
12 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>
13 Load the configuration file, print a cannonical form
14 of the configuration on stdout, and exit.
15 </p></dd><dt><span class="term">-d <i class="replaceable"><tt>n</tt></i></span></dt><dd><p>
16 Set the debug level to <i class="replaceable"><tt>n</tt></i>.
17 </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>
18 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
19 reloaded within three minutes.
20 </p></div><div class="refsect1" lang="en" xml:lang="en"><a id="introduction.1"></a><h2>Introduction</h2><p>
21 Consider the hypothetical case of a spammer who is connected via a
22 provider that does not filter BGP routing announcements. The spammer
23 then has some options to announce ip address space to be used for
24 sending spam. Note that we only consider cases where the spammer
25 simply wants to anonymously use some ip address space. This is very
26 different from the case where the attacker wants to use some specific
27 address space belonging to another organization in order to impersonate
28 some service provided by that other organization.
29 </p><p>
30 They can announce a more specific route, for example a /24, inside a
31 larger block. For example, consider 169.232.0.0/16. If the spammer
32 pokes around, they can probably find an unused /24 in there. So they
33 announce 169.232.240.0/24 and then send spam from that block. There
34 are two problems with this scheme. First, the announcement of such a
35 smaller block may be filtered out by many BGP routers, reducing their
36 reachability to their spam targets. Second, they may have made a
37 mistake, and that /24 is actually in use by some UCLA service that
38 will notice their hijack.
39 </p><p>
40 They can announce a less specific route, for example a /16, covering
41 some individual smaller blocks. For example, they could announce
42 52.129.0.0/16. The spammer could then avoid the four existing
43 announcements inside that block, and instead spam from
44 52.129.128.0/17. That gives them 32K ip addresses to work with. The
45 advantage here is that their announcement of a large block won't be
46 filtered out by as many (if any) BGP routers, giving them better reachability
47 to their spam targets. And they know they won't interfere with any
48 existing use of that address space, since there was no previous BGP
49 announcement of that /17 or any subset of it.
50 </p><p>
51 Or they can simply announce a prefix that is not assigned to anyone.
52 For example, they could simply start announcing 185.10.0.0/16. This
53 has many of the same advantages as the previous scheme, but some BGP
54 routers may be configured to drop such bogon announcements.
55 </p><p>
56 In each of these cases, the spammer can use BGP to announce some
57 address space, then send spam from those addresses, and then withdraw
58 the route annoucement. This would make it difficult for the recipient of
59 such spam to determine who actually sent it.
60 </p><p>
61 In a paper from 2006 published at <a href="http://www-static.cc.gatech.edu/~feamster/publications/p396-ramachandran.pdf" target="_top">
62 http://www-static.cc.gatech.edu/~feamster/publications/p396-ramachandran.pdf
63 </a>, Ramachandran and Feamster claim evidence for the statement
64 that spammers are using such short-lived bogus BGP route announcements
65 to send spam from hijacked parts of the IPv4 address space.
66 </p><p>
67 The question is, are spammers actually doing this today, or is this
68 just a hypothetical spam tactic that they could use in the future? To
69 help answer that question, this package monitors BGP annoucements,
70 classifies some of them as suspicious, and logs instances of SMTP
71 connections from suspicious prefixes.
72 </p><p>
73 We track the history of the AS adjacency graph, by computing the union
74 of all AS adjacent pairs over all the announced prefixes. For example,
75 137.169.0.0/16 is currently announced here with an AS path of '22298
76 19080 3549 6517 14981', so we add (22298,19080) (19080,3549)
77 (3549,6517) and (6517,14981) as valid adjacent AS pairs.
78 </p><p>
79 We track the history of the origin AS for each announced prefix. Both
80 the origin AS and AS adjacency pairs are tracked over a timescale of
81 100 hours, with an exponential decay half-life of 100 hours.
82 </p><p>
83 A prefix announcement is suspicious if the origin AS is not in the
84 historical AS set for that prefix at least 20% of the time, or if the
85 AS path contains any adjacent AS pair that is not in the historical AS
86 adjacency graph at least 40% of the time.
87 </p><p>
88 <a href="http://phas.netsec.colostate.edu/" target="_top">PHAS</a> is another
89 system that attempts to detect address space hijacking, but it is not
90 correlated with SMTP connections or spam attempts.
91 </p><p>
92 <a href="http://cs.unm.edu/~karlinjf/IAR/index.php" target="_top">IAR</a> is
93 another system that attempts to detect address space hijacking, but it
94 is not correlated with SMTP connections or spam attempts. IAR uses
95 methods detailed in <a href="http://www.cs.unm.edu/~treport/tr/06-06/pgbgp3.pdf" target="_top">PGBGP</a>
96 to detect suspicious routes. One problem with PGBGP as applied to our
97 hypothetical spammer problem, is that PGBGP is primarily looking for
98 hijacks where the attacker actually wants some specific ip address
99 space, either for a denial of service, or to impersonate the actual
100 owner. Our hypothetical spammer does not care about that - they only
101 care about sending spam anonymously. In particular, PGBGP ignores
102 super-prefix hijacks, but it seems likely that that is the preferred
103 method for our hypothetical spammer. However, the PGBGP paper does provide
104 useful data on the required timescale to avoid most of the normal AS
105 origin changes.
106 </p></div><div class="refsect1" lang="en" xml:lang="en"><a id="todo.1"></a><h2>TODO</h2><p>
107 None.
108 </p></div><div class="refsect1" lang="en" xml:lang="en"><a id="copyright.1"></a><h2>Copyright</h2><p>
109 Copyright (C) 2008 by 510 Software Group &lt;carl@five-ten-sg.com&gt;
110 </p><p>
111 This program is free software; you can redistribute it and/or modify it
112 under the terms of the GNU General Public License as published by the
113 Free Software Foundation; either version 3, or (at your option) any
114 later version.
115 </p><p>
116 You should have received a copy of the GNU General Public License along
117 with this program; see the file COPYING. If not, please write to the
118 Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.
119 </p></div><div class="refsect1" lang="en" xml:lang="en"><a id="version.1"></a><h2>Version</h2><p>
120 1.0.1
121 </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>