FiveM Server Security ต้องตั้งค่าอะไรบ้าง

August 26, 2026

FiveM Server Security ที่ดีไม่ได้เกิดจากการติด Anti-cheat เพียงตัวเดียว แต่ต้องทำให้ Server เป็นผู้ตัดสินข้อมูลสำคัญ ตรวจสอบ Network Events จำกัดสิทธิ์ Admin ควบคุมการสร้าง Entity ป้องกันการแก้ State และลดบริการที่เปิดออก Internet ให้น้อยที่สุด

จุดที่ Server Owner ควรตรวจเป็นอันดับแรก ได้แก่

Network Event Validation
Server-side Authority
ACE Permissions
Admin Permissions
sv_scriptHookAllowed
OneSync Entity Lockdown
sv_stateBagStrictMode
sv_filterRequestControl
RCON
Firewall และ Port
Resource Security
Secrets/API Keys
Database Permissions
Logging และ Monitoring
Backup และ Recovery

Cfx.re เตือนโดยตรงว่า Cheat Client สามารถพยายาม Trigger Network Events ได้ ดังนั้น Resource ที่รับข้อมูลจาก Client ต้องถือหลักว่า

Never trust the client

แม้ Server จะมี Anti-cheat อยู่แล้วก็ตาม

บทความนี้จาก comsiam จะอธิบาย FiveM Server Security ตั้งแต่ server.cfg ไปจนถึงการเขียน Resource ให้ปลอดภัยขึ้น

① หลักสำคัญที่สุดของ FiveM Security คืออะไร?

หลักที่สำคัญที่สุดคือ

Client = Untrusted

Server = Authority

Client ควรใช้สำหรับ

Input
UI
Animation
Visual
Request

ส่วนข้อมูลสำคัญควรให้ Server ตรวจสอบและตัดสิน

② ทำไมไม่ควรเชื่อ Client?

เพราะ Client อยู่บนเครื่องผู้เล่น

ผู้เล่นสามารถแก้ไขหรือ Manipulate สิ่งที่เกิดขึ้นฝั่ง Client ได้มากกว่าฝั่ง Server

ดังนั้นข้อมูลอย่าง

Money
Item
Job
Permission
Reward
Vehicle Ownership

ไม่ควรถูกยอมรับจาก Client โดยตรง

③ ตัวอย่าง Event ที่ไม่ปลอดภัย

ไม่ควรทำ:

RegisterNetEvent('shop:giveMoney', function(amount)
    local player = GetPlayer(source)

    player.addMoney(amount)
end)

ปัญหาคือ Server รับ amount จาก Client แล้วนำไปใช้ทันที

Server ไม่ได้รู้เลยว่าจำนวนเงินนั้นถูกต้องหรือไม่

④ แนวทางที่ปลอดภัยกว่า

ให้ Client ส่งเพียง Request เช่น

ฉันต้องการขาย Item X

จากนั้น Server ตรวจ

Player มี Item จริงไหม?
↓
อยู่จุดขายไหม?
↓
จำนวนถูกต้องไหม?
↓
มีสิทธิ์ทำหรือไม่?
↓
Server คำนวณ Reward
↓
จ่ายเงิน

Client ไม่ควรเป็นผู้กำหนด Reward เอง

⑤ Server ควรคำนวณเงินเอง

เช่นแทนที่จะรับ

reward = 50000

จาก Client

Server ควรมี Configuration ของตัวเอง

local ITEM_PRICE = 250

local reward = itemCount * ITEM_PRICE

Server จึงควบคุม Economy

⑥ Item ก็ใช้หลักเดียวกัน

อย่าให้ Client ระบุได้อิสระว่า

item = weapon_x
count = 999

แล้ว Server แจกทันที

Server ต้องตรวจ

Item ที่อนุญาต
จำนวนสูงสุด
Player State
Job/Activity

ก่อนเสมอ

⑦ Cfx.re แนะนำให้ตรวจอะไรใน Network Event?

เอกสาร Security ของ Cfx.re แนะนำให้ตรวจข้อมูลอย่าง

Player Money
State Bags
Inventory
Player Position
Experience/Level
Permissions
Roles

และให้ดึงข้อมูลเหล่านี้ด้วยวิธีฝั่ง Server เมื่อทำได้

⑧ Position Validation สำคัญมาก

สมมติเป็นระบบขายไม้

ผู้เล่นควรอยู่ที่จุดขาย

Server สามารถตรวจ Position ของ Player ก่อนให้ Reward

แนวคิด:

local ped = GetPlayerPed(source)
local coords = GetEntityCoords(ped)

if #(coords - SELL_POINT) > 15.0 then
    return
end

ช่วยป้องกันการเรียก Event จากตำแหน่งที่ไม่ถูกต้อง

