Linux Problem with nuker? (LOGIN OFF) - HELP IPTABLES

[natanl2]

Good morning!

I'm having the following problems in my server. Yesterday (20/06/2013), before we reached 328 player online, a "nuker" came and asked for itens or LOGIN DOWN... We never gave itens to nukers, so we didn't accept. So, the player did something that the login server was OFFLINE.

Problem characteristics:

1- Server is totally without LAG for those who are logged in, like as normal.
2- The website of our server is normal, without any problem.
3- The network does not show any oscillation.
4- When you enter your account, the character appears, however, when you try to select the character the error appears: Connection Lost...
5- When I reboot the server the login back to normal until it 'drop' again.

Information about the machine:

Ubuntu.
GOOD REV from OTland.
IPtables + CISCO.

If anyone knows how to solve it...

Sorry for bad english, I'm from Brazil.

Site: Gauchot - Global Extreme - Ultimas noticias

 

[Fec]

Lolz, maybe you have a script in engine which blocking login into server. Check your source (commands.cpp mostly) and lua scripts (talkactions ?).

 

[DestinationSer]

From what i understood from what you wrote it seems like that person must have DDoS'ed you. (Distributed Denial of Service) which means, he simply sends packages to you're router till your router cant handle no more.

 

[Danger II]

He got CISCO + Iptables, dont think its easy to get ddosd with these soft/hardware, maybe any exploit?
Any bugged lua/php/xml script?
Maybe a NPC?
Its hard to find out how he did it with those informations(didnt understand alot anyway )

 

[DestinationSer]

I already checked hes site for any obvious errors, no errors found from what i searched for

- - - Updated - - -

But, he better check this ingame
- Aleta sio/Som usually crashes the ot because of bugged creaturescripts
- If he uses reflect on hes server fire/energy damage may crash the server due to the person reflecting damage on himself

 

[natanl2]

Lolz, maybe you have a script in engine which blocking login into server. Check your source (commands.cpp mostly) and lua scripts (talkactions ?).

No, isn't. We don't have any errors in the exe... And the login only 'drops' when this 'nukerguy' say..

From what i understood from what you wrote it seems like that person must have DDoS'ed you. (Distributed Denial of Service) which means, he simply sends packages to you're router till your router cant handle no more.

No, if it was DDoS we'd have an oscilation in our network.

He got CISCO + Iptables, dont think its easy to get ddosd with these soft/hardware, maybe any exploit?
Any bugged lua/php/xml script?
Maybe a NPC?
Its hard to find out how he did it with those informations(didnt understand alot anyway )

I guess that we have a 'nice protection', not good, but 'nice'.. And we have no errors with NPC's.. xml's...

I already checked hes site for any obvious errors, no errors found from what i searched for

- - - Updated - - -

But, he better check this ingame
- Aleta sio/Som usually crashes the ot because of bugged creaturescripts
- If he uses reflect on hes server fire/energy damage may crash the server due to the person reflecting damage on himself

We have already tested it :/


Thank you everyone for trying to help!
We're testing a new REV right now.

 

[fluidsonic]

What server software are you using?

EDIT: i.e. what game server software? TFS? What version?

 

[psychomen]

As you said clearly the guy is attacking the login server directly.

In this cases, the only way to figure out what happening is to put a sniffer program in your login server port to get all packets it receives and when the login serve dies, analyzes the packets to see what happened different from the others.

You can use the TCPDUMP or Wireshark for this.

Regards,

 

[fluidsonic]

What software do you use for the login server?

I'd like to look at the source code to see if I can spot something.

 

[natanl2]

What software do you use for the login server?

I'd like to look at the source code to see if I can spot something.

8.6.
TFS 0.4
UBUNTU.

As you said clearly the guy is attacking the login server directly.

In this cases, the only way to figure out what happening is to put a sniffer program in your login server port to get all packets it receives and when the login serve dies, analyzes the packets to see what happened different from the others.

You can use the TCPDUMP or Wireshark for this.

Regards,

Thank you guys, the nuker attacked again. We're with LOGIN OFF :/

Someone knows how to buy the best TFS of OTLAND? I want to buy it. Maybe is this the problem..

 

[DestinationSer]

Must be a bug in your server somehow. have u checked the map closely? maps can sometimes trigger a crash

 

[natanl2]

The problem was fixed using a new IPtables. But now, we have another problem... Some players can not connect... Someone knows how to help?

IPtables:

# Block connection
iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
iptables -A FORWARD -p tcp ! --syn -m state --state NEW -j DROP

# Drop fragmented packets
iptables -A INPUT -f -j DROP
iptables -A FORWARD -f -j DROP

# Drop connections in INVALID state
iptables -A INPUT -m state --state INVALID -j DROP
iptables -A FORWARD -m state --state INVALID -j DROP

