Hello All,

-----------
Problem 1:
-----------
Our web server is constantly beeing attacked by some IP (example 
94-182-237-7.rasana.net).
It establishes a tcp/ip connection to port 1024 (or any other configured), 
which WAA1SRV.EXE is listening and answer: Then the CPU usage goes to 100%.

I already block the IP on IIS but is not effective because it doesn't come 
that way.

Question 1: Is there a way to tell WAA1SRV.EXE to refuse such addresses?

-----------
Problem 2
-----------
When trying to reproduce this behaviour i used HyperTerminal from Windows to 
establish the connection.
The WAA1SRV.EXE answer normally and then i start typing in HyperTerminal (no 
matter what) and the WAA1SRV.EXE crashes with FATAL ERROR.
The log files are attached

Question 2: This was not suppose to happen, right?

Best Regards,
Paulo Pinheiro

"Paulo Pinheiro" <paulo.pinheiro@modulac.pt> wrote in
news:58b4784d$3757fa15$583ac@news.alaska-software.com: 

> Our web server is constantly beeing attacked by some IP (example 
> 94-182-237-7.rasana.net).
> It establishes a tcp/ip connection to port 1024 (or any other
> configured), which WAA1SRV.EXE is listening and answer: Then the CPU
> usage goes to 100%. 
> 
> I already block the IP on IIS but is not effective because it doesn't
> come that way.
> 
> Question 1: Is there a way to tell WAA1SRV.EXE to refuse such
> addresses? 


I use a tarpit function on my Xb2.NET webserver to slow down hackers. 
Here's the Xb2.NET code which you can easily convert to WAA:
http://news.xb2.net/newsgroups.php?art_group=xb2net&article_id=1610

Working sample: http://live.xb2.net/tarpit?x

Best regards,
Boris Borzic

http://xb2.net
http://sqlexpress.net
industrial strength Xbase++ development tools

Paulo Pinheiro wrote:

> I already block the IP on IIS but is not effective because it doesn't come 
> that way.

Not sure what you are trying to say with this... but blocking on network
level (before the request reaches the WAA server) is the best option you
have because trying to block inside WAA1SRV.EXE means that the attacker
just needs a little bit more resources to overload waa1srv.exe with the
actual blocking of the requests.

Most likely you should be able to use the Windows firewall to block the
requests (or your ISP might be able to block those requests at the gateway
before they reach your server)

> Question 2: This was not suppose to happen, right?

Quite obvoiusly you are right  

I have just tried with firefox on my local test system
(http://localhost:2024), but could not reproduce the crash you described. 

I do get a wroker thread error, but not a complete crash.

If you are right, this would mean that waa1srv.exe is prone to DOS-attacks
simply by sending malformed requests.

In that case Alaska should be informed.

BUT (well, there had to be a but ) - you never should expose the
machine running waa to the public internet anyway (or take apporpriate
means to prevent access)

I have now checked something different and there seems to be no way at
all to bind the WAA to a specific IP address... it always listens on all
addresses (0.0.0.0:port)

Not sure what WAA_HOST is exactly used for anyway, but obviously not for
that purpose.

IMHO it should be possible to bind waa1srv.exe to localhost (127.0.0.1) so
only the server on which WAA is running can access WAA (in case the web
server and the WAA server is the same machine).

Maybe someone from Alaska can shed a light on this.

regards
Thomas