Re: [suse-security] filtering ports
Boris Lorenz <bolo@lupa.de> wrote:
Hope that sheds more light on the issue.
Let's see if I've understood correctly: If I return-rst all incoming connection on my 22 except ones from a "trusted" net, but I don't also drop/deny the unwanted IPs, an attacker can simply ignore the reset packets and happily connect to the port... right? Ciao, Rob!
* r.maurizzi@gvs.it wrote on Thu, Sep 27, 2001 at 11:13 +0100:
Boris Lorenz <bolo@lupa.de> wrote:
Hope that sheds more light on the issue.
If I return-rst all incoming connection on my 22 except ones from a "trusted" net, but I don't also drop/deny the unwanted IPs, an attacker can simply ignore the reset packets and happily connect to the port... right?
No, you misunderstood. If an attacker tries to tcp-connect, on a non-firewalled machine, if gets rst when there is nothing listens (and SYN, ACK, no FIN otherwise, which is the next "right" packet in TCP handshake). On a firewalled machine, the firewall can DROP this packet - that means it send nothing back. Since the attacker expects RST or SYN,ACK, it can conclude the port (host, net) is firewalled (well, in fact when blocking whole hosts she would expect nothing or icmp dest unrech, BTW). When the firewall policy is REJECT, then an ICMP dest unrech "communication adminstrativly prohibited" will be send. An attacker can conclude that it's firewalled of course. Now "some trick" is to "DROP" the packet (--> don't process it via the TCP stack) but have some clever daemon "simulating" the RST which would be sent by the TCP stack normally. For the attacker, she cannot know if the RST came from tcp stack or some clever daemon, so she conclude that the port probably it not firewalled but unused. I think the attacker can still detect the firewall by other scans methods (not syn [syn stealth or connect], maybe FIN or so), since such scans would return the same on every request, and an attacker can conclude that there should at least anythink listing anywhere. Well, but not by script kiddies which try nmap for the first time :) Anyway, I don't think that it's a security risk to let an attacker know that you use a firewall; if they get really no response from the whole network they can conclude that there must be some firewall (I don't know any networks with zero services :)). Well, but the attacker shouldn't be able to gain information to intrude easier by this. Hope this cleared up the things now. oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
Hi, On 27-Sep-01 r.maurizzi@gvs.it wrote:
Boris Lorenz <bolo@lupa.de> wrote:
Hope that sheds more light on the issue.
Let's see if I've understood correctly:
If I return-rst all incoming connection on my 22 except ones from a "trusted" net, but I don't also drop/deny the unwanted IPs, an attacker can simply ignore the reset packets and happily connect to the port... right?
Well, no. You can't connect to a port which sends RSTs back to you under normal circumstances. If you'd construct an "deny-all-except" ipchains rule for the ssh port, return-rst resets all connections, except yours. Perhaps my example ipchains line wasn't clear enough. Let's try this one: ipchains -A input -p tcp -y -o 128 -j DENY -s ! 1.2.3.4/32 -d <yourhost> 22 ("copy 128 bytes of connections with SYN set and ACK and FIN unset to the netlink device which *don't* (-s !...) come in via "trusted" IP 1.2.3.4 to the ssh server on your host"). Of course one could use IP spoofing to fiddle with that return-rst'ed port, but I guess the attacker would want to get some packets back, which does not happen if he/she spoofs his/her connection. Using toys like hping in a decent script and spoofing, you may be able to say that there is in fact a service listening... Did I mention already that return-rst is no wonder cure? ;))
Ciao, Rob!
Boris Lorenz <bolo@lupa.de> ---
participants (3)
-
Boris Lorenz -
r.maurizzi＠gvs.it -
Steffen Dettmer