Archive: http://msgs.securepoint.com/ids
FAQ: http://www.ticm.com/kb/faq/idsfaq.html
IDS: http://www-rnks.informatik.tu-cottbus.de/~sobirey/ids.html
HELP: Having problems... email questions to ids-owneruow.edu.au
NOTE: Remove this section from reply msgs otherwise the msg will bounce.
SPAM: DO NOT send unsolicted mail to this list.
UNSUBSCRIBE: email "unsubscribe ids" to majordomouow.edu.au
-----------------------------------------------------------------------------
In addition to the ethical concerns that have been voiced about "fighting
back", there are legal concerns, as well. If you launch some kind of
retaliatory attack against a site that either did not know that it was being
used for an attack or, even worse, that was not involved and you attacked by
mistake, you could be violating US federal laws if you do damage to that
site. You could become the very thing you are trying to fight against.

The better ways to fight are both slower, but more effective in the long run:

1) Honey pots. Use them to gather evidence that will allow the authorities
to track down the person who is attacking you.

2) Internal policies and procedures. Understand how your system can be
attacked. Educate users. Have policies and procedures in place that enable
you to identify and respond to an attack, including gathering evidence and
working with the authorities.

2) Policy/philosophy change. There has been a lot written about getting
people to change their philosophy from "Anything outbound/Restricted inbound"
to "Restricted outbound/Restricted inbound." If you can get your company,
your company's partners, your ISP, etc. to start taking more responsibility
for what goes out from their networks, then we can go a long way towards
making things more secure for everyone.