lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date: Mon Jan 23 17:50:30 2006
From: degeneracypressure at gmail.com (Eliah Kagan)
Subject: Personal firewalls.

On 1/23/06, Craig Soderland wrote:
> You're in right in a server environment, this might be a liability, in a
> client environment it's probably not so much of an issue.  Since you
> would only be denying me a single system, out of a myriad that I could
> still connect to. Further I think it does a check in it's connection
> table, to see if I had (as a client) a valid connect on my side. Having
> that I believe it would still let me access the resource that you were
> trying to deny me access to.

Actually I could deny you access to as many systems as I could spoof
enough packets for. Which would likely be hundreds, or maybe even
thousands (if I have a botnet). And they might, as Thierry Zoller
suggested, be systems of critical importance to you, like your DNS
servers.

Some application-layer protocols, such as HTTP, don't involve the
client maintaining a connection to the server all the time. So I could
still prevent you from accessing websites of my choosing, if the
firewall is allowing incoming packets on an ESTABLISHED connection
that you initiated.

But it seems to me that what it really comes down to is this:

Either you are allowing at least one server to be accessed over the
Internet, or you're not. Since Sygate PRO is a *firewall*, people can
only connect to servers on your box if you want those servers to be
accessible (unless you have configured it very poorly).

If you are allowing one or more servers to be accessed over the
Internet then it's a server environment, and the DoS problems apply.

If you are not allowing any servers to be accessed over the Internet
then any incoming unsolicited packets are dropped by the firewall
anyway, and then the *only* thing this feature does it to enable
people to DoS you.

Certainly this feature has the benefit of making it harder for someone
to scan your ports. But it seems to have a lot of drawbacks.
Admittedly, the risk is reduced if you're running services on obscured
ports that only a few people access. But the problems don't go away
entirely just because the environment is primarily one in which most
of the connections are outbound from the firewalled box.

If the firewall is preventing you from establishing outbound
connections to blackholed hosts (maybe this could be turned off
entirely, so it just keeps banned hosts from establishing
connections?) then I don't see any way around the DoS problems, unless
you are in a highly specialized environment. If you make exceptions in
the blackholing policy for your DNS servers, your ISP's mail servers,
and so forth, attackers can still spoof SYN packets that look like
they're coming from popular websites, such as search engines, webmail
services, news and weather sites, computer security sites, important
government sites, and so forth. For most users, it would be
prohibitively difficult to make exceptions for all these things. Even
if you could whitelist the servers you use regularly and decrease the
likelihood that you would be successfully targeted personally, hackers
could exploit this "feature" of Sygate PRO to censor access to servers
of their choosing within in certain communities, by bombarding desired
IP ranges with SYN packets spoofed to have the source IPs of those
servers.

Finally, if even one whitelisted host on the Internet runs an
operating system with a TCP/IP implementation that generates sequence
numbers in a predictable way, you can be idlescanned via that host
(see http://www.insecure.org/nmap/idlescan.html).

I think that a better way to set things up--if you really need to make
it hard for people to know what services you're running--would be to
ditch this feature and just have all your ports stealthed, and use a
VPN to connect to your services (of course the problem is, where do
you put the VPN server, but maybe Hamachi would be a suitable
solution).

-Eliah

On 1/23/06, Soderland, Craig wrote:
> You're in right in a server environment, this might be a liability, in a
> client environment it's probably not so much of an issue.  Since you
> would only be denying me a single system, out of a myriad that I could
> still connect to. Further I think it does a check in it's connection
> table, to see if I had (as a client) a valid connect on my side. Having
> that I believe it would still let me access the resource that you were
> trying to deny me access to.
>
> -----Original Message-----
> From: full-disclosure-bounces@...ts.grok.org.uk
> [mailto:full-disclosure-bounces@...ts.grok.org.uk] On Behalf Of Eliah
> Kagan
> Sent: Friday, January 20, 2006 5:53 PM
> To: full-disclosure@...ts.grok.org.uk
> Subject: Re: [Full-disclosure] Personal firewalls.
>
> > However I do wish it had the feature that Sygate PRO has, which will
> > blackhole a IP if it detects a ports scan coming to it. it then blocks
>
> > all activity from the offending IP for approximately 10 minutes.
>
> Well, it's a feature if the probes are really coming from the computer
> Sygate PRO thinks they're coming from.
>
> Suppose X is running Sygate PRO and Y is a legitimate client connecting
> to a server running on X. Then Z comes along and sends a bunch of SYN
> packets to X, spoofed to have the source IP of Y, waits 10 minutes, and
> repeats ad infinitum. Now Y can never connect to X.
> This seems more like a DoS vulnerability than a feature to me. Am I
> missing something?
>
> -Eliah
<snip>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