iptables -A INPUT -i lo -j ACCEPT

# NULL scanning detection
iptables -A INPUT -p tcp --tcp-flags ALL NONE -m limit --limit 10/s --limit-burst 4 -j LOG --log-level debug --log-prefix "firewall: SKAN_NULL: "
iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP

# NEW packets without SYN flah are always suspicious
iptables -N scans
iptables -A INPUT -p tcp ! --syn -m state --state NEW -j scans
iptables -A scans -p tcp --tcp-flags ALL RST -m limit --limit 10/s --limit-burst 4 -j LOG --log-level debug --log-prefix "firewall: SKAN_INVERSE: "
iptables -A scans -p tcp --tcp-flags ALL RST -j DROP
iptables -A scans -p tcp --tcp-flags ALL ACK -m limit --limit 10/s --limit-burst 4 -j LOG --log-level debug --log-prefix "firewall: SKAN_TCP_PING: "
iptables -A scans -p tcp --tcp-flags ALL ACK -j DROP
iptables -A scans -p tcp --tcp-flags ALL FIN -m limit --limit 10/s --limit-burst 4 -j LOG --log-level debug --log-prefix "firewall: SKAN_FIN: "
iptables -A scans -p tcp --tcp-flags ALL FIN -j DROP
iptables -A scans -p tcp --tcp-flags ALL FIN,PSH,URG -m limit --limit 10/s --limit-burst 4 -j LOG --log-level debug --log-prefix "firewall: SKAN_XMAS-NMAP: "
iptables -A scans -p tcp --tcp-flags ALL FIN,PSH,URG -j DROP
iptables -A scans -p tcp -m limit --limit 10/s --limit-burst 4 -j LOG --log-level debug --log-prefix "firewall: SKAN_INNE: "
iptables -A scans -j DROP

# packets from unwanted sources
iptables -A INPUT -s 178.217.184.190 -j DROP # Land attack
iptables -A INPUT -s 10.0.0.0/8 -j DROP # A class
iptables -A INPUT -s 172.16.0.0/12 -j DROP # B class
iptables -A INPUT -s 192.168.0.0/16 -j DROP # C class
iptables -A INPUT -s 224.0.0.0/4 -j DROP # multicast
iptables -A INPUT -d 224.0.0.0/4 -j DROP # multicast
iptables -A INPUT -s 240.0.0.0/5 -j DROP # reserved

# OTS - limit concurrent connections
iptables -A INPUT -p tcp -m recent --rcheck --seconds 60 -j DROP
iptables -A INPUT -p tcp --dport 7171 -m connlimit --connlimit-above 10 -m recent --set -j DROP
iptables -A INPUT -p tcp --dport 7172 -m connlimit --connlimit-above 10 -m recent --set -j DROP

#Iptable rules for common floods attacks
iptables -N conn-flood
iptables -I INPUT 1 -p tcp .syn -j conn-flood
iptables -A conn-flood -m limit .limit 7/s .limit-burst 20 -j RETURN
iptables -A conn-flood -j DROP
iptables -A INPUT -p icmp -m limit --limit 1/s --limit-burst 1 -j ACCEPT
iptables -A INPUT -p icmp -j DROP
iptables -I INPUT -p tcp -m state --state NEW,ESTABLISHED -m recent --set -j ACCEPT
iptables -I INPUT -p tcp -m state --state NEW -m recent --update --seconds 3 --hitcount 20 -j DROP

iptables -A INPUT -p icmp -m limit --limit 15/s -j ACCEPT


# Tibia ( Otserv )
iptables -A INPUT -p tcp --dport 7171 -j ACCEPT
iptables -A INPUT -p tcp --dport 7172 -j ACCEPT

Thank you everyone.

 

[fluidsonic]

You could come closer to the connection problem by selectively disabling some of the iptables rules.
AS soon as the players can connect again you know what rule caused the problem.

The actual problem where the login server goes down may still be a layer 7 attack, which would be great if we can spot and fix it.
It might also help if you could find out which of the iptables rules "fixed" the problem.
It could also have happened that you just locked out the attacked completely (like you did with some players) - which didn't fix the problem but just kept one possible attacker away.

 

[natanl2]

Hmm! Good idea!

I'll try!

Thank you!

You could come closer to the connection problem by selectively disabling some of the iptables rules.
AS soon as the players can connect again you know what rule caused the problem.

The actual problem where the login server goes down may still be a layer 7 attack, which would be great if we can spot and fix it.
It might also help if you could find out which of the iptables rules "fixed" the problem.
It could also have happened that you just locked out the attacked completely (like you did with some players) - which didn't fix the problem but just kept one possible attacker away.