אבטחת שרת FiveM בשכבות, מ-SSH עד ACE. אנטיצ'יט יקר לא מחליף קונסולה פתוחה, הרשאות רחבות מדי, פאנל חשוף וגיבויים שלא קיימים. כאן סדר חשיבות אמיתי.
מה מנסים לעשות לכם בפועל
- כניסה ל-txAdmin עם סיסמה חלשה
- ניצול משאב עם event פתוח שמבצע פעולה רגישה בצד שרת
- ספאם entities / explosions / events שמוציא את השרת מאיזון
- גניבת דאטה דרך endpoints או backups חשופים
- השתלטות על ה-VPS דרך SSH
הגנה רק בתוך המשחק עם מכונה פרוצה = הפסד מראש.
שכבה 1: המכונה לפני המשחק
- משתמש לא-root להרצה יומיומית
- SSH במפתחות בלבד, בלי סיסמה
- firewall: רק מה שחייב פתוח
- עדכוני מערכת בחלון תחזוקה קבוע
- גיבויים מחוץ לדיסק של השרת עצמו
fail2ban (או מקבילה) על SSH ועל פאנל ניהול חוסך הפתעות ב-2 בלילה.
שכבה 2: txAdmin וגישת צוות
txAdmin שולט בכל החיים של השרת, ולכן הוא יעד מבוקש.
עשו לפחות:
- סיסמת מנהל ארוכה וייחודית + 2FA אם זמין
- אל תחשפו את הפאנל לאינטרנט בלי VPN / IP allowlist / reverse proxy עם אימות
- משתמשים לפי תפקיד: תומך לא צריך הרשאות פריסה מלאות
- לוג פעולות אחרי כל אירוע חשוד
דומיין לפאנל = TLS. פאנל על HTTP ברשת פתוחה הוא הזמנה.
שכבה 3: ACE והרשאות בתוך FiveM
הטעות הקלאסית: לתת לקבוצת "admin" יותר מדי, ואז להוסיף אנשים "רק לרגע".
עקרונות:
- least privilege: כל תפקיד רק מה שהוא צריך
- הפרדה בין admin רשת, admin משחק ומודרטור צ'אט
- אין סיסמאות משותפות בדיסקורד לרשימת ACE
- כל שינוי הרשאות נרשם: מי, מתי, למה
בדקו במיוחד פקודות כסף, נשקים, רכבים ו-kick/ban גורף.
שכבה 4: אירועי רשת בסקריפטים
משאבים ישנים מאזינים לקליינט ומבצעים פעולה רגישה בלי אימות.
כלל ברזל:
- כל שינוי כסף/פריט/הרשאה עם אימות צד-שרת
- אל תסמכו על "הקליינט לא אמור לשלוח את זה"
- rate limit לאירועים שקל להציף
כשמוסיפים משאב מ-GitHub, קראו את קבצי ה-server.
RegisterNetEvent שמשנה DB ישירות מפרמטרי לקוח = תחשבו פעמיים.שכבה 5: אנטיצ'יט ומה שהוא לא יכסה
אנטיצ'יט עוזר נגד חלק מההזרקות. הוא לא מציל ממשאב פרוץ או מפאנל חלש.
שילוב סביר:
- אנטיצ'יט עם לוגים שמישהו באמת קורא
- רשימת ban מעודכנת
- נוהל ערעור באן (false positives מרחיקים קהילה מהר יותר מצ'יטר בודד)
אל תפעילו עשר שכבות חוסמות בלי להבין מה כל אחת עושה.
גיבויים: המבחן האמיתי
גיבוי שלא ניסיתם לשחזר ממנו הוא בדיחה. פעם בחודש:
- שחזרו DB למופע בדיקה
- ודאו ש-resources קריטיים עולים
- מדדו זמן חזרה לאונליין
עותק אחד offsite לפחות. כונן מלא על אותו VPS לא נחשב תוכנית התאוששות.
נוהל תקרית קצר
- snapshot / כבו כתיבה רגישה אם צריך
- סגרו גישות חשודות (פאנל, SSH, keys)
- שמרו לוגים לפני ניקוי
- בדקו שינויים אחרונים ב-resources ובהרשאות
- עדכנו את הקהילה בכנות, בלי דרמה מיותרת
אבטחה טובה ב-FiveM היא שגרה: מכונה נעולה, פאנל מוגן, ACE צר, סקריפטים שלא סומכים על הקליינט, וגיבוי שעובד. מי שמדלג על הבסיס ומדבר רק על "האנטיצ'יט הכי חזק" מגלה את החור בלילה הכי עמוס בשבוע.