⑨ Permission Validation ต้องอยู่ Server

เช่นคำสั่ง Admin

อย่าตรวจเพียงฝั่ง Client ว่า

isAdmin = true

แล้วแสดง Menu

เพราะ Menu ถูกซ่อนได้ แต่ Server Event ยังต้องตรวจ Permission อีกครั้ง

⑩ UI Permission ไม่ใช่ Security

การซ่อนปุ่มจากผู้เล่นธรรมดาเป็น UX

ไม่ใช่ Security

Server ต้อง Validate ทุก Action สำคัญอีกชั้น

Admin UI
↓
Request
↓
Server Permission Check
↓
Execute

⑪ AddEventHandler กับ RegisterNetEvent ต่างกันอย่างไร?

Cfx.re แนะนำให้แยกตาม Context

AddEventHandler

ใช้กับ Event ที่ควรถูกเรียกภายใน Context เดียวกัน เช่น

Server → Server

RegisterNetEvent

ใช้เมื่อ Event ต้องข้าม Network เช่น

Client → Server
Server → Client

อย่าทำ Server-only Event ให้กลายเป็น Network Event โดยไม่จำเป็น

⑫ ทำไม Event ที่ไม่จำเป็นต้อง Network ไม่ควร RegisterNetEvent?

เพราะการเปิด Event ให้เป็น Network Event เพิ่ม Surface ที่ Client สามารถเรียกถึงได้

ถ้า Function ใช้เฉพาะ Resource ฝั่ง Server

ให้ใช้ Local Event หรือ Function โดยตรง

⑬ RegisterNetEvent ไม่ได้ทำ Event ปลอดภัยเอง

RegisterNetEvent หมายถึง Event สามารถใช้งานผ่าน Network ได้

ไม่ได้หมายความว่า

ผู้เรียกได้รับอนุญาต

Developer ยังต้องทำ Validation เอง

⑭ source สำคัญอย่างไร?

Server-side Event สามารถใช้ source เพื่อระบุ Player ที่ Trigger Event

อย่ารับ Player ID จาก Client แล้วเชื่อโดยตรงหากสามารถใช้ source ได้

ตัวอย่าง:

RegisterNetEvent('shop:buy', function(item)
    local src = source

    -- ตรวจ player จาก src
end)

ลดการปลอม Target Player ผ่าน Parameter ที่ไม่จำเป็น

⑮ ระวัง source ใน Async Code

Cfx.re ระบุว่าใน Lua/JavaScript ค่า source แบบ Global รับประกันเฉพาะช่วง Event Call เริ่มต้น

ถ้าจะใช้หลัง Wait หรือ await

ควรเก็บไว้ก่อน

local src = source

จากนั้นใช้ src

ช่วยป้องกันทั้ง Bug และ Authorization Mistake

⑯ Validate Type ของ Input

ก่อนใช้ Parameter จาก Client ตรวจ Type

เช่น

if type(amount) ~= 'number' then
    return
end

และตรวจ Range ต่อ

if amount < 1 or amount > 10 then
    return
end

ช่วยลด Unexpected Input

⑰ อย่าพึ่ง Client Cooldown อย่างเดียว

Client สามารถแสดง Countdown

แต่ Server ควรมี Rate/State Validation ของตัวเอง

เช่น

Client Cooldown → UX
Server Cooldown → Security

เพราะ Client-side Timer สามารถถูก Manipulate ได้

⑱ Server ต้องเก็บ Workflow State เอง

ตัวอย่าง Job:

Start Job
↓
Server บันทึก Active Job
↓
Player ทำงาน
↓
Server ตรวจ Position/State
↓
Turn In
↓
Serverจ่าย Reward

ดีกว่าให้ Client รายงานเพียงว่า

“ทำงานเสร็จแล้ว จ่ายเงินให้ฉัน”

⑲ Anti-cheat แทน Event Security ได้ไหม?

ไม่ได้

Cfx.re ระบุชัดว่าแม้จะมี Anti-cheat ที่แข็งแรง การเพิ่ม Server-side Checks ใน Events ก็ยังเป็น Best Practice

Anti-cheat และ Secure Resource Design ต้องทำร่วมกัน

⑳ sv_scriptHookAllowed ควรตั้งอย่างไร?

Example server.cfg อย่างเป็นทางการของ Cfx.re ใช้

sv_scriptHookAllowed 0

เพื่อไม่อนุญาต Scripthook-based Plugins

สำหรับ Server ทั่วไปที่ไม่ได้ต้องการ Feature ดังกล่าว ควรตรวจให้แน่ใจว่าไม่ได้เปิดไว้โดยไม่จำเป็น

㉑ sv_scriptHookAllowed 0 ทำให้ไม่มี Cheat 100% ไหม?

