Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.security > #283 > unrolled thread

wpad.dat attack on Linux Apache server

Back to article view | Back to comp.os.linux.security

Contents

  wpad.dat attack on Linux Apache server Sandman <mr@sandman.net> - 2013-05-24 11:22 +0200
    Re: wpad.dat attack on Linux Apache server Richard Kettlewell <rjk@greenend.org.uk> - 2013-05-24 10:37 +0100
      Re: wpad.dat attack on Linux Apache server Sandman <mr@sandman.net> - 2013-05-24 11:44 +0200
        Re: wpad.dat attack on Linux Apache server Richard Kettlewell <rjk@greenend.org.uk> - 2013-05-24 11:04 +0100
          Re: wpad.dat attack on Linux Apache server Sandman <mr@sandman.net> - 2013-05-24 12:13 +0200
            Re: wpad.dat attack on Linux Apache server Richard Kettlewell <rjk@greenend.org.uk> - 2013-05-24 11:20 +0100
              Re: wpad.dat attack on Linux Apache server Sandman <mr@sandman.net> - 2013-05-24 12:23 +0200
                Re: wpad.dat attack on Linux Apache server J G Miller <miller@yoyo.ORG> - 2013-05-24 11:07 +0000
                  Re: wpad.dat attack on Linux Apache server Sandman <mr@sandman.net> - 2013-05-24 14:43 +0200
                    Re: wpad.dat attack on Linux Apache server Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2013-05-24 13:05 +0000
                      Re: wpad.dat attack on Linux Apache server Sandman <mr@sandman.net> - 2013-05-24 15:14 +0200
                        Re: wpad.dat attack on Linux Apache server Joe Beanfish <joebeanfish@nospam.duh> - 2013-05-24 13:39 +0000
                          Re: wpad.dat attack on Linux Apache server Sandman <mr@sandman.net> - 2013-05-24 16:23 +0200
                        Re: wpad.dat attack on Linux Apache server Richard Kettlewell <rjk@greenend.org.uk> - 2013-05-24 15:13 +0100
                          Re: wpad.dat attack on Linux Apache server Sandman <mr@sandman.net> - 2013-05-24 16:26 +0200
                            Re: wpad.dat attack on Linux Apache server Richard Kettlewell <rjk@greenend.org.uk> - 2013-05-24 17:38 +0100
                              Re: wpad.dat attack on Linux Apache server Sandman <mr@sandman.net> - 2013-05-24 19:02 +0200
                                Re: wpad.dat attack on Linux Apache server Richard Kettlewell <rjk@greenend.org.uk> - 2013-05-24 18:45 +0100
                                  Re: wpad.dat attack on Linux Apache server Sandman <mr@sandman.net> - 2013-05-24 21:12 +0200
                            Re: wpad.dat attack on Linux Apache server Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2013-05-24 16:47 +0000
                              Re: wpad.dat attack on Linux Apache server Sandman <mr@sandman.net> - 2013-05-24 18:53 +0200
                                Re: wpad.dat attack on Linux Apache server J G Miller <miller@yoyo.ORG> - 2013-05-24 17:15 +0000
                                  Re: wpad.dat attack on Linux Apache server Sandman <mr@sandman.net> - 2013-05-24 21:20 +0200
                                    Re: wpad.dat attack on Linux Apache server Richard Kettlewell <rjk@greenend.org.uk> - 2013-05-25 08:45 +0100
                                      Re: wpad.dat attack on Linux Apache server Sandman <mr@sandman.net> - 2013-05-25 09:54 +0200
                                      Re: wpad.dat attack on Linux Apache server Sandman <mr@sandman.net> - 2013-05-25 10:04 +0200
                                      Re: wpad.dat attack on Linux Apache server Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2013-05-26 10:12 +0000
                                Re: wpad.dat attack on Linux Apache server "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2013-05-24 13:50 -0400
                                  Re: wpad.dat attack on Linux Apache server Richard Kettlewell <rjk@greenend.org.uk> - 2013-05-24 19:10 +0100
                                    Re: wpad.dat attack on Linux Apache server Richard Kettlewell <rjk@greenend.org.uk> - 2013-05-24 19:15 +0100
                                      Re: wpad.dat attack on Linux Apache server Sandman <mr@sandman.net> - 2013-05-24 21:33 +0200
                                        Re: wpad.dat attack on Linux Apache server Richard Kettlewell <rjk@greenend.org.uk> - 2013-05-25 08:38 +0100
                                  Re: wpad.dat attack on Linux Apache server Sandman <mr@sandman.net> - 2013-05-24 21:25 +0200
                                Re: wpad.dat attack on Linux Apache server Whiskers <catwheezel@operamail.com> - 2013-05-25 15:52 +0100
                                  Re: wpad.dat attack on Linux Apache server Roger <invalid@invalid.invalid> - 2013-05-25 17:19 +0100
                                    Re: wpad.dat attack on Linux Apache server J G Miller <miller@yoyo.ORG> - 2013-05-25 17:22 +0000
                                  Re: wpad.dat attack on Linux Apache server Sandman <mr@sandman.net> - 2013-05-25 19:41 +0200
                Re: wpad.dat attack on Linux Apache server Chris Davies <chris-usenet@roaima.co.uk> - 2013-05-24 12:31 +0100
                  Re: wpad.dat attack on Linux Apache server Sandman <mr@sandman.net> - 2013-05-24 14:29 +0200
                    Re: wpad.dat attack on Linux Apache server Chris Davies <chris-usenet@roaima.co.uk> - 2013-05-24 23:45 +0100
    Re: wpad.dat attack on Linux Apache server Sandman <mr@sandman.net> - 2013-05-24 14:49 +0200

