Protecting a Lineage 2 server from DDoS attacks

A private Lineage 2 server where nobody gets past the login screen in the evening, while the players already in the world keep playing undisturbed, does not have a hardware problem. That is the fingerprint of a DDoS attack on the login server, and that is exactly where Lineage 2 DDoS protection has to start. This article begins with what you can secure yourself at no extra cost, then shows where those measures technically end, and finally explains what has to happen in the network in front of the server.

Everything here refers to L2J and its forks (L2J Mobius, aCis) on Debian 12, Debian 13, Ubuntu 22.04 LTS or Ubuntu 24.04 LTS, as well as to L2OFF packs built from AuthD, CacheD and L2Server. The commands are written for root. As a normal user, put sudo in front of them.

If the attack is running right now: do not change anything in the configuration and do not restart the login server or the game server. Capture the measurements first (see the section "Logging"), because once the attack is over they are gone.

Protecting a Lineage 2 server from DDoS: why private L2 servers get attacked

A private Lineage 2 server combines several traits that make it a convenient target, and Lineage 2 DDoS protection has to address exactly those traits. First, your address is public from day one: players download a patched System folder, and its l2.ini contains the line ServerAddr= with the IP address of your login server. Anyone who has ever installed your project knows that address, whether or not they ever created a character.

Second, the player base is tied to fixed hours. Castle sieges, epic raid bosses and events are on a schedule, so an outage at exactly that hour is as visible as it gets. Third, projects compete directly with each other: whoever opens a server is courting the same few thousand players as three other projects on the same weekend. Taking out a competitor is a common strategy in this scene. An attack is simply booked as a service (the scene calls them booters or stressers) and costs whoever orders it neither skill nor any serious amount of money. For the details of what a DDoS attack actually is, read What is a DDoS attack?.

Why the login server on port 2106 is the real target

Lineage 2 is split into two separate processes: a login server and one or more game servers. The client first connects to the login server on 2106 TCP, authenticates, receives the server list containing the external address and port of the game server, and then opens a second connection to the game server on 7777 TCP. Both processes have their own configuration files, their own ports and their own load limits.

That produces the attack pattern L2 operators describe over and over: a flood against 2106 blocks new logins only. Anyone already standing in the world keeps playing until they lose the connection themselves. So the online counter falls slowly instead of collapsing, and the forum fills up with "the server is up, I just cannot get in". That picture is exactly what distinguishes an attack on the login server from an attack on the game server, where everybody drops at the same moment.

The login server is also the cheaper target, because the effort is distributed unevenly. At startup, the L2J login server generates a pool of ten RSA key pairs of 1024 bits and twenty Blowfish keys. Every login attempt costs the client one packet and costs the server one decryption with the private RSA key. A half-finished session holds a slot until the built-in timer discards it: LOGIN_TIMEOUT is set to 60 seconds in the source. The default MaxConnectionPerIP = 50 allows every source address fifty simultaneous connections. A thousand source addresses are therefore enough for 50,000 concurrent sessions, each of which persists for up to a minute.

On top of that comes a trait that sets the game apart from most game servers: Lineage 2 runs over TCP only. The publisher lists TCP ports 80, 2009, 2106 and 7777 for the game, and for UDP only port 53 for name resolution. So there is no UDP game traffic to filter, but the classic SYN flood with spoofed source addresses works directly, and the connection tracking of the kernel becomes the first bottleneck.

Why attacks on Lineage 2 servers cluster around server launches

Attacks on private Lineage 2 servers cluster around server launches because the date and the hour of the opening are public weeks in advance. Opening calendars for Lineage 2 projects list upcoming launches by chronicle (Interlude, High Five, Classic, Essence) together with the rates and the exact launch time, and they are updated daily. The attacker does not have to scout anything: the moment that suits him best is printed in the operator's own announcement.

The second reason is economic. A private Lineage 2 server earns its money up front: the entire player base is recruited in the first few days, the donations arrive in the first few weeks, and after that the population shrinks steadily. A player who cannot get in during the first hour moves to the project opening the same weekend, and that project always exists. One hour of downtime on opening day therefore does not cost one hour of revenue, it costs a share of the server's entire lifetime.

