On Tue, Apr 04, 2000 at 02:26:59PM +1000, Ian Ward wrote:
> If I was OPTUS (or anybody) and I wanted to figure if you are running a
> "server" (just cause windows doesn't have any inbuilt messaging or httpd
> doesn't make everything else that does a server), one way is to scan 3128
> and 3120 to look for squid. If the packet was dropped, then that would mean
> you have firewalling in place *AND* most probably have squid listening on
> your internal network.
Wrong. If the packet is dropped (and you only know that *after* you've
timed out on the response), all you can tell is that the packet was
dropped. It tells you absolutely *nothing* about what's running
internally.
(And why is squid in any way relevant to this discussion? There's far
more to the internet than just the bloody web. Squid generally reduces
your downstream traffic, with minimal, if any, impact on upstream traffic.
Optus's concern is upstream traffic).
I can setup two different machines, one with squid and one without, and
both will react identically if you try to connect to port 3128 (and 3130
is the default icp port, not 3120) from the outside world. I can also
setup squid on any other port I choose, and you'd be none the wiser. As
an outsider, you cannot possibly distinguish between any of these
configurations. Even if you could connect to port 3128, you could then
only assume that something (but you wouldn't necessarily know what) is
listening on that port *on the external interface*. You'd still have no
idea what's running internally, because you have absolutely no access to
that interface.
> connection refused neither confirms or denies the hypothesis. Therefore I
And this is different from dropping the packet precisely how? Both will
tell you exactly the same thing. The argument over reject vs deny is
nothing to do with providing information about open and closed ports, but
rather it's over when and how the attacker gains information about your
firewall. Both reject and deny tell the attacker that the port is
unreachable, the difference is *when* that information becomes available
to the attacker.
Rejecting the packet provides *immediate* feedback to the attacker that
the port is unreachable. Merely dropping the packet without response
*eventually* tells the attacker that the port is unreachable, but it takes
longer for the attacker to figure this out. That means that they'll
generally try several times, taking more of their time. A dropped packet
could be lost in transit somewhere, it could be caused by a routing
problem, it could be just a slow link somewhere between the attacker and
you. The attacker can't tell the difference, so he has to wait for some
time in case there's a response.
The longer it takes for the attacker to collect this information, the
longer it takes for them to break into your machine. That increases their
chances of being caught, and reduces their chance of success.
Remember, most of the attackers we're likely to see are script-kiddies
without a clue what they're doing, and they're not smart enough to figure
out the difference. A really smart attacker won't be fooled, but that's
not what I was aiming to protect against. A really smart attacker will be
going after higher value targets, and he isn't going to leave tracks a
mile wide in your logs even if he did try ...
Cheers,
John
--
whois [EMAIL PROTECTED]
--
SLUG - Sydney Linux Users Group Mailing List - http://www.slug.org.au
To unsubscribe send email to [EMAIL PROTECTED] with
unsubscribe in the text