Page 1 of 3  [1] 2 3  Next page →

#283 — wpad.dat attack on Linux Apache server

I don't actually know if it's an attack.

My Apache server was slow - symptoms being slow responses (after PHP had 
processed and sent to client) and dropped connections, looked in the log 
files, found 12GB of accesses to /wpad.dat on my catch-all vhost. 

I got thousands of requests per minute from hundreds of different hosts, 
and a sample of these showed that they all seemed like legit end-user 
hosts, not a tor proxy botnet at least.

I googled some, and found that wpad is some form of auto-discover proxy 
settings. Problem is, it should be done to the local network. So if my 
machine is on the "example.com" network, my browser will send a request 
to "wpad.example.com" to find proxy settings. not 
"wpad.remoteinternetsite.com".

So, maybe it is an attack after all?

I added a wpad.dat file to the server, with this content:

    function FindProxyForURL(url, host) { return "PROXY 127.0.0.1:445"; }

Which just tells these clients to look for a proxy on localhost. Nothing 
changed. Thousands of thousands of requests.

In /server-status for Apache, my queue is filled with /wpad.dat requests 
with the "K" status (Keep-Alive), so that sounds like why it's slow.

Ok, so I'll block it. Blocking it in apache seemd stupid, it would still 
process the requests, so to iptables:

    iptables -I INPUT -p tcp --dport 80 -m string --to 70 --algo bm \
      --string "GET /wpad.dat" -j REJECT --reject-with tcp-reset

Yes, I know this analyzes *every* request, and wastes CPU cycles, I may 
get around to chain this into a seperate iptables chain and only act on 
correct parts. In about an hour, this has blocked 45k requests, or about 
750 per minute

Either way, the requests are gone, the log file is clean(er) but the 
server is still slow and still drops connections.

So, troubleshooting some more. CPU is at 0.8% usage, Memory is 80% free. 
Asking my hosting ISP, my bandwidth capacity is at 0.62%

ethtool -S eth0 shows no errors (but a shitload of packets, of course)

Someone suggested that it could have something to do with my using a 
wildcard DNS. So, my server hosts some 100+ virtual hosts. All my 
clients are told to use a CNAME pointer for their servers. So:

 www.client.com -> CNAME -> cluster.mydomain.com -> A -> 123.123.123.123

Which means that every visitor to my sites has their web browser first 
look up www.client.com to find cluster.mydomain.com which in turn points 
to my IP. 

No, the mydomain.com had a wildcard setting, so if and when they would 
access "wpad.mydomain.com" my DNS would point that to 
cluster.mydomain.com and then that wold point to the IP. So supposedly, 
all the request could channel to my server this way.

I have now removed wildcard for mydomain.com, and also added a wpad host 
for all my domains that points to 127.0.0.1. I'm waiting to see that 
propagate and see if it makes any difference. It hasn't so far.


Do any of you guys have any ideas what this might be?  Or rather - how 
do I trouble shoot this some more?

I have:

    Slow transfer speeds on apache
    Super fast on other ports (SFTP for instance)
    Thousands of requests per minute that are now being blocked
    Super low CPU usage
    Super low RAM usage
    No reported ethernet errors








-- 
Sandman[.net]

[toc] | [next] | [standalone]

#284

Sandman <mr@sandman.net> writes:
> Ok, so I'll block it. Blocking it in apache seemd stupid, it would still 
> process the requests, so to iptables:
>
>     iptables -I INPUT -p tcp --dport 80 -m string --to 70 --algo bm \
>       --string "GET /wpad.dat" -j REJECT --reject-with tcp-reset
>
> Yes, I know this analyzes *every* request, and wastes CPU cycles, I may 
> get around to chain this into a seperate iptables chain and only act on 
> correct parts. In about an hour, this has blocked 45k requests, or about 
> 750 per minute

