How to secure Your server? - Read here!

[Focher]

so i have no idea what's wrong, can You get me list of all files these players have
\PMC
\BAF

same goes i need list of the server files (ideally MD5 hashes included)

also what's your server IP ?

Hi, I kind of feel like I hijacked this thread so I'll put that information in the other thread I created at Wrong Signature - v1 / v2.

[$able]

ATTENTION! Warning to All Admins!
Emergency Responder to Event OMFGBBQFAIL#65535: http://dev-heaven.net/issues/20994

[...]

More countermeasures for beserver.cfg soon(tm)!

beserver.cfg is now automatically renamed to beserver_active_[randomtext].cfg while the server is running to prevent this exploit.

[nomad_man]

Sable,

we have an issue with our linux box.

The server reports only 500MB ram usage. Which is normal for us.

However, it is actually eating up all 4Gigs of RAM.

Furthermore, BE fails to start with -bepath full or relative.
And the beserver.so gets automatically deleted.


And question #2

if we run multiple servers off the same config, will that "autorename" interfere with each other?

FYI: the file get's renamed to beserver_ac<random>.cfg and not the format you posted.

[eddieck]

Yeah, we're having the same issue. RCon stops working randomly (when the file gets renamed) and beserver.so gets removed.

[nomad_man]

do you get increased ram usage too?

[eddieck]

Nope, our RAM usage looks fine.

[$able]

Sable,

we have an issue with our linux box.

The server reports only 500MB ram usage. Which is normal for us.

However, it is actually eating up all 4Gigs of RAM.

Furthermore, BE fails to start with -bepath full or relative.
And the beserver.so gets automatically deleted.


And question #2

if we run multiple servers off the same config, will that "autorename" interfere with each other?

FYI: the file get's renamed to beserver_ac<random>.cfg and not the format you posted.

Did the RAM usage only increase after the last BE update?

Also, -BEpath might not be implemented properly on Linux, so you might not be able to use it (I will try to check this with BIS).

Regarding the rename bug, I will research and fix this shortly. And no, running multiple servers with the same BE folder shouldn't cause problems here, however it is never recommended to do this due to BE's auto-update.

---------- Post added at 17:58 ---------- Previous post was at 16:28 ----------

Regarding the rename bug, I will research and fix this shortly.

Fixed now.

[nomad_man]

After much poking around with strace

1. RAM usage increased to ridiculous levels, after battleye update or around the same time. No change to the box. I will be running memtest on the box to validate that ram isnt' faulty. We did have a fault stick couple of month ago. There were no hardware or software updates on the box, it wasn't rebooted for a month either. 1 instance tends to max out the ram (4gigs) and proceeds to swap causing horrific lag.

Any ideas how i can trouble shoot this? Nothing was changed on the box.

~$ free
             total       used       free     shared    buffers     cached
Mem:       4109520    3988364     121156          0       2824      49716
-/+ buffers/cache:    3935824     173696
Swap:      3903752     456476    3447276

2. -bepath isn't working on linux

3. bans are not being enforced, and can't connect to rcon remotely.
Edit: it appears while my message was passing moderation, this got fixed.

4. battle eye appears to be running, atleast acorrding to strace it opens beserver.so and checks for beserver.so.new
and the process re-reads bans file every now and than
Edit: It removes beserver.so located at -bepath

5. After much poking around it appears the server is looking for bans.txt both in BattlEye folder and in the root folder of arma. Which is kinda odd.
Any thoughts on that?

6. BattleEye when started searches for beserver.cfg according to my strace efforts. It should be trying to load beserver_*.cfg instead.
I fixed this issue by modifying the server start up script to always copy beserver_*.cfg into beserver.cfg and let the battle eye take care of renaming.
Edit: Again, my message was passing moderation, it is fixed now indeed.

[$able]

After much poking around with strace

1. RAM usage increased to ridiculous levels, after battleye update or around the same time. No change to the box. I will be running memtest on the box to validate that ram isnt' faulty. We did have a fault stick couple of month ago. There were no hardware or software updates on the box, it wasn't rebooted for a month either. 1 instance tends to max out the ram (4gigs) and proceeds to swap causing horrific lag.

Any ideas how i can trouble shoot this? Nothing was changed on the box.

~$ free
             total       used       free     shared    buffers     cached
Mem:       4109520    3988364     121156          0       2824      49716
-/+ buffers/cache:    3935824     173696
Swap:      3903752     456476    3447276

2. -bepath isn't working on linux

3. bans are not being enforced, and can't connect to rcon remotely.
Edit: it appears while my message was passing moderation, this got fixed.

4. battle eye appears to be running, atleast acorrding to strace it opens beserver.so and checks for beserver.so.new
and the process re-reads bans file every now and than
Edit: It removes beserver.so located at -bepath

5. After much poking around it appears the server is looking for bans.txt both in BattlEye folder and in the root folder of arma. Which is kinda odd.
Any thoughts on that?

6. BattleEye when started searches for beserver.cfg according to my strace efforts. It should be trying to load beserver_*.cfg instead.
I fixed this issue by modifying the server start up script to always copy beserver_*.cfg into beserver.cfg and let the battle eye take care of renaming.
Edit: Again, my message was passing moderation, it is fixed now indeed.

1. Please research further. This is unlikely to be caused by BE.

2. Possible, I will forward this to BIS (only they can fix it).

3. Did you remove the -BEpath parameter? Most likely this parameter prevented BE from loading its files correctly.

4. See 2.

5. The ArmA server loads "ban.txt" from root, the BE Server loads "bans.txt" from BE folder - note the difference.

6. You shouldn't need to do this. The BE Server now renames the beserver.cfg to beserver_active_[randomtext].cfg to prevent a remote script exploit. If the server is shut down properly, it will automatically be renamed back. But even if it isn't when the server crashes, the config should be loaded without problems the next time.

[eddieck]

The update seems to have killed RCon on one of our servers (but it works on the others). The beserver.cfg is the same and it appears to be recognized since it was renamed to beserver_active_*.cfg.

The strange thing is the server log shows several successful RCon connections from me every time I attempt to log in, but the client itself doesn't show that. I'm using the official BE command line RCon tool from the wiki (0.91 I believe).