Hey Guys,
This has developed into an interesting debate so let me drop a couple of
pennies in the slot.
For me, best practice is to configure firewalls so they they only allow
those data flows provided for in a qualified security policy. You allow
the bear minimum and stop there. Then you test that this is all you have
allowed. If possible you do not want to allow any connections from the
outside world to your internal network. If you have to allow protocols
like HTTP, Telnet, FTP etc then put these hosts somewhere else (like in
a DMZ) .... etc .. OK extract those eggs from your gullet anytime
now....
Most companies are concerned with business continuity. The cost of
maintaining this should be as low as possible. Thus the added costs of
logging TCP/IP transactions could perhaps be one which is unneccessary.
Obviously the corporate net must be as unassailable as possible from
outside and perhaps more particularly , inside. The corporate web
presence featuring whatever e-commerce solution is not so important.
These things will be underwritten ... and provided the cost of failures
is not comparable to the profit made from the site not much will be done
about it. I am reminded here of the film "Fight Club" where out would be
anti-hero explains the process by which dangerous motor vehicles are not
withdrawn from the market. It has nothing to do with how many young
teenagers die but the cost of litigation...
So this is the canvas. Upon this one could argue that provided you keep
up to date with security patches, and keep seeking to improve your
security, making sure it is tested to make sure that reacting passively
or agressively to an attack is not even worth thinking about. Or could
we describe redirecting closed port connections as passive-agressive?
In order to redirect any sort of port connection you have to be able to
detect it first. So, TCP/IP log hosts, Firewall syslogs and IDS... Once
you have detected an port scan you can either, do nothing and just
giggle at the hapless fool, redirect the packets to a Honey Pot then
giggle at the hapless fool, try to track the source and giggle at the
hapless fool , try to track the source and retaliate, then giggle at the
hapless fool.
So the benefits here are research, in that if you have enough time to
spend reviewing the logs you might just see a new form of attack. In
addition, using a honey pot or the like you may give you self enough
time to track the source aswell as log other types of attack such as the
use of root kits etc...
A note here about Honey pots .. I will continue the thread lower down...
Why? For a honey pot to be attractive it must be appealing. i.e. you are
going to leave something open or vulnerable. Thus you have lost the
benefit of research as you should see the same attack over and over
again. All you really get is time .... and a bit of excitement... Here I
disagree with the notion that leaving everything open will somehow
disuade a script kiddie from continuing with their attack....
To continue ... tracking the source can be difficult and is prone to
error. This has been pointed out already... But then close port scanning
such as SYN scans etc... are not all that usefull to an attacker except
perhaps in the form of network enumeration... you might be able to get a
better picture of what the network looks like but you will not get a
foot hold to launch an attack.... OK perhaps DOS for the Brain Dead. DOS
is just the bananna skin of TCP/IP security. Ultimately, it takes no
skill or knowledge, and it will just about always work... the only
defence is to detect it early and turn off your router... or have so
much bandwidth that the source crashes before you do.. DSL????
The only reliable method of scanning is a tcp connect. If this type of
scan is detected then you know how you can track the source. From here
it is simple. In order for the attacker to get any usefull info he must
be able to get data back... Thus the source reported in the TCP header/
IP Header is the real source, or by tracerouting back to the reported
source .. one of the hops will be the real source... you know what the
source port is so find which one accepts your response packets.... But
then what do you do when you have tracked the source ... the responsible
thing to do would be to determine what ISP is responsible and inform
them that one of the hosts or connections is being used to scan you
illegally. Retaliation is a highly questionable course of action, even
if it is very tempting!!
Cheers,Liam.
> ----------
> From: Paul D. Robertson
> Sent: 12 May 2000 20:45
> To: Steve Coleman
> Cc: Damian Gerow; [EMAIL PROTECTED]
> Subject: Re: FW: Redirecting closed port connections
>
> On Fri, 12 May 2000, Steve Coleman wrote:
>
> > This reminded me I a somewhat (legally) flawed idea I had in the
> past
> > which was to redirect all the probes back at the host that they were
> > coming from. This way the perpetrator would be scanning the machine
> that
> > (s)he is sitting on and wasting their time trying to break into
> their
> > own system.
> >
>
> And if they're spoofing source addresses, you'll be sending packets at
> an
> innocent victim, and if they're doing the same thing...
>
> Paul
> ----------------------------------------------------------------------
> -------
> Paul D. Robertson "My statements in this message are personal
> opinions
> [EMAIL PROTECTED] which may have no basis whatsoever in fact."
>
> PSB#9280
>
> -
> [To unsubscribe, send mail to [EMAIL PROTECTED] with
> "unsubscribe firewalls" in the body of the message.]
>
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