ไม่

เอกสาร Cfx.re ระบุเองว่าการปิด Scripthook ไม่ได้รับประกันว่าจะป้องกัน External Plugins หรือ Cheat ทุกชนิด

จึงยังต้องมี Security Layer อื่น

㉒ หลัก Defense in Depth คืออะไร?

อย่าพึ่งมาตรการเดียว

ใช้หลายชั้น:

Cfx Platform Security
↓
Network Security
↓
Event Validation
↓
Permissions
↓
Entity Security
↓
Anti-cheat
↓
Logging
↓
Backup

ถ้าชั้นหนึ่งพลาดยังมีชั้นอื่นช่วยลดความเสียหาย

㉓ ACE Permissions คืออะไร?

ACE คือ Permission System ภายใน Cfx/FiveM

ใช้กำหนดว่า Principal ใดสามารถทำ Action ใดได้

ตัวอย่างจาก server.cfg มาตรฐาน:

add_ace group.admin command allow
add_ace group.admin command.quit deny

หมายถึง Admin Group ใช้ Command ได้ แต่ห้าม quit

㉔ add_principal ใช้ทำอะไร?

ใช้เพิ่ม Principal เข้า Group หรือ Principal อื่น

ตัวอย่างแนวคิด:

add_principal identifier.fivem:12345 group.admin

ควรใช้ Identifier ที่ถูกต้องของ Admin จริง

㉕ อย่าแจก group.admin กว้างเกินไป

Admin ไม่จำเป็นต้องทุกคนมี Permission ทุกอย่าง

แบ่ง Roles เช่น

Owner
Developer
Senior Admin
Admin
Moderator
Support

แล้วให้สิทธิ์ตามหน้าที่

เรียกว่า Principle of Least Privilege

㉖ Least Privilege คืออะไร?

ให้ User/Resource มีสิทธิ์ เท่าที่ต้องใช้

ไม่ใช่

ทุกคน
→ ทุก Command
→ ทุก Action

ยิ่ง Account ถูกขโมย ความเสียหายก็จะถูกจำกัดตาม Permission

㉗ Resource ก็มี ACE Permission ได้

Resource สามารถได้รับสิทธิ์ Command บางตัวผ่าน ACL

อย่าอนุญาต Resource ที่ไม่จำเป็นให้ Execute Administrative Commands

ตรวจ server.cfg ว่ามี

add_ace resource....

อะไรบ้าง

㉘ RCON ควรเปิดไหม?

ถ้าไม่ได้ใช้ ไม่จำเป็นต้องเปิด

Example Config ของ Cfx.re ปล่อย RCON Password ไว้ Commented

ถ้าจะใช้ RCON ต้อง

ใช้ Password แข็งแรง
จำกัด Network Access
ไม่ Share Credential
เปลี่ยน Credential เมื่อมีความเสี่ยง

㉙ ห้ามใช้ Password ตัวอย่าง

อย่าใช้

admin123
password
fivem123
123456

กับระบบ Admin/RCON/Database

ควรใช้ Password ยาวและ Unique

㉚ Firewall สำคัญแค่ไหน?

สำคัญมาก

เปิดเฉพาะ Port ที่ Server ต้องใช้จริง

แนวคิด:

Internet
↓
Firewall
↓
เฉพาะ Required Ports
↓
FXServer

อย่าเปิด Database, Remote Desktop หรือ Admin Service ออก Internet ทั้งหมดโดยไม่มีเหตุผล

㉛ Port FiveM มาตรฐานคืออะไร?

Vanilla Config ของ Cfx.re ใช้ตัวอย่าง

endpoint_add_tcp "0.0.0.0:30120"
endpoint_add_udp "0.0.0.0:30120"

แต่ Security Policy ของ Firewall ต้องอิง Environment จริงของคุณ

㉜ Database ควรเปิด Public Internet ไหม?

โดยทั่วไป ไม่ควร หากไม่จำเป็น

ถ้า Game Server กับ Database อยู่ Infrastructure เดียวกัน

ควรจำกัด Connection Source ให้แคบที่สุด

ใช้ Firewall หรือ Private Network เมื่อทำได้

㉝ Database User ไม่ควรใช้ Root ถ้าไม่จำเป็น

สร้าง Database Account สำหรับ FiveM โดยเฉพาะ

ให้ Permission เท่าที่ Application ต้องใช้

แยกจาก Database Administrator Account

ช่วยลด Blast Radius หาก Credential หลุด

㉞ API Key และ Password ห้ามอยู่ Client Script

Client Resource ถูกส่งไปยังเครื่อง Player

ดังนั้นห้ามฝัง

Database Password
Discord Bot Token
Private API Key
Admin Secret

ใน Client Script/NUI

Secret ต้องอยู่ Server-side

