This is noted in the README. I have recommended that people use it only on dedicated "honeypots", or at least on client machines, rather than on mission-critical servers :) One can always use iptables --rate, but, like I said, I'm unable to tests it very well atm. I think that, as written, synfloods are equivalent to fork bombs (very bad because now people don't even need a shell account); but it's my list of things to do: make the accept() non-blocking, and if a response isn't heard within $TIME then log the attack, which is known to be a SYN attack! This both avoids the fork bomb and notifies the admin of the (special) attack. Non-SYN attacks are also bad, but the primary problem is disk access and disk space. Please Cc: me, Justin On Thu, May 22, 2003 at 03:10:00PM +0000, Jerry Shenk wrote: > > That does sound like a pretty decent idea. I know when I pen-test a Raptor > firewall, it reports so many ports as being open that it's a bit of a > nuisance to sort through what's really open and what's not. From the > security side, this gives the 'victim' plenty of time to track this incoming > junk while the attacker's fumbling around trying to figure out what's real > and what isn't. > > One major issue I see...How vulnerable to attack do you think that will be? > If that method of defense were detected, an attacker chew up a lot of > resources but scanning fast. > > -----Original Message----- > From: Justin Pryzby [mailto:justinpryzbyat_private] > Sent: Wednesday, May 21, 2003 5:00 PM > To: incidentsat_private > Subject: [ANNOUNCE] protocol watcher > > > I emailed the list previously asking if anyone knew of a way to > automatically accept and log all connections to a computer. My thanks > to all that replied; unfortunately, I was unable to find exactly what I > wanted. Since then, it occurred to me that this piece of software would > not be hard to write, so, three attempts later, it is written. > > ``Protowatch'' may be now be found on sourceforge: > [http://www.sf.net/projects/protowatch/]. It will work only for Linux > 2.4/2.5, as it requires the iptables QUEUE target to dynamically run a > server (in userspace) for each unhandled packet. > > It has not been well tested, but is a trivial piece of code. I will be > in a better position to test it in two weeks; atm I am behind a home > router. > > Questions, comments and flames are welcome. > > Justin Pryzby > > ---------------------------------------------------------------------------- > *** Wireless LAN Policies for Security & Management - NEW White Paper *** > Just like wired networks, wireless LANs require network security policies > that are enforced to protect WLANs from known vulnerabilities and threats. > Learn to design, implement and enforce WLAN security policies to lockdown > enterprise WLANs. > > To get your FREE white paper visit us at: > http://www.securityfocus.com/AirDefense-incidents > ---------------------------------------------------------------------------- > > ---------------------------------------------------------------------------- *** Wireless LAN Policies for Security & Management - NEW White Paper *** Just like wired networks, wireless LANs require network security policies that are enforced to protect WLANs from known vulnerabilities and threats. Learn to design, implement and enforce WLAN security policies to lockdown enterprise WLANs. To get your FREE white paper visit us at: http://www.securityfocus.com/AirDefense-incidents ----------------------------------------------------------------------------
This archive was generated by hypermail 2b30 : Fri May 23 2003 - 10:15:44 PDT