The third reason is technical. At the grand opening, thousands of players try to log in at the same time. The login server is already at its limit in that exact minute, and an additional flood is hard to tell apart from the legitimate peak. An attack that would pass unnoticed on a quiet Tuesday is enough during the opening hour. The same applies to scheduled events in regular operation: castle sieges and epic raid bosses are on the calendar and are popular attack windows for the same reason. After the opening rush the incentive drops again, which is why operators experience these attacks as seasonal waves rather than a constant state.

The ports that actually matter

The table below lists the ports of a private Lineage 2 server, the matching configuration file and the directive that sets the value. The defaults come from the configuration files shipped with L2J and from the setup guides for L2OFF packs.

The table answers two questions along the way: Lineage 2 has neither a query port nor an RCON port. There is no separate service that publishes the player count for a server browser, and no remote control port like the one Source based games have. The login server builds the server list itself and sends it over the same connection on 2106 to the authenticated client. Remote administration in L2J runs through in-game commands and through the database. That removes two attack vectors other games have, and it loads all the more onto port 2106.

The numbers you should know

What you can do yourself before spending money

This section is the longest one, and that is deliberate. A cleanly configured Lineage 2 server survives small and medium attacks under its own power, no matter who hosts it.

1. Take stock: what is listening at all?

Before you write a single rule, check what your server actually offers to the outside. Do not guess, look:

ss -lntp

The interesting column is the local address. 0.0.0.0:2106 and 0.0.0.0:7777 belong there. 0.0.0.0:9014 and 0.0.0.0:3306 are mistakes: those are the two ports through which an attacker can register in your server list or probe your database. 127.0.0.1:3306, by contrast, means "local only" and needs no firewall rule. A port scan from outside gives you the attacker's view:

nmap -Pn -p- --min-rate 1000 YOUR.SERVER.IP.ADDRESS

2. Keep port 9014 and the database off the open internet

Port 9014 is the channel the game server uses to register with the login server, and it has no business on the open internet under any circumstances. L2J already ships the correct default for this: LoginHostname = 127.0.0.1 binds the port to the loopback interface, so it is not reachable from outside at all. If the login server and the game server run on two different machines, enter the specific internal address instead of * and open the port for that one peer only.

The same rule applies to the database. Check in /etc/mysql/mariadb.conf.d/50-server.cnf that it says:

bind-address = 127.0.0.1

And replace the database user. The shipped Server.properties is set to Login = root, and the file itself comments that this is not recommended. How to create a dedicated user with minimal privileges is covered in Securing MariaDB and MySQL. Then verify the result:

ss -lntp | grep -E ':9014|:3306'

The firewall on top stays short. Two rules facing the outside are enough for a Lineage 2 server, and in exactly this order so that you do not lock yourself out:

ufw allow 22/tcp comment 'SSH'
ufw allow 2106/tcp comment 'L2 Login'
ufw allow 7777/tcp comment 'L2 Game'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

The full guide including the escape route is in Setting up the UFW firewall without locking yourself out.

3. Turn off AcceptNewGameServer once your server is registered

Out of the box, LoginServer.properties contains AcceptNewGameServer = True, and the comment above it describes exactly what that means: any game server may register on a free slot of your login server. As long as 9014 sits on the loopback interface only, this has no consequences. The moment that port becomes reachable for any other reason, it is an open door. So set the value to False as soon as your own game server has registered once and holds its ID:

AcceptNewGameServer = False

The counterpart on the game server side is AcceptAlternateID = True. That is convenient while you are building the server, because the login server then hands out a different ID when the requested one is taken. On a production system you want the opposite: a fixed ID, and an error if it is taken.

4. Configure the login server's flood protection properly

L2J ships its own connection limiter inside the login server. It lives in LoginServer.properties, and all time values are in milliseconds:

EnableFloodProtection = True
FastConnectionLimit = 15
NormalConnectionTime = 700
FastConnectionTime = 350
MaxConnectionPerIP = 50

The values work together. A connection arriving less than FastConnectionTime after the previous one from the same source address counts as fast. After FastConnectionLimit such connections, the address is rejected. NormalConnectionTime is the interval after which the counter decays again. MaxConnectionPerIP is the ceiling of simultaneous open connections per address.

Fifty simultaneous connections is very generous for a single player, and lower values help noticeably. Still, be careful here: several players in one household, an internet cafe and above all connections behind carrier grade NAT (in the L2 scene this affects many players from Turkey, Brazil and parts of Eastern Europe) share one public address. Setting this to 3 locks out real players. Measure a week of normal operation first, then lower it in steps.

