[IndiChix] Fwd: [Volunteers] [Chapters] DNS issue, was... floss events/confs

Thu Jun 25 11:33:14 UTC 2009

Second, in the series of responses to the DNS issue.

---------- Forwarded message ----------
From: Lisa Kachold <lisakachold at obnosis.com>
Date: Thu, Jun 25, 2009 at 11:24
Subject: Re: [Volunteers] [Chapters] DNS issue, was... [IndiChix]
floss 	events/confs
To: Mary Gardiner <mary at puzzling.org>
Cc: Volunteers <volunteers at linuxchix.org>, chapters at linuxchix.org

It's possible that ns2.demandspace.com does not respond to queries
because it's setup not to respond to all networks for security
reasons.

Having more than one physically diverse DNS server setup for your NIC
template in whois is desirable.  Generally one (or more) are
configured as MASTER and others as slaves, getting updates from the
single primary source (where we make the edits) so that all provide
redundant DNS in case of disaster.

The issues with your DNS might actually be that someone is poisoning
or DoS'ing your cache wherein the primary server would quit
responding.  Queries are cached depending on the TTL (time to live) in
the distributed database that is the internet DNS server system.  So I
doubt that this is why in fact there is an issue with your server
appearing to be down, if that is happening, but we dilligent and
thorough women generally ferret out a great deal of things overlooked
when the ball is in our court to resolve intermittent issues.  It's
probable that there is some server based DoS as well, (which is common
for web servers) or other issues that preclude it's response during
certain things (scans, aggressive spiders, SSL network treason).

If your current master is not under load (and it takes a great deal to
load a DNS server) the second will not be queried.  But if the first
one is answering, you will never see, read notice, that the other is
not responding to queries, unless you actually ask it (as was done
above via nslookup).  If the secondary DNS server was once the primary
and now is not answering, with a 6 week TTL (time to live) for
instance, you will still queries fail in an intermittant way.  If you
changed your servers some $weeks ago, and are now suddenly seeing
these problems and getting reports from people, check your server TTL.

Of course this must be fixed, but a full analysis of the server logs
to ensure there are no other factors is in order.  While your server
might have once been stable the script kiddie scum fluctuate all the
time.  And new Apache DoS exploits are constantly being devised:

Yesterday RSnake released an interesting HTTP DoS tool that performs a
Denial of Service attack on Apache servers by exhausting available
connections by holding the connection open while sending incomplete
HTTP requests to the server.

The initial part of the HTTP request is standard:

GET / HTTP/1.1\r\n
Host: host\r\n
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1;
Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.503l3; .NET CLR
3.0.4506.2152; .NET CLR 3.5.30729; MSOffice 12)\r\n
Content-Length: 42\r\n

Notice that it is missing one CRLF to finish the header which is
otherwise completely legitimate. The bogus header line the tools sends
is currently:

X-a: b\r\n

So the server keeps waiting for the rest of the header.

RSnake explains:

"In considering the ramifcations of a slow denial of service attack
against particular services, rather than flooding networks, a concept
emerged that would allow a single machine to take down another
machine's web server with minimal bandwidth and side effects on
unrelated services and ports. The ideal situation for many denial of
service attacks is where all other services remain intact but the
webserver itself is completely inaccessible. Slowloris was born from
this concept, and is therefore relatively very stealthy compared to
most flooding tools.

Slowloris holds connections open by sending partial HTTP requests. It
continues to send subsequent headers at regular intervals to keep the
sockets from closing. In this way webservers can be quickly tied up.
In particular, servers that have threading will tend to be vulnerable,
by virtue of the fact that they attempt to limit the amount of
threading they'll allow. Slowloris must wait for all the sockets to
become available before it's successful at consuming them, so if it's
a high traffic website, it may take a while for the site to free up
it's sockets. So while you may be unable to see the website from your
vantage point, others may still be able to see it until all sockets
are freed by them and consumed by Slowloris. This is because other
users of the system must finish their requests before the sockets
become available for Slowloris to consume. If others re-initiate their
connections in that brief time-period they'll still be able to see the
site. So it's a bit of a race condition, but one that Slowloris will
eventually always win - and sooner than later."

Apache 1.x and 2.x are affected as well as Squid, so the number of
servers that are effected will be quite high.

The traffic to exhaust available connections on a server is slight.
Microsoft IIS 6.0 or 7.0 are not affected.

At the moment Apache's has not responded to state configuration change
that might  prevent this attack – increasing MaxClients will just
increase requirements for the attack.

Tomasz Miklas said that he was able to prevent the attack by using a
reverse proxy called Perlbal in front of an Apache server.  Of course
load balancers will, like IIS, probably not be effected (with this
exploit - check your headers and URI rewrites for other known
exploits).

Reference:

http://www.hackinthebox.org/index.php?name=News&file=article&sid=31831

On 6/24/09, Mary Gardiner <mary at puzzling.org> wrote:
> On Thu, Jun 25, 2009, vid wrote:
>> Ketan, here is what i got on a nslookup.
>>
>> Non-authoritative answer:
>> Name:   india.linuxchix.org
>> Address: 64.13.203.77
>>
>> Can you explain this ? I'm CC'ing the volunteers and chapters list so
>> they can help us out.
>
> It's not clear to me how much you know about the two nameservers, so the
> below
> may contain info you know already.
>
> There are two nameservers for linuxchix.org:
>
>     $ dig -t ns linuxchix.org
>     [...]
>     ;; ANSWER SECTION:
>     linuxchix.org.            72041   IN      NS      ns2.demandspace.com.
>     linuxchix.org.            72041   IN      NS      ns0.linuxchix.org.
>
> Both of those are regarded as equally correct sources of information about
> "linuxchix.org" (and subdomains). It is common (required, in fact) for there
> to
> be some redundancy in DNS like this.
>
> ns0.linuxchix.org knows about india.linuxchix.org:
>
>     $ dig india.linuxchix.org @ns0.linuxchix.org.
>     [...]
>     ;; ANSWER SECTION:
>     india.linuxchix.org.      86400   IN      A       64.13.203.77
>
> ns2.demandspace.com does not (the command "dig india.linuxchix.org
> @ns2.demandspace.com." doesn't return an ANSWER SECTION, which is what is
> meant
> by "not found")
>
> This will mean continual intermittant errors looking up india.linuxchix.org.
> This needs to be fixed by the admins of either ns0.linuxchix.org. or
> ns2.demandspace.com., possibly both. The nameservers should be returning
> consistent information for the domain to work correctly.
>
> -Mary
> _______________________________________________
> Volunteers mailing list
> Volunteers at linuxchix.org
> http://mailman.linuxchix.org/mailman/listinfo/volunteers
>

--
www.obnosis.com (503)754-4452
http://despair.com/discovery.html
"Contradictions do not exist." A. Rand
_______________________________________________
Volunteers mailing list
Volunteers at linuxchix.org
http://mailman.linuxchix.org/mailman/listinfo/volunteers

-- 
thanks
|| vid || http://www.svaksha.com ||