㉟ server.cfg ต้องรักษาความลับหรือไม่?

ไฟล์นี้อาจมีค่า Sensitive เช่น

License Key
RCON Credential
Resource Secrets

อย่านำ Config Production ไปโพสต์สาธารณะทั้งไฟล์โดยไม่ตรวจ

㊱ Git Repository ต้องระวัง Secrets

ก่อน Push Source ให้ตรวจ

server.cfg
.env
config secrets
database credentials
API tokens

ไม่ควร Commit Secret Production ลง Public Repository

ถ้า Secret หลุดให้ Rotate

ไม่ใช่แค่ลบ Commit ล่าสุด

㊲ Rotate Secret คืออะไร?

คือยกเลิก Credential เดิมและสร้างใหม่

เพราะเมื่อ Secret ถูกเผยแพร่แล้วต้องถือว่าอาจมีคน Copy ไปแล้ว

การลบจากหน้า Git อย่างเดียวไม่เพียงพอ

㊳ OneSync Entity Lockdown ช่วย Security ได้อย่างไร?

OneSync รองรับ Entity Lockdown เพื่อควบคุม Client-created Entities

Cfx.re ระบุ Modes เช่น

strict
relaxed
inactive

และ Enhanced มี full Mode ที่มีความหมายเฉพาะเรื่อง Dummy Objects

㊴ strict Entity Lockdown คืออะไร?

strict หมายถึง

Client ไม่สามารถสร้าง Entity ใน Routing Bucket นั้น

ตัวอย่าง:

SetRoutingBucketEntityLockdownMode(1, 'strict')

เหมาะกับระบบที่ Server ต้องการควบคุม Entity Creation เต็มรูปแบบ

㊵ ทำไม Entity Lockdown ช่วย Security?

ช่วยลดโอกาส Client สร้าง

Vehicles
Peds
Objects

โดยไม่ได้รับอนุญาตใน Bucket ที่กำหนด

แต่ Resource ต้องออกแบบให้ Server สร้าง Entity ที่จำเป็นแทน

㊶ เปิด strict ทุกอย่างทันทีได้ไหม?

ไม่ควร

Resource บางตัวอาจสร้าง Entity ฝั่ง Clientเป็นส่วนหนึ่งของ Gameplay

ถ้าเปิด Strict โดยไม่ Audit Resource อาจพัง

ควร

Staging
↓
Audit Entity Creation
↓
Strict Test
↓
Multiplayer Test
↓
Production

㊷ relaxed ต่างจาก strict อย่างไร?

ตามเอกสาร OneSync

strict

ไม่ให้ Client สร้าง Entity

relaxed

Block Script-owned Entities ที่ Client สร้าง แต่ผ่อนคลายกว่า Strict

เลือกตาม Architecture

㊸ full ไม่ใช่ Security สูงกว่า strict

ต้องระวังคำนี้มาก

Enhanced full Mode หมายถึง

Disable Dummy Object Creation

ไม่ได้หมายถึง “Security สูงสุด”

ถ้าต้องการ Client Entity Lockdown ต้องดู strict

㊹ sv_stateBagStrictMode คืออะไร?

เอกสาร State Bags ระบุว่าเมื่อเปิด

sv_stateBagStrictMode true

จะจำกัดให้ Server เท่านั้นสามารถแก้ State Bags

ช่วยสร้าง Server-authoritative Architecture ที่เข้มงวดขึ้น

㊺ ควรเปิด sv_stateBagStrictMode เลยไหม?

ต้อง Audit ก่อน

Resource บางตัวพึ่ง Client-side State Write เช่น

LocalPlayer.state:set(...)

ถ้าเปิด Strict Mode Resource อาจหยุดทำงาน

ให้ทดสอบบน Staging ก่อน

㊻ State Bags สำคัญกับ Security อย่างไร?

Default Policy อนุญาตบาง State ให้ Player/Entity Owner เขียนได้

ดังนั้นห้ามใช้ Client-writable State เป็นหลักฐานเดียวในการ

ให้เงิน
ให้สิทธิ์
แจก Item
ยืนยัน Admin

Critical State ควรมี Server Authority

㊼ sv_filterRequestControl คืออะไร?

เป็น Server Setting สำหรับกรองการส่ง REQUEST_CONTROL_EVENT

Cfx.re มีระดับตั้งแต่

จากไม่กรอง ไปจนถึงปิด Control Requests เข้มงวดขึ้นตาม Policy

㊽ ควรตั้ง sv_filterRequestControl เท่าไร?

ไม่มีค่าหนึ่งที่ควร Copy ไปใช้ทุก Server

ค่าที่เข้มงวดขึ้นอาจกระทบ Resource ที่พึ่ง Entity Control Requests