And one limitation you have to be aware of: this limiter runs inside the Java process of the login server. Every packet it decides about has already travelled down your uplink and has already cost processing time. It works against a handful of sources, it does not work against a botnet.

5. Limit failed attempts and use banned_ip.cfg

Two more directives in LoginServer.properties control how long somebody may keep guessing:

LoginTryBeforeBan = 5
LoginBlockAfterBan = 900

LoginTryBeforeBan is the number of invalid account and password combinations after which the address is banned, and LoginBlockAfterBan is the ban duration in seconds (900 equals 15 minutes). After that the counting starts over.

Permanent bans go into the file banned_ip.cfg in the login server's config directory. Single addresses, whole subnets and an optional expiry as a Unix timestamp in milliseconds are allowed, and everything after # is a comment:

198.51.100.7
203.0.113.0
198.51.100.44 1789689600000

Also set AutoCreateAccounts = False. The default True creates an account automatically whenever somebody logs in with an unknown account name. That is handy while you build the server and a gift once it is live: an attacker can create arbitrarily many accounts with it, and every one of them is allowed to pull the server list containing the address of your game server. Let accounts be created through the registration on your website instead, so that you control who gets credentials.

6. Limit connection rates on 2106 and 7777 in the kernel

What the Java limiter decides too late, the kernel decides earlier and more cheaply. Against small attacks and sloppy bots, an upper limit per source address helps:

iptables -I INPUT -p tcp --dport 2106 --syn -m connlimit --connlimit-above 8 --connlimit-mask 32 -j DROP
iptables -I INPUT -p tcp --dport 2106 --syn -m hashlimit --hashlimit-name l2login --hashlimit-mode srcip --hashlimit-above 6/sec --hashlimit-burst 20 -j DROP
iptables -I INPUT -p tcp --dport 7777 --syn -m connlimit --connlimit-above 6 --connlimit-mask 32 -j DROP

The first rule drops new connections to the login server as soon as one address holds more than eight of them open at the same time. A regular client needs exactly one. The second caps the new connection rate at six per second per address with a burst of twenty, which still lets a reconnect storm after a server restart through. The third allows six simultaneous connections per address on the game server, because multiboxing (dual boxing and triple boxing) is normal in Lineage 2 and a limit that is too tight hits your paying players.

All three numbers are starting points, not truths. A server with 2,000 concurrent players behaves differently from one with 200. Measure first, then configure. Plain iptables rules are gone after a reboot, and on Debian and Ubuntu you save them like this:

apt-get install -y iptables-persistent
netfilter-persistent save

Under UFW, such rules belong in /etc/ufw/before.rules, because otherwise they disappear with the next ufw reload.

7. Absorbing a SYN flood: syncookies, backlog and connection tracking

Because Lineage 2 runs over TCP only, the SYN flood is the obvious vector. A SYN flood is an attack that sends connection requests with spoofed source addresses and never answers the acknowledgement, so the server reserves memory for every request that is never used. Four settings defuse this:

sysctl -w net.ipv4.tcp_syncookies=1
sysctl -w net.ipv4.tcp_max_syn_backlog=8192
sysctl -w net.core.somaxconn=4096
sysctl -w net.ipv4.tcp_synack_retries=2

SYN cookies are the most important line: the kernel answers the request without remembering anything and only creates state once the peer actually completes the connection. Spoofed senders run into nothing. To make the values permanent, put them into a file under /etc/sysctl.d/ and load them with sysctl --system.

Another bottleneck that is often overlooked is the connection tracking of the kernel. Once it fills up, the server drops legitimate packets as well, and the log says "nf_conntrack: table full, dropping packet". The current value and the limit are shown by:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

8. Put website, login server and game server on separate IP addresses

The project website with its registration, donation shop and vote pages is always findable through your domain. If it sits on the same IP address as the login server, an attack on the website takes down logins at the same time, and the other way round. Split the three roles across different addresses. Then an attack on the website leaves the game reachable, and an attack on 2106 leaves the already connected players playing.

Keep the DNS records clean while you are at it. The most common mistake is a forgotten A record pointing at a previous address: it makes any address change pointless, because the attacker finds the new address through the same name your players do.

