|
0
|
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 <carl@five-ten-sg.com>
|
|
|
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>
|
