| 1 |
fox2mike 05/07/13 09:58:29 |
| 2 |
|
| 3 |
Added: xml/htdocs/doc/en/articles dynamic-iptables-firewalls.xml |
| 4 |
Log: |
| 5 |
#98620 - Common Threads - Dynamic iptables firewalls by drobbins - Initial Version. Thanks to Lukasz Damentko. |
| 6 |
|
| 7 |
Revision Changes Path |
| 8 |
1.1 xml/htdocs/doc/en/articles/dynamic-iptables-firewalls.xml |
| 9 |
|
| 10 |
file : http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/articles/dynamic-iptables-firewalls.xml?rev=1.1&content-type=text/x-cvsweb-markup&cvsroot=gentoo |
| 11 |
plain: http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/articles/dynamic-iptables-firewalls.xml?rev=1.1&content-type=text/plain&cvsroot=gentoo |
| 12 |
|
| 13 |
Index: dynamic-iptables-firewalls.xml |
| 14 |
=================================================================== |
| 15 |
<?xml version='1.0' encoding="UTF-8"?> |
| 16 |
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/articles/dynamic-iptables-firewalls.xml,v 1.1 2005/07/13 09:58:28 fox2mike Exp $ --> |
| 17 |
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> |
| 18 |
|
| 19 |
<guide link="/doc/en/articles/dynamic-iptables-firewalls.xml"> |
| 20 |
<title>Dynamic iptables firewalls</title> |
| 21 |
|
| 22 |
<author title="Author"> |
| 23 |
<mail link="drobbins@g.o">Daniel Robbins</mail> |
| 24 |
</author> |
| 25 |
<author title="Editor"> |
| 26 |
<mail link="rane@××××××.pl">Łukasz Damentko</mail> |
| 27 |
</author> |
| 28 |
|
| 29 |
<abstract> |
| 30 |
Firewalls are good and fun, but what do you do when you need to make rapid, |
| 31 |
complex changes to your firewall rules? Easy. Use Daniel Robbins' dynamic |
| 32 |
firewall scripts that are demonstrated in this article. You can use these |
| 33 |
scripts to increase your network security and responsiveness, and to inspire |
| 34 |
your own creative designs. |
| 35 |
</abstract> |
| 36 |
|
| 37 |
<!-- The original version of this article was published on IBM developerWorks, |
| 38 |
and is property of Westtech Information Services. This document is an updated |
| 39 |
version of the original article, and contains various improvements made by the |
| 40 |
Gentoo Linux Documentation team --> |
| 41 |
|
| 42 |
<version>1.0</version> |
| 43 |
<date>2005-07-13</date> |
| 44 |
|
| 45 |
<chapter> |
| 46 |
<title>Introduction</title> |
| 47 |
<section> |
| 48 |
<title>Flexible (and fun) network security</title> |
| 49 |
<body> |
| 50 |
|
| 51 |
<note> |
| 52 |
The original version of this article was published on IBM developerWorks, and is |
| 53 |
property of Westtech Information Services. This document is an updated version |
| 54 |
of the original article, and contains various improvements made by the Gentoo |
| 55 |
Linux Documentation team. |
| 56 |
</note> |
| 57 |
|
| 58 |
<p> |
| 59 |
The best way to see the benefits of dynamic firewall scripts is to see them in |
| 60 |
action. To do this, let's imagine that I'm a sysadmin at an ISP, and I've |
| 61 |
recently set up a Linux-based firewall to protect my customers and internal |
| 62 |
systems from malicious users on the Internet. To do this, my firewall uses the |
| 63 |
new Linux 2.4 iptables stateful functionality to allow new outgoing connections |
| 64 |
to be established by my customers and servers, and of course to allow new |
| 65 |
incoming connections, but only to "public" services, such as web, ftp, ssh, and |
| 66 |
SMTP. Since I used a deny-by-default design, any from-Internet connections to |
| 67 |
non-public services, such as the squid proxy cache or Samba server, are |
| 68 |
automatically rejected. So far, I have a pretty decent firewall that offers a |
| 69 |
good level of protection for everyone at my ISP. |
| 70 |
</p> |
| 71 |
|
| 72 |
<p> |
| 73 |
For the first week or so, the firewall works great, but then something ugly |
| 74 |
happens: Bob, my arch-nemesis (who works at a competing ISP) decides that he |
| 75 |
wants to flood my network with packets in an attempt to deny service to my |
| 76 |
customers. Unfortunately, Bob has carefully studied my firewall and knows that |
| 77 |
while I'm protecting many internal services, port 25 and 80 must be publicly |
| 78 |
accessible so that I can receive mail and serve HTTP requests. Bob decides to |
| 79 |
take advantage of this fact by launching a bandwidth-sucking attack against my |
| 80 |
web and mail server. |
| 81 |
</p> |
| 82 |
|
| 83 |
<p> |
| 84 |
About a minute or so after Bob begins his attack, I notice that my uplinks start |
| 85 |
becoming saturated with packets. After taking a look at the situation with |
| 86 |
<c>tcpdump</c> I determine that this is yet another Bob attack, and I figure out |
| 87 |
what IP addresses he's using to launch it. Now that I have this information, all |
| 88 |
that I need to do is block these IP addresses, and that should solve the problem |
| 89 |
-- a simple solution, or so I think. |
| 90 |
</p> |
| 91 |
|
| 92 |
</body> |
| 93 |
</section> |
| 94 |
|
| 95 |
<section> |
| 96 |
<title>Responding to an attack</title> |
| 97 |
<body> |
| 98 |
|
| 99 |
<p> |
| 100 |
I quickly load my firewall setup script into vi and begin hacking away at my |
| 101 |
iptables rules, modifying my firewall so that it'll block those evil incoming |
| 102 |
Bob packets. After a minute or so, I find the exact place to make the |
| 103 |
appropriate DROP rule additions, and I add them. Then, I start and stop the |
| 104 |
firewall...ooops, made a bit of a mistake when I added the rules. I load up the |
| 105 |
firewall scripts again, fix the problem, and thirty seconds later the firewall |
| 106 |
has been tweaked to block Bob's attack of the month. At first, it seems like I |
| 107 |
successfully thwarted the attack...until the helpdesk phones begin ringing. |
| 108 |
Apparently, Bob was able to disrupt my network for about 10 minutes, and now my |
| 109 |
customers are calling to find out what's going on. Even worse, after a few |
| 110 |
minutes pass, I notice that our uplinks again start to become saturated. This |
| 111 |
time, Bob appears to be using a brand-new set of IP addresses for his attacks. |
| 112 |
In response, I begin feverishly hacking away at our firewall scripts, except |
| 113 |
this time, I'm a bit panicky -- maybe my solution isn't so good after all. |
| 114 |
</p> |
| 115 |
|
| 116 |
<p> |
| 117 |
Here's what went wrong in the above scenario. Although I had a decent firewall |
| 118 |
in place and also quickly identified the cause of the network problem, I was |
| 119 |
unable to modify the behavior of my firewall to respond to the threat in time. |
| 120 |
Of course, when your network is under attack, you want to be able to respond |
| 121 |
immediately, and being forced to hack away at your master firewall setup script |
| 122 |
in a panicked state is not only stressful, but also very inefficient. |
| 123 |
</p> |
| 124 |
|
| 125 |
</body> |
| 126 |
</section> |
| 127 |
</chapter> |
| 128 |
|
| 129 |
<chapter> |
| 130 |
<title>Scripts</title> |
| 131 |
<section> |
| 132 |
<title>ipdrop</title> |
| 133 |
<body> |
| 134 |
|
| 135 |
<p> |
| 136 |
It would be far better if I had a special <c>ipdrop</c> script that's |
| 137 |
specifically designed to insert just the rules you need to block the IP address |
| 138 |
that I specify. With such a script, blocking a firewall is no longer a |
| 139 |
two-minute ordeal; instead, it takes five seconds. And since the script shields |
| 140 |
me from the task of editing firewall rules by hand, it eliminates a major source |
| 141 |
of errors. All that's left for me to do is to determine the IP address that I'd |
| 142 |
like to block, and then type: |
| 143 |
</p> |
| 144 |
|
| 145 |
<pre caption="Dropping IP"> |
| 146 |
# <i>ipdrop 129.24.8.1 on</i> |
| 147 |
IP 129.24.8.1 drop on. |
| 148 |
</pre> |
| 149 |
|
| 150 |
<p> |
| 151 |
Immediately, the ipdrop script would block 129.24.8.1, Bob's current evil IP |
| 152 |
address of the week. This script dramatically improves your defenses, because |
| 153 |
now an IP block is a no-brainer. Now, let's take a look at my implementation of |
| 154 |
the ipdrop script: |
| 155 |
</p> |
| 156 |
|
| 157 |
<pre caption="ipdrop script"> |
| 158 |
#!/bin/bash |
| 159 |
|
| 160 |
source /usr/local/share/.sh |
| 161 |
|
| 162 |
args 2 $# "${0} IPADDR {on/off}" |
| 163 |
|
| 164 |
<comment># Drops packets to/from IPADDR. Good for obnoxious |
| 165 |
networks/hosts/DoS"</comment> |
| 166 |
|
| 167 |
if [ "$2" == "on" ] |
| 168 |
then |
| 169 |
<comment># Rules will be appended or inserted as normal</comment> |
| 170 |
APPEND="-A" |
| 171 |
INSERT="-I" |
| 172 |
rec_check ipdrop $1 "$1 already blocked" on |
| 173 |
record ipdrop $1 |
| 174 |
elif [ "$2" == "off" ] |
| 175 |
then |
| 176 |
<comment># Rules will be deleted instead</comment> |
| 177 |
APPEND="-D" |
| 178 |
INSERT="-D" |
| 179 |
rec_check ipdrop $1 "$1 not currently blocked" off |
| 180 |
unrecord ipdrop $1 |
| 181 |
else |
| 182 |
echo "Error: \"off\" or \"on\" expected as second argument" |
| 183 |
exit 1 |
| 184 |
fi |
| 185 |
|
| 186 |
<comment># Block outside IP address that's causing problems</comment> |
| 187 |
<comment># Attacker's incoming TCP connections will take a minute or so to time |
| 188 |
out, reducing DoS effectiveness</comment> |
| 189 |
|
| 190 |
iptables $INSERT INPUT -s $1 -j DROP |
| 191 |
iptables $INSERT OUTPUT -d $1 -j DROP |
| 192 |
iptables $INSERT FORWARD -d $1 -j DROP |
| 193 |
iptables $INSERT FORWARD -s $1 -j DROP |
| 194 |
|
| 195 |
echo "IP ${1} drop ${2}." |
| 196 |
</pre> |
| 197 |
|
| 198 |
</body> |
| 199 |
</section> |
| 200 |
|
| 201 |
<section> |
| 202 |
<title>ipdrop: the explanation</title> |
| 203 |
<body> |
| 204 |
|
| 205 |
<p> |
| 206 |
If you take a look at the last four highlighted lines, you'll see the actual |
| 207 |
commands that insert the appropriate rules into the firewall tables. As you can |
| 208 |
see, the definition of the $INSERT environment variable varies, depending on |
| 209 |
whether we're running in "on" or "off" mode. When the iptables lines execute, |
| 210 |
the particular rules will be inserted or deleted appropriately. |
| 211 |
</p> |
| 212 |
|
| 213 |
<p> |
| 214 |
|
| 215 |
|
| 216 |
|
| 217 |
-- |
| 218 |
gentoo-doc-cvs@g.o mailing list |
Archives