While this will send a TCP reset to the misbehaving client, AIUI it will
not send anything to your Apache, which by this point will have an open
TCP connection and will be awaiting the start of the HTTP request.  It
will presumably continue waiting up to some timeout.  You should be able
to use netstat to confirm or refute this.

-- 
http://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#285

In article <87vc68ra57.fsf@araminta.anjou.terraraq.org.uk>,
 Richard Kettlewell <rjk@greenend.org.uk> wrote:

> Sandman <mr@sandman.net> writes:
> > Ok, so I'll block it. Blocking it in apache seemd stupid, it would still 
> > process the requests, so to iptables:
> >
> >     iptables -I INPUT -p tcp --dport 80 -m string --to 70 --algo bm \
> >       --string "GET /wpad.dat" -j REJECT --reject-with tcp-reset
> >
> > Yes, I know this analyzes *every* request, and wastes CPU cycles, I may 
> > get around to chain this into a seperate iptables chain and only act on 
> > correct parts. In about an hour, this has blocked 45k requests, or about 
> > 750 per minute
> 
> While this will send a TCP reset to the misbehaving client, AIUI it will
> not send anything to your Apache, which by this point will have an open
> TCP connection and will be awaiting the start of the HTTP request.  It
> will presumably continue waiting up to some timeout.  You should be able
> to use netstat to confirm or refute this.

Thank you for your reply. I thought "reject" just rejected the request 
and nothing came to Apache?

Using /server-status I see a huge difference in active connections, but 
I do see a tremendous amount of "Total accesses" which doesn't seem to 
correlate to the actual number of "valid" HTTP requests.

    Current Time: Friday, 24-May-2013 11:39:38 CEST
    Restart Time: Friday, 24-May-2013 11:22:51 CEST
    Parent Server Generation: 0
    Server uptime: 16 minutes 47 seconds
    Total accesses: 14027 - Total Traffic: 144.8 MB
    CPU Usage: u124.78 s5.91 cu136.95 cs0 - 26.6% CPU load
    13.9 requests/sec - 147.2 kB/second - 10.6 kB/request
    29 requests currently being processed, 24 idle workers

    ...._.KK.KK..........._.._...K._.R..._...K_.._...K......._R..K_.
    K_KKKK.._K_KW_WK_K__KK_....K_K_K___K_KK._.......................
    ................................................................
    ................................................................


As you can see - almost a thousand accesses per minute. Yet, my child 
processes are free to serve new processes.

"netstat -lap" shows about 400 lines of this:

tcp  0 0 www.mydomain.com:www  c-83-233-215-17.c:49686 SYN_RECV    -               
tcp  0 0 www.mydomain.com:www  h-5-200.a327.priv:50165 SYN_RECV    -               
tcp  0 0 www.mydomain.com:www  c-62-220-189-209.:50627 SYN_RECV    -             
tcp  0 0 www.mydomain.com:www  238.77.85.212.bah:58190 SYN_RECV    -               
tcp  0 0 www.mydomain.com:www  c-89-160-22-176.c:57315 SYN_RECV    -   

So yes, something is still knocking on that door - could this be bogging 
down my server?

I have also a number of lines with TIME_WAIT status, suggesting that 
some queue is full here... Right?       

-- 
Sandman[.net]

[toc] | [prev] | [next] | [standalone]

#286

Sandman <mr@sandman.net> writes:
> Richard Kettlewell <rjk@greenend.org.uk> wrote:
>> Sandman <mr@sandman.net> writes:
>>> Ok, so I'll block it. Blocking it in apache seemd stupid, it would still 
>>> process the requests, so to iptables:
>>>
>>>     iptables -I INPUT -p tcp --dport 80 -m string --to 70 --algo bm \
>>>       --string "GET /wpad.dat" -j REJECT --reject-with tcp-reset
>>>
>>> Yes, I know this analyzes *every* request, and wastes CPU cycles, I may 
>>> get around to chain this into a seperate iptables chain and only act on 
>>> correct parts. In about an hour, this has blocked 45k requests, or about 
>>> 750 per minute
>> 
>> While this will send a TCP reset to the misbehaving client, AIUI it will
>> not send anything to your Apache, which by this point will have an open
>> TCP connection and will be awaiting the start of the HTTP request.  It
>> will presumably continue waiting up to some timeout.  You should be able
>> to use netstat to confirm or refute this.
>
> Thank you for your reply. I thought "reject" just rejected the request 
> and nothing came to Apache?

You’re rejecting a packet that is part of an already-established TCP
connection.  iptables cannot go back in time and prevent the TCP
connection from being established in the first place.

-- 
http://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#287

In article <87ppwgr8wz.fsf@araminta.anjou.terraraq.org.uk>,
 Richard Kettlewell <rjk@greenend.org.uk> wrote:

> >> While this will send a TCP reset to the misbehaving client, AIUI it will
> >> not send anything to your Apache, which by this point will have an open
> >> TCP connection and will be awaiting the start of the HTTP request.  It
> >> will presumably continue waiting up to some timeout.  You should be able
> >> to use netstat to confirm or refute this.
> >
> > Thank you for your reply. I thought "reject" just rejected the request 
> > and nothing came to Apache?
> 
> You’re rejecting a packet that is part of an already-established TCP
> connection.  iptables cannot go back in time and prevent the TCP
> connection from being established in the first place.

Yes, like I said - I thought nothing came through to Apache. But looking 
at server-status, it seems it does anyway?


-- 
Sandman[.net]

[toc] | [prev] | [next] | [standalone]

#288

Sandman <mr@sandman.net> writes:
>  Richard Kettlewell <rjk@greenend.org.uk> wrote:

>> >> While this will send a TCP reset to the misbehaving client, AIUI it will
>> >> not send anything to your Apache, which by this point will have an open
>> >> TCP connection and will be awaiting the start of the HTTP request.  It
>> >> will presumably continue waiting up to some timeout.  You should be able
>> >> to use netstat to confirm or refute this.
>> >
>> > Thank you for your reply. I thought "reject" just rejected the request 
>> > and nothing came to Apache?
>> 
>> You’re rejecting a packet that is part of an already-established TCP
>> connection.  iptables cannot go back in time and prevent the TCP
>> connection from being established in the first place.
>
> Yes, like I said - I thought nothing came through to Apache.  But
> looking at server-status, it seems it does anyway?

I don’t know how to put it any more clearly; I give up.

-- 
http://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#289

In article <87k3mor85j.fsf@araminta.anjou.terraraq.org.uk>,
 Richard Kettlewell <rjk@greenend.org.uk> wrote:

> >> >> While this will send a TCP reset to the misbehaving client, AIUI it will
> >> >> not send anything to your Apache, which by this point will have an open
> >> >> TCP connection and will be awaiting the start of the HTTP request.  It
> >> >> will presumably continue waiting up to some timeout.  You should be able
> >> >> to use netstat to confirm or refute this.
> >> >
> >> > Thank you for your reply. I thought "reject" just rejected the request 
> >> > and nothing came to Apache?
> >> 
> >> You’re rejecting a packet that is part of an already-established TCP
> >> connection.  iptables cannot go back in time and prevent the TCP
> >> connection from being established in the first place.
> >
> > Yes, like I said - I thought nothing came through to Apache.  But
> > looking at server-status, it seems it does anyway?
> 
> I don’t know how to put it any more clearly; I give up.

No, please don't. Maybe I am misunderstanding you? I am not trying to 
argue with you.

I thought that rejecting the TCP request in iptables blocked the request 
from ever reaching the httpd process. Obviously it isn't blocked from 
the *machine*, and I apologize if you thought that was what I meant.

Mind you, I don't get any HTTP requests in Apache, but it does increment 
the requests number in a rate faster than the normal requests I see.

You are free to call me stupid and ignorant about iptables/httpd here, 
of course, but I would still very much like to solve my problem even so 
:)


-- 
Sandman[.net]

[toc] | [prev] | [next] | [standalone]

#290

On Friday, May 24th, 2013, at 12:23:54h +0200, Sandman pondered:

> I thought that rejecting the TCP request in iptables blocked the request 
> from ever reaching the httpd process. 

You need to re-read the very first reply from R J Kettlwell.

The sequence of events is, you have an open port 80, so
some remote host connects on port 80 to your Apache server
which then is waiting for data on what to do next.

Now you have suggested a rule

   iptables -I INPUT -p tcp --dport 80 -m string --to 70 --algo bm \
      --string "GET /wpad.dat" -j REJECT --reject-with tcp-reset

This will reject any packets containing the string "GET /wpad.dat"
but it will not close the already opened connection to apache
and furthermore will not block any packets from the host which do
 not contain the string "GET /wpad.dat".

              DONT' PANIC

A quick web search reveals that other people have had
this problem and it is probably not a malicious attack
but most probably misbehaving Windoze 7 clients.

Please read the discussion at

   <http://forums.freebsd.ORG/showthread.php?t=27668>

which after three pages offers a potential solution to the problem.

[toc] | [prev] | [next] | [standalone]

#293

In article <knnhma$50u$4@dont-email.me>, J G Miller <miller@yoyo.ORG> 
wrote:

> On Friday, May 24th, 2013, at 12:23:54h +0200, Sandman pondered:
> 
> > I thought that rejecting the TCP request in iptables blocked the request 
> > from ever reaching the httpd process. 
> 
> You need to re-read the very first reply from R J Kettlwell.
> 
> The sequence of events is, you have an open port 80, so
> some remote host connects on port 80 to your Apache server
> which then is waiting for data on what to do next.
> 
> Now you have suggested a rule
> 
>    iptables -I INPUT -p tcp --dport 80 -m string --to 70 --algo bm \
>       --string "GET /wpad.dat" -j REJECT --reject-with tcp-reset
> 
> This will reject any packets containing the string "GET /wpad.dat"
> but it will not close the already opened connection to apache
> and furthermore will not block any packets from the host which do
>  not contain the string "GET /wpad.dat".
> 
>               DONT' PANIC
> 
> A quick web search reveals that other people have had
> this problem and it is probably not a malicious attack
> but most probably misbehaving Windoze 7 clients.
> 
> Please read the discussion at
> 
>    <http://forums.freebsd.ORG/showthread.php?t=27668>
> 
> which after three pages offers a potential solution to the problem.

Yes, I have seen this thread, and they are talking about wildcard DNS 
being the culprit - I have yet to understand how this applies to me?

I mean - I *DO* use wildcard DNS for all domains that I have a DNS for. 
The DNS server is on the machine that is currently being flooded on port 
80. Ok. So the DNS is "ns1.mydomain.com" (for example).

So, for my clients - whose web pages I host on this machine, I tell 
*them* to point their subdomains (I.e. www.client.com) to the domainname 
"cluster.mydomain.com" as a CNAME record.

Now, when the visitor types in www.client.com into the web browser, 
their DNS says that that resolvs to cluster.mydomain.com - which in turn 
has an A record for an IP number. So in the end, they surf to 
cluster.mydomain.com asking for www.client.com

This works very good and has for more than a year.

Now, mydomain.com har a wildcard DNS, meaning that 
"lkjkljklj.mydomain.com" points to "cluster.mydomain.com" and then to 
the IP.

According to that thread, Internet Explorer and/or Windows makes 
assumptions about where to look for "wpad.dat", a javascript file that 
aims to provide the browser/hte OS info about proxy servers.

So, Windows/IE asks for "http://wpad.client.com:80/wpad.dat" (as far as 
I know) and that's where the problem is.

Now, to counter this:

 1. I have removed wildcard DNS on mydomain.com
    propagation may take a while though

 2. I am actively pointing wpad.mydomain.com to
    127.0.0.1, also waiting for the TTL there.

 3. I am trying to use iptables to block these accesses

The open questions seem to be several, which the forum thread doesn't 
seem to have an answer for:

 1. Why would thousands of clients per minute all over Sweden ask for 
    a wpad.dat file on *my* machine? According to the standard, they
    should be asking for it on wpad.*client.com*, not wpad.mydomain.com

 2. And why the *excessive* amount of traffic. several hundreds of IPS 
    make up thousands of requests per minute, meaning that one IP makes
    several requests often.

 3. Blocking these IP-number, would I also be blocking their normal 
    traffic to the server? Meaning, are these flooding some form of
    colleteral traffic from normal surfing?

Thanks for all your replies, guys. This is a huge problem for me right 
now...


-- 
Sandman[.net]

[toc] | [prev] | [next] | [standalone]

#295

Sandman <mr@sandman.net> writes:

>Yes, I have seen this thread, and they are talking about wildcard DNS 
>being the culprit - I have yet to understand how this applies to me?

All systems shipped these days are configured to search for a
automatic proxy configuration from "http://wpad/wpad.dat"

Because of your use of wildcard DNS *everyone* who starts their
webbrowser will find wpad.their.domain then look for it on
your webserver.

Your ip filtering rules block your customers; it also makes their
web experience interesting (it will take some time before the system
figures out that there is no wpad.dat and will then connect to
the internet directly)

>I mean - I *DO* use wildcard DNS for all domains that I have a DNS for. 
>The DNS server is on the machine that is currently being flooded on port 
>80. Ok. So the DNS is "ns1.mydomain.com" (for example).

Well, you shouldn't have done that.

> 1. Why would thousands of clients per minute all over Sweden ask for 
>    a wpad.dat file on *my* machine? According to the standard, they
>    should be asking for it on wpad.*client.com*, not wpad.mydomain.com

But you're serving their domains too, right?

Casper

[toc] | [prev] | [next] | [standalone]

#297

In article <519f6593$0$15954$e4fe514c@news2.news.xs4all.nl>,
 Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> wrote:

> >Yes, I have seen this thread, and they are talking about wildcard DNS 
> >being the culprit - I have yet to understand how this applies to me?
> 
> All systems shipped these days are configured to search for a
> automatic proxy configuration from "http://wpad/wpad.dat"

All? I thought it was Windows thing. 

> Because of your use of wildcard DNS *everyone* who starts their
> webbrowser will find wpad.their.domain then look for it on
> your webserver.

Why? I mean - when they go to wpad.their.domain, why would they end up 
with the IP of my server, or the CNAME of cluster.mydomain.com

That's the part I just can't understand.

