Re: [Full-disclosure] 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@xxxxxxxxxxxxxxxxx
> [mailto:full-disclosure-bounces@xxxxxxxxxxxxxxxxx] On Behalf Of Eliah
> Kagan
> Sent: Friday, January 20, 2006 5:53 PM
> To: full-disclosure@xxxxxxxxxxxxxxxxx
> 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>
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/



Relevant Pages

  • Re: ER: weird behaviour when using s=6 option in sqlhosts
    ... The environment consists of three instances, ... The cdr tool is an ESQL/c program and would need to use an SQL connection to connect to the server. ... Since part of template realization is to verify that the data is correct, it must connect to those servers. ... After that I defined and realized a template on ER primary and tried to realize it for target instance also. ...
    (comp.databases.informix)
  • Re: Basic questions for designing the COM Server
    ... Almost all my COM Servers act as a data providers. ... information and on request supply it to the Client. ... the database connection late, acquire the data, and close the connection and ... the database, then the thin Servers would just supply required ...
    (microsoft.public.vc.atl)
  • Re: scp fails - excepted on very small files
    ... ssh is also working great. ... mismatch in versions between the client software and the servers. ... Have you put a sniffer on the connection to see what's actually passing ...
    (SSH)
  • Re: Port 7070
    ... why that port is open. ... It always returns a reset when a connection is ... tcpdump on the client machine shows a complete ... Running the client on a machine on the servers LAN shows that the port ...
    (freebsd-questions)
  • Port 7070
    ... I checked on all my production and test servers and got the same response. ... I can't figure out why that port is open. ... It always returns a reset when a connection is opened. ... The client is going across the internet. ...
    (freebsd-questions)