And this is where honesty beats wishful thinking: the address of your login server cannot be kept secret. It is in the l2.ini inside the System folder every player downloads. The address of the game server, in turn, is distributed by the login server itself: in L2J it is the external address in ipconfig.xml (in older forks it is ExternalHostname in Server.properties), and it is handed to every client that has authenticated successfully. Hiding is not a strategy, filtering is.

9. Logging, so that you have data when it counts

The most important step is the one almost nobody takes beforehand: build a baseline while everything is still normal. Without a normal value you cannot say after an incident whether 40,000 packets per second was a lot or simply a Saturday night. With apt-get install -y vnstat sysstat the measurement runs permanently in the background. During an incident four commands are enough:

sar -n DEV 1 10
ss -tn state syn-recv | wc -l
ip -s link show eth0
tcpdump -ni eth0 'tcp port 2106' -c 200 -q

For Lineage 2 the second line is the most telling one: it counts the half-open connections. A five digit value with a few hundred players online is a SYN flood and nothing else. One rule for tcpdump: always cap it with -c, because a capture under full load puts extra strain on a server that is already overloaded. How to read the numbers is covered in Detecting a DDoS attack.

Where these measures stop

Now the part that no configuration file can solve. Everything so far runs on your server, which means at the far end of the uplink. A firewall rule decides about a packet that has already travelled down the wire. You can drop it, but you cannot un-send it.

Do the math once. A typical game server sits on 1 Gbps, which is 125 megabytes per second, and the uplink is full as soon as somebody sends more. Against a Lineage 2 server it does not even take a large attack, because the second figure hits earlier: the packet rate. With small packets of 64 bytes, around 1.49 million packets per second fit into an uplink of 1 Gbps. Depending on CPU and network card, a normal server kernel handles a few hundred thousand of them before it starts dropping.

With a pure TCP game there is a third limit on top. Every half-open connection occupies an entry in the connection tracking table and in the backlog, and the L2J login server holds its sessions for up to 60 seconds. So an attack of a few hundred thousand packets per second, which does not even fill a third of your uplink, can block logins completely. Operators experience this as "the utilization was not even high, and still nobody could get in".

For a sense of the magnitudes that really occur: on KernelHost servers we have filtered, among others, an attack of over 112.2 Gbps at over 8.7 million packets per second against a game server, and a multi-vector attack of over 473.4 Gbps at over 41.5 million packets per second against a voice server. There is no local setting for that. Volumetric attacks have to end in the network in front of the server. What to do in an acute case is covered in Severe DDoS attack: what to do.

What KernelHost puts up against it

The always-on protection included with every server

DDoS protection at KernelHost is built in two layers and permanently active, with nothing for you to switch on, order or configure:

• Layer 1: 17 Tbps of mitigation capacity in the global scrubbing network. Volumetric attacks are scrubbed close to their source, before they reach the datacenter.
• Layer 2: Arbor real-time filtering with 3.2 Tbps in Frankfurt am Main. Directly in front of the server, protocol-specific patterns are detected and dropped, packet by packet.

Two properties make the difference. The protection runs permanently and does not have to react to an attack first, so there are no opening minutes in which the server is gone. During a grand opening in particular, that is the difference between a successful and a lost launch. And no null-routing is used: your IP address stays on the network, only the malicious packets are dropped. Whoever takes the IP address off the network achieves the same result for you as the attacker does. Which games and protocols are covered is listed in Game server DDoS protection with real-time filtering.

Advanced DDoS Protection for projects under constant fire

Some projects are attacked not occasionally, but deliberately and for weeks on end, and in the Lineage 2 scene that is the normal condition for any server that climbs into the upper ranks of the server lists. For those there is Advanced DDoS Protection from EUR 50.00 per month, PrePaid and with no minimum term. The difference is not more capacity, it is control:

• A dedicated protected IP from the Frankfurt core, which your server is switched over to inside our own network. Nothing has to be rebuilt on your side.
• Self-managed protection rules per port and protocol in the customer panel: you define separately what is allowed on 2106 TCP and what is allowed on 7777 TCP. For Lineage 2 that is the decisive point, because the two ports carry completely different traffic patterns: many short connections on one side, few very long ones on the other.
• Changes take effect in real time, so you can fine-tune while an attack is running, and you can tighten the rules before the opening hour and relax them afterwards.
• A protection profile that matches the application, including modified and custom server files on any TCP or UDP port. Whether you run L2J, L2J Mobius, aCis or an L2OFF pack makes no difference to the rule set, because it works on port and protocol.