> Your ip filtering rules block your customers; it also makes their
> web experience interesting (it will take some time before the system
> figures out that there is no wpad.dat and will then connect to
> the internet directly)

But the people surfing to my web server wouldn't be asking my server, 
any more than microsoft.com, for information about their own networks 
proxy settings, surely? 

> >I mean - I *DO* use wildcard DNS for all domains that I have a DNS for. 
> >The DNS server is on the machine that is currently being flooded on port 
> >80. Ok. So the DNS is "ns1.mydomain.com" (for example).
> 
> Well, you shouldn't have done that.

Fair enough, but I still don't know how that messed this up. I just 
can't wrap my head around it.

> > 1. Why would thousands of clients per minute all over Sweden ask for 
> >    a wpad.dat file on *my* machine? According to the standard, they
> >    should be asking for it on wpad.*client.com*, not wpad.mydomain.com
> 
> But you're serving their domains too, right?

No. Only my own domains. Their IT managers have set up their subdomains 
(i.e. www.) to point to cluster.mydomain.com which points to my IP





-- 
Sandman[.net]

[toc] | [prev] | [next] | [standalone]

#298

On Fri, 24 May 2013 15:14:19 +0200, Sandman wrote:

> In article <519f6593$0$15954$e4fe514c@news2.news.xs4all.nl>,
>  Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> wrote:
> 
>> >Yes, I have seen this thread, and they are talking about wildcard DNS
>> >being the culprit - I have yet to understand how this applies to me?
>> 
>> All systems shipped these days are configured to search for a automatic
>> proxy configuration from "http://wpad/wpad.dat"
> 
> All? I thought it was Windows thing.
> 
>> Because of your use of wildcard DNS *everyone* who starts their
>> webbrowser will find wpad.their.domain then look for it on your
>> webserver.
> 
> Why? I mean - when they go to wpad.their.domain, why would they end up
> with the IP of my server, or the CNAME of cluster.mydomain.com
> 
> That's the part I just can't understand.
> 
>> Your ip filtering rules block your customers; it also makes their web
>> experience interesting (it will take some time before the system
>> figures out that there is no wpad.dat and will then connect to the
>> internet directly)
> 
> But the people surfing to my web server wouldn't be asking my server,
> any more than microsoft.com, for information about their own networks
> proxy settings, surely?
> 
>> >I mean - I *DO* use wildcard DNS for all domains that I have a DNS
>> >for. The DNS server is on the machine that is currently being flooded
>> >on port 80. Ok. So the DNS is "ns1.mydomain.com" (for example).
>> 
>> Well, you shouldn't have done that.
> 
> Fair enough, but I still don't know how that messed this up. I just
> can't wrap my head around it.

Wildcard DNS is asking for issues unless you fully understand all the
ramifications. Best not to use it unless you really really need it and
fully understand it.

You have no entry for "wpad" so your wildcard is used. Get people off your
server by creating a wpad entry in your dns that points to a nonexistent
host or a host you want to handle that discovery traffic, even if only
to reject it.

[toc] | [prev] | [next] | [standalone]

#300

In article <knnqit$ib6$1@dont-email.me>,
 Joe Beanfish <joebeanfish@nospam.duh> wrote:

> >> Well, you shouldn't have done that.
> > 
> > Fair enough, but I still don't know how that messed this up. I just
> > can't wrap my head around it.
> 
> Wildcard DNS is asking for issues unless you fully understand all the
> ramifications. Best not to use it unless you really really need it and
> fully understand it.

Fair enough. 

> You have no entry for "wpad" so your wildcard is used.

Yes, that's how wildcards works - but not only do I not understand why 
thousands of hosts from all over the swedish internet would start to 
request wpad.* on my server, some of the up to thirty times per second - 
per host!

I am also not hosting any of their domains, so why would would they ever 
come to me to ask for this?

> Get people off your server by creating a wpad entry in your dns that 
> points to a nonexistent host or a host you want to handle that 
> discovery traffic, even if only to reject it.

I did that yesterday, didn't change a single thing... :(



-- 
Sandman[.net]

[toc] | [prev] | [next] | [standalone]

#299

Sandman <mr@sandman.net> writes:
>  Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> wrote:

>> Because of your use of wildcard DNS *everyone* who starts their
>> webbrowser will find wpad.their.domain then look for it on
>> your webserver.
>
> Why? I mean - when they go to wpad.their.domain, why would they end up 
> with the IP of my server, or the CNAME of cluster.mydomain.com
>
> That's the part I just can't understand.

Perhaps quoting some of the domain names involved would clarify matters.

-- 
http://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#301

In article <8761y8qxcr.fsf@araminta.anjou.terraraq.org.uk>,
 Richard Kettlewell <rjk@greenend.org.uk> wrote:

> >> Because of your use of wildcard DNS *everyone* who starts their
> >> webbrowser will find wpad.their.domain then look for it on
> >> your webserver.
> >
> > Why? I mean - when they go to wpad.their.domain, why would they end up 
> > with the IP of my server, or the CNAME of cluster.mydomain.com
> >
> > That's the part I just can't understand.
> 
> Perhaps quoting some of the domain names involved would clarify matters.

Yeah, ok.

So a client to me, for example http://www.stadsnat.se has their DNS set 
up as such:

> host www.stadsnat.se
www.stadsnat.se is an alias for cluster.atlascms.se.
cluster.atlascms.se has address 94.247.170.170

Now, atlascms.se WAS a wildcard DNS, but isn't any longer.

Even so, the requests I get look largely like this:

94.254.41.78 cluster.atlascms.se - [24/May/2013:16:25:24 +0200] "GET 
/wpad.dat HTTP/1.1" 200 70 "-" "Mozilla/5.0 (compatible; MSIE 10.0; 
Win32; Trident/6.0)"

I.e. a request to that domain name, not to a wpad subdomain. So the 
wildcard DNS thing doesn't seem to even apply... Or am I mistaken?



-- 
Sandman[.net]

[toc] | [prev] | [next] | [standalone]

#302

Sandman <mr@sandman.net> writes:
> Richard Kettlewell <rjk@greenend.org.uk> wrote:

>>>> Because of your use of wildcard DNS *everyone* who starts their
>>>> webbrowser will find wpad.their.domain then look for it on your
>>>> webserver.
>>>
>>> Why? I mean - when they go to wpad.their.domain, why would they end
>>> up with the IP of my server, or the CNAME of cluster.mydomain.com
>>>
>>> That's the part I just can't understand.
>> 
>> Perhaps quoting some of the domain names involved would clarify
>> matters.
>
> Yeah, ok.
>
> So a client to me, for example http://www.stadsnat.se has their DNS set 
> up as such:
>
>> host www.stadsnat.se
> www.stadsnat.se is an alias for cluster.atlascms.se.
> cluster.atlascms.se has address 94.247.170.170
>
> Now, atlascms.se WAS a wildcard DNS, but isn't any longer.
>
> Even so, the requests I get look largely like this:
>
> 94.254.41.78 cluster.atlascms.se - [24/May/2013:16:25:24 +0200] "GET 
> /wpad.dat HTTP/1.1" 200 70 "-" "Mozilla/5.0 (compatible; MSIE 10.0; 
> Win32; Trident/6.0)"
>
> I.e. a request to that domain name, not to a wpad subdomain. So the 
> wildcard DNS thing doesn't seem to even apply... Or am I mistaken?

I agree; I think the wildcard was probably a red herring, and the longer
it gets since you removed it, the more certain that is (although it’s
worth remembering that not all DNS clients honor TTLs correctly).

The request doesn’t seem consistent with the way that wpad searching is
described as working, but of course it may be that there’s more to the
implementation that the various descriptions online imply.

Do you have any idea how many distinct addresses are involved?  Are they
in fact _all_ Swedish IP addresses or are any of them from further
afield?  Can you tell whether any are associated with any of your
customers (e.g. if you keep logs of where they upload from, do any of
the oddly behaving clients appear there)?

Have you recently annoyed anyone who might have sufficiently poor
judgement to launch a DDoS attack?

-- 
http://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#305

In article <87d2sgl4e2.fsf@araminta.anjou.terraraq.org.uk>,
 Richard Kettlewell <rjk@greenend.org.uk> wrote:

> > Even so, the requests I get look largely like this:
> >
> > 94.254.41.78 cluster.atlascms.se - [24/May/2013:16:25:24 +0200] "GET 
> > /wpad.dat HTTP/1.1" 200 70 "-" "Mozilla/5.0 (compatible; MSIE 10.0; 
> > Win32; Trident/6.0)"
> >
> > I.e. a request to that domain name, not to a wpad subdomain. So the 
> > wildcard DNS thing doesn't seem to even apply... Or am I mistaken?
> 
> I agree; I think the wildcard was probably a red herring, and the longer
> it gets since you removed it, the more certain that is (although it’s
> worth remembering that not all DNS clients honor TTLs correctly).

Indeed.

> The request doesn’t seem consistent with the way that wpad searching is
> described as working, but of course it may be that there’s more to the
> implementation that the various descriptions online imply.

Or this seemingly benign request is used to stage a flood attack 
against me or my clients. Since google can't find any more serious 
attacks, especially not current one (there is that one forum post), I 
am starting to wonder why this is.

> Do you have any idea how many distinct addresses are involved?

I now have a cronjob that reads the access_log file for wpad.dat 
requests and then add them to a blacklist and to iptables. It has been 
in effect for maybe two hours and the list is 4000 IP's long. 4000 
seemingly normal swedish IP's from normal swedish ISP's. All 
bombarding me with millions of wpad.dat requests.

