Strange requests activity

[teckays]

Hi there, I've noticed some strange random requests NOT directed to valve/steam servers. I'm not sure if you're aware of this, you might be though and I'd like to know your opinion on this because now I feel that your library is doing some nasty things and that's bad for you and for the library itself.

In case you're not aware, would you be interested in collaboration to find out what's going on? I can provide you privately with all logs I have in order to track where these connections are going and why.

Thanks!

[jimmydorry]

Make an issue please, or fire away in this one. If it's not public now, it could be made public at any point in time.

[teckays]

OK, so here are the logs I received from my hosting company. To mention that I had 2 servers blocked and unable to recover because of this (no refund). The logs will be posted in a chronological order

- START OF ADDITIONAL INFORMATION -
Attack detail : 125Kpps/27Mbps
dateTime                   srcIp:srcPort           dstIp:dstPort           protocol flags       bytes reason               
2016.02.16 03:52:42 CET    164.132.101.189:57105   104.153.108.20:27015    UDP      ---            29 ATTACK:UDP           
2016.02.16 03:52:42 CET    164.132.101.189:57105   104.153.108.20:27015    UDP      ---            29 ATTACK:UDP           
2016.02.16 03:52:42 CET    164.132.101.189:57105   104.153.108.20:27015    UDP      ---            29 ATTACK:UDP           
2016.02.16 03:52:42 CET    164.132.101.189:57105   104.153.108.20:27015    UDP      ---            29 ATTACK:UDP           
2016.02.16 03:52:42 CET    164.132.101.189:57105   104.153.108.20:27015    UDP      ---            29 ATTACK:UDP           
2016.02.16 03:52:42 CET    164.132.101.189:57105   104.153.108.20:27015    UDP      ---            29 ATTACK:UDP           
2016.02.16 03:52:42 CET    164.132.101.189:57105   104.153.108.20:27015    UDP      ---            29 ATTACK:UDP           
2016.02.16 03:52:42 CET    164.132.101.189:57105   104.153.108.20:27015    UDP      ---            29 ATTACK:UDP           
2016.02.16 03:52:42 CET    164.132.101.189:57105   104.153.108.20:27015    UDP      ---            29 ATTACK:UDP           
2016.02.16 03:52:42 CET    164.132.101.189:57105   104.153.108.20:27015    UDP      ---            29 ATTACK:UDP           
2016.02.16 03:52:42 CET    164.132.101.189:57105   104.153.108.20:27015    UDP      ---            29 ATTACK:UDP           
2016.02.16 03:52:42 CET    164.132.101.189:57105   104.153.108.20:27015    UDP      ---            29 ATTACK:UDP           
2016.02.16 03:52:42 CET    164.132.101.189:57105   104.153.108.20:27015    UDP      ---            29 ATTACK:UDP           
2016.02.16 03:52:42 CET    164.132.101.189:57105   104.153.108.20:27015    UDP      ---            29 ATTACK:UDP           
2016.02.16 03:52:42 CET    164.132.101.189:57105   104.153.108.20:27015    UDP      ---            29 ATTACK:UDP           
2016.02.16 03:52:42 CET    164.132.101.189:57105   104.153.108.20:27015    UDP      ---            29 ATTACK:UDP           
2016.02.16 03:52:42 CET    164.132.101.189:57105   104.153.108.20:27015    UDP      ---            29 ATTACK:UDP           
2016.02.16 03:52:42 CET    164.132.101.189:57105   104.153.108.20:27015    UDP      ---            29 ATTACK:UDP           
2016.02.16 03:52:42 CET    164.132.101.189:57105   104.153.108.20:27015    UDP      ---            29 ATTACK:UDP           
2016.02.16 03:52:42 CET    164.132.101.189:57105   104.153.108.20:27015    UDP      ---            29 ATTACK:UDP           
-  END OF ADDITIONAL INFORMATION  -

- START OF ADDITIONAL INFORMATION -
Attack detail : 13Kpps/100Mbps
dateTime                   srcIp:srcPort           dstIp:dstPort           protocol flags       bytes reason               
2016.02.24 09:50:48 CET    51.254.102.91:3148      192.126.126.72:80       TCP      SYN          1010 ATTACK:TCP_SYN       
2016.02.24 09:50:48 CET    51.254.102.91:15333     192.126.126.72:80       TCP      SYN          1010 ATTACK:TCP_SYN       
2016.02.24 09:50:48 CET    51.254.102.91:56958     192.126.126.72:80       TCP      SYN          1010 ATTACK:TCP_SYN       
2016.02.24 09:50:48 CET    51.254.102.91:53157     192.126.126.72:80       TCP      SYN          1010 ATTACK:TCP_SYN       
2016.02.24 09:50:48 CET    51.254.102.91:49078     192.126.126.72:80       TCP      SYN          1010 ATTACK:TCP_SYN       
2016.02.24 09:50:48 CET    51.254.102.91:7420      192.126.126.72:80       TCP      SYN          1010 ATTACK:TCP_SYN       
2016.02.24 09:50:48 CET    51.254.102.91:18244     192.126.126.72:80       TCP      SYN          1010 ATTACK:TCP_SYN       
2016.02.24 09:50:48 CET    51.254.102.91:2526      192.126.126.72:80       TCP      SYN          1010 ATTACK:TCP_SYN       
2016.02.24 09:50:48 CET    51.254.102.91:38249     192.126.126.72:80       TCP      SYN          1010 ATTACK:TCP_SYN       
2016.02.24 09:50:48 CET    51.254.102.91:38120     192.126.126.72:80       TCP      SYN          1010 ATTACK:TCP_SYN       
2016.02.24 09:50:48 CET    51.254.102.91:45144     192.126.126.72:80       TCP      SYN          1010 ATTACK:TCP_SYN       
2016.02.24 09:50:48 CET    51.254.102.91:28635     192.126.126.72:80       TCP      SYN          1010 ATTACK:TCP_SYN       
2016.02.24 09:50:48 CET    51.254.102.91:46836     192.126.126.72:80       TCP      SYN          1010 ATTACK:TCP_SYN       
2016.02.24 09:50:48 CET    51.254.102.91:37781     192.126.126.72:80       TCP      SYN          1010 ATTACK:TCP_SYN       
2016.02.24 09:50:48 CET    51.254.102.91:14791     192.126.126.72:80       TCP      SYN          1010 ATTACK:TCP_SYN       
2016.02.24 09:50:48 CET    51.254.102.91:4299      192.126.126.72:80       TCP      SYN          1010 ATTACK:TCP_SYN       
2016.02.24 09:50:48 CET    51.254.102.91:38625     192.126.126.72:80       TCP      SYN          1010 ATTACK:TCP_SYN       
2016.02.24 09:50:48 CET    51.254.102.91:11046     192.126.126.72:80       TCP      SYN          1010 ATTACK:TCP_SYN       
2016.02.24 09:50:48 CET    51.254.102.91:48378     192.126.126.72:80       TCP      SYN          1010 ATTACK:TCP_SYN       
2016.02.24 09:50:48 CET    51.254.102.91:17807     192.126.126.72:80       TCP      SYN          1010 ATTACK:TCP_SYN       
-  END OF ADDITIONAL INFORMATION  -