ให้ Audit Resource และทดสอบ

Cfx.re เองเตือนว่า Security ConVars เหล่านี้ไม่ควรถูก Copy/Paste โดยไม่เข้าใจ

㊾ sv_authMinTrust คืออะไร?

เป็น ConVar ที่เกี่ยวข้องกับระดับ Trust ของ Player Identity

Cfx.re รวมไว้ใน Server-owner Security Options

แต่ไม่ควรเปลี่ยนค่าแบบสุ่ม เพราะสามารถกระทบการเชื่อมต่อผู้เล่นจริง

㊿ sv_authMaxVariance คืออะไร?

เกี่ยวข้องกับความแปรปรวนของ Identity Provider

เป็นอีก Setting ที่ Cfx.re ระบุไว้ใน Security Guide

หลักเดียวกันคือ

อย่า Tune โดยไม่เข้าใจ

Security Setting ที่เข้มเกินไปสามารถสร้าง False Positive ได้

51. sv_disableClientReplays คืออะไร?

Cfx.re ระบุว่าการเปิดตัวเลือกนี้มีเป้าหมายเพื่อลดช่องทางบางอย่างที่อาจถูกใช้เพื่อ Cheat

แต่มี Trade-off คือ

Rockstar Editor จะถูกปิด

จึงต้องพิจารณาความต้องการของ Community

52. Security ConVars เปิดมากที่สุดดีที่สุดไหม?

ไม่

Security Configuration ต้อง Balance

Security
↔
Compatibility
↔
Player Experience

เปิดค่าที่เข้มมากแบบไม่ Test อาจทำให้ Player หลุดหรือ Resource พัง

53. Cfx.re เตือนเรื่อง Security ConVars อย่างไร?

เอกสาร Security ระบุโดยตรงว่า Server-owner Options บางตัว ไม่ควรปรับถ้าไม่รู้ว่ากำลังทำอะไร

และตัวอย่างเหล่านั้นไม่ควรถูกนำไป Copy/Paste แบบอัตโนมัติ

นี่เป็นคำเตือนสำคัญ

54. Anti-cheat ควรมีไหม?

สำหรับ Public Server มีประโยชน์มาก

แต่เลือก Resource ที่

มีการดูแล
Update สม่ำเสมอ
Compatible กับ Framework
ไม่สร้าง False Positive สูงเกินไป

และต้องไม่ใช้ Anti-cheat แทน Secure Coding

55. Resource จากแหล่งไม่รู้จักอันตรายไหม?

อันตรายได้มาก

Resource Server-side สามารถทำสิ่งที่มีผลต่อระบบได้ตามสิทธิ์และ Sandbox ที่เกี่ยวข้อง

ก่อนติดตั้งควรตรวจ

Source
Developer
Repository
Dependencies
Files
Manifest

โดยเฉพาะ Resource ฟรีที่มาจากแหล่งไม่น่าเชื่อถือ

56. อย่ารันไฟล์ที่ไม่รู้จักบน Server

ถ้า Resource Package มี

Executable แปลก
Binary ที่ไม่ทราบที่มา
Installer ที่ไม่จำเป็น
Script Obfuscated ผิดปกติ

ควรหยุดและตรวจสอบก่อน

อย่าใช้ Production Server เป็น Sandbox ทดสอบไฟล์

57. Dependency ต้อง Update ไหม?

ควรใช้ Version ที่ยังได้รับการดูแล

โดยเฉพาะ

Framework
Database Library
Admin Resource
Anti-cheat
Web Backend

แต่ Update ผ่าน Staging ก่อน

58. Artifact เก่ามีความเสี่ยงหรือไม่?

ควรใช้ Cfx Server Build ที่ยังได้รับการสนับสนุน

Artifact ที่เก่ามากอาจไม่ได้รับระดับ Stability/Fix เดียวกับ Build ที่ยัง Support

วางแผน Update สม่ำเสมอ

59. อย่า Update Production แบบ Blind

ใช้

Backup
↓
Staging
↓
Update
↓
Security Test
↓
Functional Test
↓
Production

เพราะ Security Update อาจมี Compatibility Change

60. Enhanced Connection Process เปลี่ยน Security อย่างไร?

FiveM Enhanced เปลี่ยน Connection Handshake ใหม่

Cfx.re ระบุว่า Client จะ ไม่ใช้ UDP จนกว่าจะ Connect กับ Serverสำเร็จ

และ Connection Deferrals เปลี่ยนไปใช้ WebSocket

61. Enhanced Handshake มีประโยชน์อะไร?

Cfx.re ระบุว่าการเปลี่ยนนี้ทำให้ Server Protection ต่อ Denial-of-Service จัดการได้ง่ายขึ้น

แต่ Infrastructure Protection เดิมของ Server อาจต้องปรับให้ Compatible กับ Connection Flow ใหม่

