SRCDS Steam group


srcds DOS attack?
#31
Do you use HLSW? Do your players use HLSW?

HLSW seems to be blocked by the iptables rule at least partially. You can see that many of the blocked packets are using port number 7130. Some of the other ports are probably also by HLSW, which has been configured differently.
Reply
#32
no HLSW installed
[Image: b_560x95.png]
Reply
#33
Can you tell me then what is this http://c400.ru/index.php?newsid=63176 ?

Here it says HLSW uses port 7130 http://wiki.hlsw.net/index.php/LogAddress:_Time_out#HLSW_is_using_the_wrong_IP-Adress

Look at your syslog file again and search for port 7130. Then look at the IP addresses and either see your game server logs or search from Psychostats / HLStatsX for the IP addresses. Those are probably players on your server who are using HLSW to connect to your server. In the connecting process HLSW probably tries to RCON connect to the server or something.
Reply
#34
the post tells about hlsw software. So it is not preconfigured to connect to my server. The same was if i have a post about Linux Ubuntu - this does not mean that everybody plays on it....

Let`s get back to the topic. May by we can create a kind of a rule, wich would not drop harmless connections?
[Image: b_560x95.png]
Reply
#35
(11-03-2009, 11:13 PM)c400 Wrote:  May by we can create a kind of a rule, wich would not drop harmless connections?

First of all you need to understand what the rules are. Now you're seeing text "SRCDS:ATTACK" and you think it's something bad immediately. In reality it's packet sent by HLSW, which gets dropped and falsely logged as an attack.

Look at the timestamps. They are about 1-5 minutes apart. Under attack you will see 2 lines per second! Look at the rule, it says --limit 2/sec, which means it will write at most 2 lines per second.

Now you have to figure out what is this traffic. Nobody else (me, lhffan, jheiv, else?) have seen normal traffic being dropped.

I see that your servers are listed at http://css.setti.info/servers/full/page/1/search/95.31.2.145 which means they are cracked. Are you sure you or your players are not using some special means to connect to your server which might cause this mysterious network traffic?
Reply
#36
Quote:Look at the timestamps. They are about 1-5 minutes apart. Under attack you will see 2 lines per second! Look at the rule, it says --limit 2/sec, which means it will write at most 2 lines per second.

i understand this. I am talking about

Quote:Oct 26 02:32:37 QWERTY1 [ 458.370693] SRCDS:ATTACK: IN=ppp0 OUT= MAC= SRC=84.242.227.153 DST=95.31.2.145 LEN=28 TOS=0x00 PREC=0x00 TTL=111 ID=31944 PROTO=UDP SPT=57627 DPT=27020 LEN=8
Oct 26 02:32:37 QWERTY1 [ 458.860115] SRCDS:ATTACK: IN=ppp0 OUT= MAC= SRC=84.242.227.153 DST=95.31.2.145 LEN=28 TOS=0x00 PREC=0x00 TTL=111 ID=4383 PROTO=UDP SPT=57627 DPT=27020 LEN=8
Oct 26 02:32:38 QWERTY1 [ 459.380447] SRCDS:ATTACK: IN=ppp0 OUT= MAC= SRC=84.242.227.153 DST=95.31.2.145 LEN=28 TOS=0x00 PREC=0x00 TTL=111 ID=9694 PROTO=UDP SPT=57627 DPT=27020 LEN=8
Oct 26 02:32:38 QWERTY1 [ 459.800874] SRCDS:ATTACK: IN=ppp0 OUT= MAC= SRC=84.242.227.153 DST=95.31.2.145 LEN=28 TOS=0x00 PREC=0x00 TTL=111 ID=14501 PROTO=UDP SPT=57627 DPT=27020 LEN=8
Oct 26 02:32:39 QWERTY1 [ 460.370479] SRCDS:ATTACK: IN=ppp0 OUT= MAC= SRC=84.242.227.153 DST=95.31.2.145 LEN=28 TOS=0x00 PREC=0x00 TTL=111 ID=21273 PROTO=UDP SPT=57627 DPT=27020 LEN=8
Oct 26 02:32:39 QWERTY1 [ 460.841029] SRCDS:ATTACK: IN=ppp0 OUT= MAC= SRC=84.242.227.153 DST=95.31.2.145 LEN=28 TOS=0x00 PREC=0x00 TTL=111 ID=26407 PROTO=UDP SPT=57627 DPT=27020 LEN=8
Oct 26 02:32:40 QWERTY1 [ 461.320398] SRCDS:ATTACK: IN=ppp0 OUT= MAC= SRC=84.242.227.153 DST=95.31.2.145 LEN=28 TOS=0x00 PREC=0x00 TTL=111 ID=31324 PROTO=UDP SPT=57627 DPT=27020 LEN=8
Oct 26 02:32:40 QWERTY1 [ 461.810540] SRCDS:ATTACK: IN=ppp0 OUT= MAC= SRC=84.242.227.153 DST=95.31.2.145 LEN=28 TOS=0x00 PREC=0x00 TTL=111 ID=3511 PROTO=UDP SPT=57627 DPT=27020 LEN=8

and i am using revemu. Seems no extradata should be sent...
[Image: b_560x95.png]
Reply
#37
It looks like attack. See if it was anyone of your players and ask him. If it wasn't, then don't worry. It didn't crash the server, did it?
Reply
#38
(11-04-2009, 06:08 AM)css Wrote:  It looks like attack. See if it was anyone of your players and ask him. If it wasn't, then don't worry. It didn't crash the server, did it?

the server crashes !!!very!!! often! But anyway thanks alot!
[Image: b_560x95.png]
Reply
#39
I have seen similar when connecting with hlsw through an vpn. Noticed then that the ip was my vpn ip.

Does anyone else has acess to your server via hlsv (rcon)?

edit1:
Tip: Investigate what ip it is. One of your players, yours, any of your admins with hlsw(rcon), you with vpn.

edit2:
Googled that ip found this
http://cs.mxc.ru/cs/player.php?id=4310

^ same ip
Reply
#40
http://www.netip.de/search?query=84.242.227.153
Seems not to be a static ip, So blocking it with iptables wont help.
Reply
#41
(11-05-2009, 06:34 PM)Terrorkarotte Wrote:  http://www.netip.de/search?query=84.242.227.153
Seems not to be a static ip, So blocking it with iptables wont help.

You haven't understood what we've been discussing in this thread. The iptables rule blocks the attack. Blocking it with iptables will help.

PS. I happen to know the IP is static.
Reply
#42
uhm i have added this log rule but where do i find or see those logattacker file ...
Reply
#43
/var/log/messages
Reply
#44
Code:
# DROP all incomming traffic
$IPT -P INPUT DROP
$IPT -P OUTPUT DROP
$IPT -P FORWARD DROP

Code:
iptables -N logattacker
$IPT -A INPUT -p udp --destination-port 1200 -m state --state NEW,ESTABLISHED,RELATED  -j ACCEPT
$IPT -A OUTPUT -p udp --sport 1200 -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -A INPUT -p tcp --destination-port 27015:27035 -m state --state NEW,ESTABLISHED,RELATED  -j ACCEPT
$IPT -A OUTPUT -p udp --sport 27015:27035 -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -A INPUT -p udp --destination-port 27000:27050 -m state --state NEW,ESTABLISHED,RELATED  -j ACCEPT
$IPT -A OUTPUT -p udp --sport 27000:27050 -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -A INPUT -p udp -m udp --dport 27015 -m length --length 0:32 -j logattacker
$IPT -A INPUT -p udp -m udp --dport 27035 -m length --length 0:32 -j logattacker
$IPT -A logattacker -j LOG --log-prefix "SRCDS:ATTACK: " --log-ip-options -m limit --limit 2/sec
$IPT -A logattacker -j DROP

my rules atm. The server works fine and users can login. But i have a feelling that atm the logattacker drop wont work when i have INPUT .... accept on those ports?
Reply
#45
(12-29-2009, 06:16 AM)lhffan Wrote:  But i have a feelling that atm the logattacker drop wont work when i have INPUT .... accept on those ports?

You have right feeling. The first matching ACCEPT is used and the other rules are not applied after that.

You can solve the problem by moving the logattacker rules above the ACCEPT rules. That way the 0-32 bytes length packets are first matching the logattacker rule and thus handled properly in the logattacker chain. The packets don't get back to the INPUT chain from the logattacker chain, so they are dropped correctly. All other traffic (packets larger than 32 bytes) are handled normally by the ACCEPT rules.
Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)