[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[suse-security] Re [suse-security] SuSEfirewall2 behaves strangely



> -----Original Message-----
> From: Tom Knight [mailto:thomas.knight@xxxxxxxxxx] 
> Sent: Friday, January 09, 2004 1:52 PM
> >
> > rejecting packest rather than dropping packets tells the querying
> > system that that service does not exist.
> > so unless the rules allow for a connection, packets will be 
> rejected.
> 
> 
> Surely what you want to do is not tell someone the sevice 
> doesn't exist, but
> rather not tell them anything? If you drop the packet they 
> don't even know
> that the port exists, not that the port exists and is 
> configured not to let
> them access it. 

one could argue about that.

> Trying to ftp to (say): 196.30.15.82 I get a "connection refused"
> immediately.
> Oh ho, a machine is there, what else can I try?

In this case it doesn't matter if you DROP or REJECT the packet
(except the connection timeout vs the connection refusal)

If theres no response you know theres a firewall in place
otherwise another (properly configured) host would have send a
icmp host/network unreachable.
Your machine is not invisible just because you DROP IP connections.
 
> If the attacker tries port 1 against 196.30.15.1, port 2 
> against 196.30.15.2
> etc, he'll find your machine and attack. This is one of the 
> port scans I've
> seen in use against my old work.
> 
> If you drop everything (except for externally available 
> ports), then there's
> a good chance the attacher won't try (say) port 21 against 
> 196.30.15.82, and
> so won't see that that machine exists.

What prevents the attacker from starting multiple scans at once?
 
> 
> Dropping packets is actually a line of defense, and you 
> really should use
> it.
> 
> Tom.

again there are different opinions about this topic, everyone
should decide on his own if DROP or REJECT is his choice.

marc

--
Check the headers for your unsubscription address
For additional commands, e-mail: suse-security-help@xxxxxxxx
Security-related bug reports go to security@xxxxxxx, not here