62. Firewall/Proxy เก่าต้องตรวจเมื่อย้าย Enhanced ไหม?

ต้อง

โดยเฉพาะ Server ที่มี

Reverse Proxy
DDoS Protection
Custom Firewall
Connection Filtering

Cfx.re เตือนว่า Existing Protections บางแบบต้องปรับให้รองรับ Enhanced

อย่าคิดว่า Network Flow เหมือน Legacy ทุกอย่าง

63. DDoS Protection จำเป็นไหม?

Public Server ควรใช้ Hosting/Network ที่มี DDoS Mitigation ตามความเสี่ยง

โดยเฉพาะ Server Community ขนาดใหญ่

Firewall บนเครื่องเพียงอย่างเดียวไม่สามารถรับมือกับ Attack ที่กิน Bandwidth Link จนเต็มได้ทั้งหมด

64. txAdmin ต้องรักษาความปลอดภัยไหม?

ต้องมาก

txAdmin เป็น Management Surface ของ Server

Account ที่เข้าถึงได้สามารถมี Permission สำคัญ

จึงควร

จำกัดผู้ใช้
ใช้ Account ที่ปลอดภัย
ตรวจ Permission
ไม่ Share Session/Credential
ตรวจ Logs

หัวข้อ Account/Admin Security จะต้องเข้มกว่าการตั้งค่า Gameplay ทั่วไป

65. Admin Command ทุกคำสั่งต้องมี Permission

ตัวอย่าง

Give Money
Give Item
Spawn
Ban
Kick
Revive
Teleport

ต้องมี Server-side Permission Check

ห้ามเชื่อว่าเพราะ Menu เปิดได้เฉพาะ Admin จึงปลอดภัยแล้ว

66. Command ควรใช้ ACE เมื่อเหมาะสม

ACE ช่วยควบคุมว่า Group ใดเรียก Command ได้

แต่อาจใช้ร่วมกับ Framework Permission System ได้

สิ่งสำคัญคือ Server ต้องมี Authorization Layer ที่ชัดเจน

67. Logging Security Event สำคัญไหม?

ควร Log เหตุการณ์สำคัญ เช่น

Admin Action
Permission Change
Ban/Unban
Resource Restart
Sensitive Economy Action
Repeated Invalid Requests

Log ช่วย Incident Investigation

68. แต่ห้าม Log Secret

อย่าเขียน

Password
API Key
Full Token
Database Credential

ลง Log

เพราะ Logging System เองอาจถูกเข้าถึงได้

69. Log ทุก Event ดีไหม?

ไม่

Logging มากเกินไปสร้าง

Storage
CPU
Network
Noise

เลือก Security-relevant Events และใช้ Rate Limit

70. Invalid Event ควร Ban ทันทีไหม?

ไม่จำเป็นทุกกรณี

Invalid Input อาจเกิดจาก

Bug
Race Condition
Outdated Client Resource

ใช้หลัก

Reject
↓
Log
↓
Count / Correlate
↓
Action ตาม Evidence

ดีกว่า Ban จาก Signal เดียวโดยไม่มี Context

71. Rate Limit สำคัญไหม?

สำคัญกับ Event ที่สามารถถูกเรียกบ่อย

เช่น

Purchase
Job Reward
Admin Query
Expensive Database Request

Server ควรป้องกัน Request Flood ตาม Use Case

72. Rate Limit ไม่แทน Validation

แม้ Player เรียก Eventได้เพียงหนึ่งครั้งต่อวินาที

ถ้า Server ยังยอมรับ

reward = 99999999

Event ก็ยังไม่ปลอดภัย

ต้องทำทั้ง

Validation + Rate Limiting

73. Server-side Source of Truth คืออะไร?

ข้อมูลสำคัญควรมีแหล่งจริงอยู่ Server เช่น

Money → Server/Database
Inventory → Server
Permissions → Server
Job → Server
Ownership → Server

Client รับข้อมูลเพื่อแสดงผลและส่ง Request

ไม่ควรเป็น Authority

74. Backup คือส่วนหนึ่งของ Security หรือไม่?

ใช่

Security ไม่ได้มีเพียงป้องกันการบุกรุก

ต้อง Recovery ได้ด้วย

Backup อย่างน้อย

Database
Resources
Configuration
Important Keys/Settings ในระบบจัดเก็บที่ปลอดภัย

และต้องทดสอบ Restore

75. Backup ที่ Restore ไม่ได้ถือว่า Backup ไหม?

ในทางปฏิบัติยังไม่น่าเชื่อถือ

ควรทดลอง

Backup
↓
Restore บน Test Environment
↓
เปิด Server
↓
ตรวจข้อมูล

เป็นระยะ