The two tiers compared

For most Lineage 2 projects the included always-on protection together with a clean server configuration is enough. Advanced DDoS Protection is the answer to somebody taking it personally, and experience says that happens in the week before the grand opening.

Common mistakes and how to fix them

"Login does not work, but the game server is running normally": that is not a coincidence, it is the usual shape of an attack on a Lineage 2 server. The login server and the game server are two processes on two ports. Measure ss -tn state syn-recv | wc -l and sar -n DEV 1 10. If the half-open connections climb while the bandwidth stays unremarkable, it is a connection flood against 2106.

"I changed the IP address and was offline again the next day": the attacker gets the new address the same way your players do, namely through the new System folder with the updated l2.ini, through your announcement or through a forgotten DNS record. Changing the address buys time, it is not a solution.

"I set MaxConnectionPerIP to 3 and now players are complaining": dual boxing is common in Lineage 2, and players behind carrier grade NAT share one public address with hundreds of others. Go back to a value that covers your measurements from normal operation, and cap the new connection rate in the kernel instead.

"My iptables rules have no effect": three causes are common. The rules sit behind the UFW chains and are never reached, they were gone after the last reboot (then netfilter-persistent save or an entry in /etc/ufw/before.rules helps), or the attack is volumetric and the rule works correctly on an uplink that is already full. Use iptables -L INPUT -n -v to check whether the hit counters are rising. If they stay at zero, the rule is never reached.

"All players have lag spikes, but the uplink is quiet": then it is not a DDoS attack. On a Java server the usual suspects are garbage collection pauses, a database without suitable indexes, and a script or a custom event stuck in a loop. Check sar -n DEV 1 10 first: if the packet rates stay normal, the cause is inside the server, not in the network.

"My previous provider blocked my IP address": that is null-routing. The provider protects its own network with it, and for you the result is identical to a successful attack, usually for hours afterwards. If in doubt, ask whether traffic is filtered or null-routed. The answer says more about your availability than any hardware spec.

"I do not see anything unusual in tcpdump": if the traffic is already filtered in the network upstream, nothing arrives on the server, exactly as expected. That is the normal case when the filtering works. The other way round applies as well: once the uplink is saturated, even the SSH session you wanted to measure with may no longer reach you. Use the VNC console in the customer panel then, which works independently of the network of the guest system.

"My grand opening is in two weeks": then migrate now and not during launch week. A migration costs a new System folder for the players, a DNS change and a test run. You want all of that behind you before you announce the date, because from the announcement on, every competitor knows your worst possible moment.

In short

• A private Lineage 2 server needs exactly two ports on the open internet: 2106 TCP for the login server and 7777 TCP for the game server. Port 9014, the database (3306 on L2J, 1433 on L2OFF) and the internal L2OFF ports 2002, 2006, 2008, 2104 and 2108 are not among them.
• Lineage 2 runs over TCP only and has neither a query port nor an RCON port. The typical attack is therefore a SYN or connection flood against port 2106, not a UDP flood.
• An attack on the login server blocks new logins only. If nobody can get in while the players in the world keep playing, look for the cause on port 2106 and not on 7777.
• Set EnableFloodProtection, MaxConnectionPerIP, LoginTryBeforeBan and AutoCreateAccounts deliberately, switch AcceptNewGameServer to False after registration, and cap connection rates in the kernel as well, because the Java limiter only acts after the uplink.
• Attacks on Lineage 2 servers cluster around server launches, because the date and the hour are public weeks in advance and the financial damage is greatest on opening day. The protection has to be in place before the announcement, not after it.
• Above the uplink capacity and above a few hundred thousand packets per second, only the filtering in the network in front of the server decides the outcome. At KernelHost it is two-layered, permanently active, at no surcharge and without null-routing.

If your project already runs at KernelHost, the filtering is active without you having to do anything. If you still notice something unusual, open a support ticket so that we can fine-tune the filter rules for your IP address. During an ongoing attack you can also reach us through the WhatsApp emergency chat at +43 650 8209883.