[jimmydorry]

That was less info than I expected. What were you doing with the library? You can audit our code, but it shouldn't make random requests.

More specifically, were you banned for receiving an attack or causing one?

I think the first step you should take is to figure out what you were running codewise. We can't even start to help until we know what you were doing.

[jimmydorry]

Also, I was assuming that the src column is yours. If so, feel free to censor it.

Destination num 1 is a cs:go server. If that is not yours, then the log indicates you were attacking it. This is not something the library would ever do. http://www0.gametracker.com/server_info/104.153.108.20:27015/

The second log indicates that you were attacking a website. Which is again something the library would not do.

[teckays]

@jimmydorry I know the info is way to little but I don't have any options to login to the server and do any debugging, the only way would be to buy another server and log everything I can.

Also, I was assuming that the src column is yours. If so, feel free to censor it.

Yes, that IP was hours until the server has been blocked and taken away, it's a VPS btw, so no big deal to expose it.

More specifically, were you banned for receiving an attack or causing one?

I was banned for causing an attack.

About the use: I didn't do anything special, just launched the server and made some simple requests to it. I didn't have anything except node-dota2 and the server was brand new and intended strongly for this library and nothing else.

[Crazy-Duck]

No offense, but going by those logs (especially the second one) I can see why you got booted. Second log shows a classic and VERY obvious attempt at a DOS attack by SYN flooding the server. Furthermore, I can assure you that nothing in node-dota2 would cause this kind of behaviour, we even have specific counter-measures in place to prevent exactly this from happening (via rate-limiting on the login). Besides, the library would never try to connect to a cs:go server or a random website, since it's hard-wired to only contact the Dota2 GC...
So if your code is causing this kind of behaviour, it has most definitely something to do with the way you're using the library. Based on the information you've given us so far, we have literally zero way of determining what it is you're exactly doing. Unless you actually post your source code, there is very little we can do.

[teckays]

@Crazy-Duck I can give you access to the repository which happens to be on bitbucket, if you have an account there then send me your username and I'll add you.

In few words, the only stack we have is using node-dota2 and loopback as a top layer to communicate with it through an API.

Second log shows a classic and VERY obvious attempt at a DOS attack by SYN flooding the server.

Well if I would intentionally do this then I definitely wouldn't open this issue here. So the only option here is: someone somehow used our server for doing nasty stuff, which I can't think of a way for this being possible

[Crazy-Duck]

bitbucket username: Crazy-Duck

[jimmydorry]

I'm putting $5 on compromised machine, with nothing relevant to node-dota2. 🎱

[teckays]

@Crazy-Duck done!

[Crazy-Duck]

found it, i'll have a look at it

[Crazy-Duck]

Alright, Imma go wiith @jimmydorry here. I've looked around somewhat in your repo and I don't find anything shocking. As far as I can see on a quick glance, you're using the library as it should and none of it should be causing the above mentioned behaviour. Going by the password complexity I found in your config files, your server was most likely compromised by someone who used it to mount a DOS (UDP and SYN flood) attack on someones dedicated CS servers; probably a mad skiddy who got kicked from the server.
I'm afraid there's not much we can do here (apart from burning you on a stake for writing semi-colonless JS), the issue is clearly not node-dota2. Issue can be closed.

[teckays]

@Crazy-Duck too bad we can't even ask for our money back, 2 servers in one week, down for the same "attacks" reason, should I blame OVH here? (decided to say their name, because if your library is clean then they should take the responsibility for it.

[jimmydorry]

It sounds like your setup was insecure, so I don't think OVH will do anything. I've had servers with OVH for at least two years, without a hitch. The best things you can do to lockdown your server is setup public/private key authentication for your ssh server and disable password authentication completely.

http://www.unixwiz.net/techtips/putty-openssh.html

The second best is to use long random passwords for all other public facing apps.

[teckays]

@jimmydorry we've been their customers for the last 4 years, I won't say that I'm expert but we know how to secure access to our servers, we use only ssh for deploying our code. I wonder if you'd deploy your library on a shared VPS2 (as we did) server, would this happen to you as well?!

[jimmydorry]

It would not, and has not so far. Have a look at the code yourself. The meat of the library is in the handlers folder, and the rest is in index.js .