76. Database Backup ต้องทำก่อน Update ใหญ่

ก่อน

Framework Migration
Inventory Migration
Database Schema Change

ควรมี Backup ล่าสุด

เพราะความผิดพลาดจาก Update สามารถเสียหายพอ ๆ กับ Security Incident

77. แยก Production กับ Development

Developer ไม่ควร Test Resource ไม่ทราบสถานะบน Production

ใช้

Development
↓
Staging
↓
Security / Functional Test
↓
Production

ลดโอกาส Resource ทดลองเปิดช่องโหว่ให้ Server จริง

78. Production Server ไม่ควรมี Debug Tools เกินจำเป็น

ปิด

Test Commands
Debug Events
Developer Bypass
Temporary Admin Permissions

เมื่อขึ้น Production

สิ่งที่ใช้สะดวกตอน Development อาจกลายเป็นช่องทาง Security ถ้าลืมปิด

79. ตรวจ Resource ก่อน Production ด้วย Checklist

Events

Client Input Validate
Permission Check
Position Check
Range Check
Rate Limit

Data

Server Authority
No Secrets Client-side

Entity

Creation Policy
Cleanup
Lockdown Test

Admin

ACE
Least Privilege

Network

Firewall
RCON
DDoS Protection

Operations

Logging
Backup
Staging

80. ตัวอย่าง Security Architecture

Player Client
↓ Request
Network Event
↓
Type / Range Validation
↓
Permission Validation
↓
Player State / Position Validation
↓
Server-side Business Logic
↓
Database / Framework
↓
Response

นี่คือ Pattern ที่ควรใช้กับ Resource สำคัญ

81. ตัวอย่าง Shop ที่ดี

Client ส่งเพียง

ซื้อ water จำนวน 2

Server ตรวจ

water อยู่ในรายการสินค้าหรือไม่
จำนวนอยู่ใน Limit หรือไม่
Player อยู่ร้านหรือไม่
Server ดูราคาจาก Config
Server ตรวจเงิน
หักเงิน
เพิ่ม Item

Client ไม่ได้เป็นผู้กำหนด Price

82. ตัวอย่าง Job Reward ที่ดี

Server ควรรู้เองว่า

Player Start Job เมื่อไร
อยู่สถานะไหน
ทำได้กี่ชิ้น
อยู่จุด Turn-in หรือไม่

เมื่อ Finish จึงคำนวณ Reward

ไม่รับคำว่า

ฉันทำครบ 999 รอบ

จาก Client แล้วเชื่อทันที

83. ตัวอย่าง Admin Action ที่ดี

Admin Client
↓
Request Kick Player
↓
Server ตรวจ ACE/Permission
↓
Validate Target
↓
Execute
↓
Audit Log

แม้คนทั่วไปเรียก Event ได้ Server ก็ Reject เพราะไม่มี Permission

84. FiveM Security Checklist ฉบับย่อ

ตรวจว่ามีสิ่งเหล่านี้หรือไม่:

sv_scriptHookAllowed 0 หากไม่จำเป็นต้องใช้ Scripthook
Network Events Validate ฝั่ง Server
Server คำนวณ Money/Reward
Server ตรวจ Permission
ACE ไม่กว้างเกินไป
RCON ปิดถ้าไม่ใช้
Password ไม่ซ้ำ
Firewall เปิดเฉพาะบริการจำเป็น
Database ไม่เปิดกว้าง
Secrets อยู่ Server-side
Entity Lockdown ได้รับการทดสอบ
State Bags ไม่ถูก Trust แบบ Client-authoritative
Resource Update อยู่ในรุ่นรองรับ
Logging
Backup
Staging

85. คำถามที่พบบ่อย

FiveM Server Security ต้องตั้งค่าอะไรบ้าง?

ต้องดูทั้ง Events, ACE Permissions, Entity Lockdown, State Bags, Network, RCON, Database, Resources และ Admin Access

มี Anti-cheat แล้วต้อง Secure Events ไหม?

ต้อง Cfx.re แนะนำให้ Validate Server Events แม้มี Anti-cheat

Client ส่งเงินมาให้ Server เชื่อได้ไหม?

ไม่ได้ Server ควรคำนวณและตรวจเงินเอง

RegisterNetEvent ปลอดภัยหรือไม่?

เป็นเพียงการเปิด Event ให้ใช้ผ่าน Network ต้องมี Authorization/Validation เพิ่ม

sv_scriptHookAllowed ควรตั้งอะไร?

Vanilla Example ของ Cfx.re ใช้ sv_scriptHookAllowed 0

sv_stateBagStrictMode คืออะไร?

เมื่อเปิดจะจำกัดการแก้ State Bags ให้ Server เท่านั้น แต่ต้องตรวจ Compatibility ก่อน