Some IP's send 30-40 requests per second in a burst. 

With 4000 in two hours, I'm guessing that tomorrow morning it will be 
over 10000, and then using iptables becomes increasingly stupid. 

> Are they in fact _all_ Swedish IP addresses or are any of them from 
> further afield?

I have made samples now and then - all have been swedish IP's 
according to various online ip -> location functions. 

> Can you tell whether any are associated with any of your
> customers (e.g. if you keep logs of where they upload from, do any of
> the oddly behaving clients appear there)?

Even so, I don't have anywhere near to 4000 customers so this can't be 
due to one of my clients faulty network either. This seems like a 
targeted attack.

> Have you recently annoyed anyone who might have sufficiently poor
> judgement to launch a DDoS attack?

I can think of only one person (from here on usenet) but he's from 
America and I doubt he has the ability to muster a botnet of 
Swedish-only clients. He has tried to flood me before, but only from a 
single IP. So no, I have to answer that I know of no one that could do 
this specifically against *me*. Maybe against one of my clients?

Because, if they were targetting me, they would target my homepage 
(sandman.net) or some other, these attacks seem to either target the 
IP or my cluster domain name - and the cluster domain is not something 
used for anything but DNS redirection.



-- 
Sandman[.net]

[toc] | [prev] | [next] | [standalone]

#307

Sandman <mr@sandman.net> writes:
> Richard Kettlewell <rjk@greenend.org.uk> wrote:

>> Can you tell whether any are associated with any of your customers
>> (e.g. if you keep logs of where they upload from, do any of the oddly
>> behaving clients appear there)?
>
> Even so, I don't have anywhere near to 4000 customers so this can't be 
> due to one of my clients faulty network either. This seems like a 
> targeted attack.

I don’t currently have a better theory.

>> Have you recently annoyed anyone who might have sufficiently poor
>> judgement to launch a DDoS attack?
>
> I can think of only one person (from here on usenet) but he's from
> America and I doubt he has the ability to muster a botnet of
> Swedish-only clients. He has tried to flood me before, but only from a
> single IP. So no, I have to answer that I know of no one that could do
> this specifically against *me*. Maybe against one of my clients?
> 
> Because, if they were targetting me, they would target my homepage
> (sandman.net) or some other, these attacks seem to either target the
> IP or my cluster domain name - and the cluster domain is not something
> used for anything but DNS redirection.

From what you’ve said (and I may be wrong) it sounds like it could be
targetting your source of income.  The ability to run a botnet
personally isn’t necessarily relevant, even if you’re right about that;
botnet operators rent them out.

-- 
http://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#313

In article <874ndsl1as.fsf@araminta.anjou.terraraq.org.uk>,
 Richard Kettlewell <rjk@greenend.org.uk> wrote:

> > I can think of only one person (from here on usenet) but he's from
> > America and I doubt he has the ability to muster a botnet of
> > Swedish-only clients. He has tried to flood me before, but only from a
> > single IP. So no, I have to answer that I know of no one that could do
> > this specifically against *me*. Maybe against one of my clients?
> > 
> > Because, if they were targetting me, they would target my homepage
> > (sandman.net) or some other, these attacks seem to either target the
> > IP or my cluster domain name - and the cluster domain is not something
> > used for anything but DNS redirection.
> 
> From what you’ve said (and I may be wrong) it sounds like it could be
> targetting your source of income.  The ability to run a botnet
> personally isn’t necessarily relevant, even if you’re right about that;
> botnet operators rent them out.

I didn't know that :)

Thanks for your comments, it's a possible scenario I suppose.


-- 
Sandman[.net]

[toc] | [prev] | [next] | [standalone]

#303

Sandman <mr@sandman.net> writes:

>> host www.stadsnat.se
>www.stadsnat.se is an alias for cluster.atlascms.se.
>cluster.atlascms.se has address 94.247.170.170

>Now, atlascms.se WAS a wildcard DNS, but isn't any longer.

So when someone looked up wpad.stadsnet.se it was mapped
to cluster.atlascms.se?  That, I think, is the root
of your problem.

>Even so, the requests I get look largely like this:

>94.254.41.78 cluster.atlascms.se - [24/May/2013:16:25:24 +0200] "GET 
>/wpad.dat HTTP/1.1" 200 70 "-" "Mozilla/5.0 (compatible; MSIE 10.0; 
>Win32; Trident/6.0)"

>I.e. a request to that domain name, not to a wpad subdomain. So the 
>wildcard DNS thing doesn't seem to even apply... Or am I mistaken?

I wouldn't be too sure about that.  Note that wpad/wpad.dat is looked
with a different algorithm then ordinary websites because it needs
to sidestep the proxies and such.

Casper

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.os.linux.security

csiph-web