Date: Wed, 19 Sep 2001 14:01:22 -0400 (EDT) From: Rob Simmons <rsimmons@wlcg.com> To: Brett Glass <brett@lariat.org> Cc: <security@FreeBSD.ORG> Subject: Re: Defense against "Code Rainbow" Message-ID: <20010919135456.M62587-100000@mail.wlcg.com> In-Reply-To: <4.3.2.7.2.20010919112438.0598b8b0@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 This poses the same problem as allowing snort, or snort-like NIDS systems access to your firewall rules. It opens a new window for DOS attacks. If some nefarious person figured out that you are doing such a thing, they could spoof attacks from many addresses and cripple the server. A much better approach is something like hogwash, which will only block the attack itself, allowing all normal traffic to pass. http://hogwash.sourceforge.net/ There was traffic on this list about making a freebsd port of the software, but that is not needed, just grab the source and compile :) Robert Simmons Systems Administrator http://www.wlcg.com/ On Wed, 19 Sep 2001, Brett Glass wrote: > I'm working on an automatic defense against "Code Rainbow" and would > appreciate suggestions about how to refine it so that others can use it. > > My first quick-and-dirty attempt was to create an ErrorDocument for > Apache that was not actually a document but rather a CGI script. If the > script saw that the error was not "Code Rainbow," it sent back a standard > error code. But if it recognized a "Code Rainbow" attack, it blackholed > the attacker's IP address (available to CGI programs via the REMOTE_ADDR > environment variable) via the system routing table and dropped the > connection... cold. Bingo -- the attacking machine was locked out. (To > give the CGI script the ability to change the routing table safely, I had > to create a setuid program that could be invoked only by the CGI script > and could do nothing but add a blackhole route.) > > Unfortunately, there was a serious problem with this approach. The BSD > TCP/IP stack apparently does not expect its routing table to be very big, > and so scans it linearly. This means that, as the list of blackhole > routes grew, we started to see serious problems with network performance. > I tried creating ipfw rules instead, but discovered that ipfw scans > linearly too. What does ipf use? pf? Any ideas for speedups or security > enhancements? > > --Brett Glass > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7qN11v8Bofna59hYRA4i2AJ4yBY2E6xU1yP26+W6se6FcoGiRSgCeOR/U DCj4YG603EVC948uAQlXhvw= =tdyc -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010919135456.M62587-100000>