Entity Lockdown strict คืออะไร?

ไม่ให้ Client สร้าง Entity ใน Routing Bucket ที่ใช้ Strict Mode

sv_filterRequestControl คืออะไร?

ใช้ควบคุมการ Routing ของ Entity Control Requests และมีหลายระดับ ต้องทดสอบก่อนปรับ

เปิด Security ConVars ทุกตัวแรงสุดดีไหม?

ไม่ ค่าบางตัวมีผลต่อ Compatibility และ Cfx.re เตือนว่าไม่ควร Copy/Paste โดยไม่เข้าใจ

RCON ควรเปิดไหม?

ถ้าไม่ใช้ไม่จำเป็นต้องเปิด หากใช้ต้องปกป้อง Password และ Network Access อย่างเข้มงวด

86. สรุป FiveM Server Security ต้องตั้งค่าอะไรบ้าง

FiveM Server ที่ปลอดภัยไม่ควรเริ่มจากคำถามว่า

“ใช้ Anti-cheat ตัวไหนดี?”

เพียงอย่างเดียว

แต่ควรเริ่มจาก Architecture:

Never Trust Client
↓
Validate Network Events
↓
Server-side Authority
↓
Least Privilege
↓
Entity / State Protection
↓
Network Hardening
↓
Monitoring
↓
Backup

Cfx.re ระบุชัดว่า Cheat Client สามารถพยายาม Trigger Events ได้ ดังนั้น Resource ที่รับข้อมูลจาก Client ต้องตรวจ

Money
Inventory
Position
Player State
Permission
Role

ด้วยข้อมูลฝั่ง Server

Event ที่ไม่จำเป็นต้องใช้ผ่าน Network ก็ควรใช้ Local Event แทน RegisterNetEvent

ใน server.cfg ควรตรวจอย่างน้อย

sv_scriptHookAllowed 0

หาก Server ไม่ต้องการ Scripthook และตรวจ ACE Permissions ไม่ให้ Admin/Resources ได้สิทธิ์มากเกินจำเป็น

สำหรับ OneSync สามารถใช้ Entity Lockdown เช่น strict ใน Architecture ที่เหมาะสม และ State Bags มี sv_stateBagStrictMode สำหรับทำให้ Server เป็นผู้แก้ State เพียงฝ่ายเดียว แต่ทั้งสองระบบต้องทดสอบกับ Resources ก่อนเปิดจริง

Security ConVars เช่น

sv_filterRequestControl
sv_authMinTrust
sv_authMaxVariance
sv_disableClientReplays

ก็มีให้ใช้ แต่ไม่ควรตั้งค่าจากบทความหรือ Config ของ Server อื่นแบบ Copy/Paste เพราะ Cfx.re เตือนโดยตรงว่าบาง Setting สามารถกระทบผู้เล่นและ Compatibility ได้

FiveM Enhanced ยังเปลี่ยน Connection Handshake ใหม่ โดยไม่ใช้ UDP จนกว่าจะเชื่อมต่อสำเร็จและใช้ WebSocket สำหรับ Connection Deferrals ซึ่งช่วยให้การป้องกัน Denial-of-Service ทำได้ง่ายขึ้น แต่ Server ที่มี Firewall, Proxy หรือ DDoS Protection แบบ Custom ต้องตรวจว่า Infrastructure เดิมรองรับ Connection Flow ใหม่หรือไม่

แนวทางที่ comsiam แนะนำคือ

Secure Code ก่อน → Secure Permissions → Secure Network → Secure Admin → Monitor → Backup

ไม่ใช่ติด Anti-cheat แล้วถือว่าเสร็จ

จำสั้น ๆ:

Client → อย่า Trust

Money/Items → Server คำนวณ

Events → Validate ทุก Input สำคัญ

Permissions → ตรวจ Server-side

ACE → Least Privilege

Entity → Lockdown เมื่อ Architecture รองรับ

State Bags → Critical State ต้อง Server-authoritative

RCON → ปิดถ้าไม่ใช้

Secrets → ห้ามอยู่ Client/Public Git

Database → จำกัดสิทธิ์และ Network

Security ConVars → อย่า Copy/Paste โดยไม่ทดสอบ

Enhanced → ตรวจ Firewall/DDoS Protection กับ Handshake ใหม่

Backup → ต้อง Restore ได้จริง

Security ที่แข็งแรงที่สุดจึงมาจากหลาย Layer ทำงานร่วมกัน และต่อให้ผู้เล่นสามารถส่ง Request แปลก ๆ เข้ามา Server ก็ควรตรวจพบว่า Request นั้นไม่สมเหตุสมผลและปฏิเสธก่อนจะกระทบ Economy, Entity หรือสิทธิ์ของผู้เล่นรายอื่น