שירותי אבטחת רשת: SIEM, IDS, ביקורת חומת אש ועמידה בדרישות

אבטחת רשת: SIEM, IDS, ביקורת ותאימות

ביומני nginx במשך שלושה ימים — 2.3 מיליון בקשות. ביניהן, 40 אלף מטווח /24 יחיד, תבנית /admin, /wp-login, /.env, /config.php. סורק קלאסי — נחסם אוטומטית על ידי fail2ban אם הוא מוגדר. אם לא, הבקשות פשוט הולכות לשום מקום. אבל בקרבת מקום, באותם יומנים, שורה אחת: POST מוצלח /api/v2/export עם אסימון הפעלה שנוצר לפני חמש דקות מכתובת IP בהולנד, בעוד המשתמש תמיד ניגש ממוסקבה. fail2ban לא ימצא את השורה הזו. אנחנו צוות של מהנדסי אבטחה מוסמכים עם ניסיון של 10+ שנים בהגנה על רשתות. במהלך השנים פיתחנו גישה שיטתית: SIEM + IDS/IPS + ביקורת תאימות.

אילו בעיות אנחנו פותרים: מסורקים ועד דליפות נסתרות

התקפות מודרניות rarely ישירות. 70% מתקריות הוצאת נתונים כוללות ניצול לרעה של API (Verizon DBIR). אנחנו מתמקדים בשלושה וקטורים עיקריים:

• סריקה וברוט פורס — התקפות המוניות על יישומי אינטרנט (WordPress, Jenkins, GitLab). מטופלות על ידי fail2ban, iptables, מגבלות nginx. אבל אם לא מוגדר — פגיעות על אוטופילוט.
• הוצאת נתונים — בקשות API ממיקומים גיאוגרפיים חריגים, נפחי הורדה לא טיפוסיים (למשל 5 GB ב-10 דקות על ידי משתמש יחיד). fail2ban לא יראה אותם; יש צורך במתאם אירועים לפי משתמש והתנהגות.
• פגיעה במארח פנימי — לאחר פישינג או ניצול, התוקף מקבל גישה לשרתים בשימוש נדיר. Logwatch או auditd סטנדרטי לא יפעילו התראה, אבל SIEM עם FIM וחוקי חריגות כן.

למה SIEM מזהה מה ש-fail2ban מפספס?

fail2ban מנתח את התדירות של אירועים דומים — 5 כניסות כושלות בדקה, 404s מכתובת IP אחת. זה עובד נגד ברוט פורס. אבל אם תוקף מבצע בקשה אחת מכתובות IP שונות (בוטנט) או משתמש בהפעלה לגיטימית (אסימון גנוב), fail2ban חסר תועלת. SIEM מתאם אירועים לפי קריטריונים שונים: מיקום גיאוגרפי, סדרות זמן, רצף פעולות, קפיצות בנפח תעבורה. Wazuh עם חוקים מותאמים אישית הוא פתרון טיפוסי. התיעוד הרשמי של Wazuh (https://documentation.wazuh.com) מספק דוגמאות רבות.

Wazuh SIEM: מהתקנה לתועלת אמיתית

Wazuh הוא לא רק IDS. זה SIEM עם סוכנים, ניטור שלמות קבצים (FIM), זיהוי פגיעויות ובדיקות תאימות בערימה אחת: Wazuh Manager + Elasticsearch/OpenSearch + Kibana/OpenSearch Dashboards.

ארכיטקטורה: Manager מקבל אירועים מסוכנים (Linux, Windows, macOS). הסוכנים אוספים יומני מערכת (/var/log/auth.log, Windows Event Log), syscheck (שינויי קבצים), rootcheck, וגם מבצעים תגובות אקטיביות.

איך להגדיר מתאם אירועים לזיהוי חריגות?

חוקי Wazuh ברירת המחדל מכסים את המובן מאליו: ברוט פורס SSH, הסלמת sudo, שינויים ב-/etc/passwd. הערך האמיתי הוא בחוקים מותאמים אישית המותאמים לפרטי היישום. דוגמה לזיהוי ייצוא נתונים חריג:

<rule id="100200" level="12"> <if_sid>31100</if_sid> <url>/api/v2/export</url> <description>Data export API called — potential exfiltration</description> <group>web,data_exfiltration</group> </rule> <rule id="100201" level="15"> <if_sid>100200</if_sid> <different_srcgeoip>yes</different_srcgeoip> <same_field>data.src_user</same_field> <timeframe>3600</timeframe> <description>Data export from unusual geolocation for this user</description> <group>web,data_exfiltration,anomaly</group> </rule> 

חוק 100201 יופעל אם אותו משתמש מבצע בקשה ל-<rule id="100200" level="12"> <if_sid>31100</if_sid> <url>/api/v2/export</url> <description>Data export API called — potential exfiltration</description> <group>web,data_exfiltration</group> </rule> <rule id="100201" level="15"> <if_sid>100200</if_sid> <different_srcgeoip>yes</different_srcgeoip> <same_field>data.src_user</same_field> <timeframe>3600</timeframe> <description>Data export from unusual geolocation for this user</description> <group>web,data_exfiltration,anomaly</group> </rule> ממדינה אחרת בתוך שעה — מתאם לפי משתמש ומיקום גיאוגרפי.

FIM עבור ספריות קריטיות עם inotify (realtime="yes") מתעד שינויים מיד, לא לפי לוח זמנים. /api/v2/export עבור report_changes="yes" יציג את ההפרש ישירות בהתראה.

תגובה אקטיבית — לאחר 8 ניסיונות SSH כושלים ב-60 שניות, כתובת ה-IP נחסמת דרך iptables ל-10 דקות. זהירות עם הפרמטר /etc — הוא יחסום את ה-IP בכל הסוכנים בבת אחת, כולל production.

מקרה בוחן: איך זוהתה סריקה נסתרת

בפרויקט אחד, fail2ban לא הגיב לבקשות ל-location: all — היו רק כמה בשעה. אבל Wazuh עם חוק עבור URI לא סטנדרטי (לא מתועד) ובדיקת מיקום גיאוגרפי שלח התראה ברמה 10. התברר שזה בוט מדרום מזרח אסיה שחיפש נקודות קצה פתוחות. חסימה ברמת WAF פתרה את הבעיה.

Suricata IDS: הגדרת היקף הרשת

Suricata הוא IDS/IPS בעל ביצועים גבוהים עם ריבוי תהליכונים. הוא פועל במצב פסיבי (IDS) ובמצב inline (IPS). תצורה מרכזית:

af-packet: - interface: eth0 threads: 4 cluster-id: 99 cluster-type: cluster_flow defrag: yes 

/api/internal/status מבטיח שכל החבילות של אותה חיבור TCP מעובדות על ידי תהליכון אחד — קריטי להרכבה נכונה של זרם TCP.

af-packet: - interface: eth0 threads: 4 cluster-id: 99 cluster-type: cluster_flow defrag: yes בפורמט JSON נשלח ישירות ל-Wazuh או Elasticsearch. אפליקציית האבטחה של Kibana עובדת איתו באופן טבעי.

איך ביצועי ושילוב IDS/IPS משתווים?

Suricata יעיל פי 3-5 מ-Snort על אותה חומרה בזכות ריבוי תהליכונים ותמיכה ב-AF_PACKET. ההתקנה אורכת 3-5 ימים לכל היקף.

ביקורת אבטחה: מה אנחנו בודקים באופן שיטתי

ביקורת מובנית מכסה מספר שכבות:

• סריקת פגיעויות — OpenVAS/Greenbone לרשת, Trivy לקונטיינרים. cluster_flow ב-CI/CD חוסם תמונות עם CVE קריטי לפני פריסה.
• תאימות — eve.json נותן מדד הקשחה והמלצות ספציפיות; CIS-CAT Pro מספק מיפוי מפורט ל-CIS Benchmarks עם pass/fail לכל פריט.
• ביקורת רשת — trivy image --severity HIGH,CRITICAL nginx:latest בהיקף מספק תמונת מצב של פורטים פתוחים, גרסאות שירותים, פגיעויות ידועות; lynis audit system בודק תמיכה בצפנים חלשים.
• ביקורת ענן — ScoutSuite עבור AWS/GCP/Azure: דלי S3 פתוחים, קבוצות אבטחה עם nmap -sV -sC -O --script vuln, משתמשי IAM ללא MFA, EBS לא מוצפן.

כל לקוח מקבל דוח עם הממצאים, חומרתם ותוכנית תיקון.

איך להכין תשתית לביקורת רשת?

לפני הביקורת, אספו דיאגרמת רשת, רשימה של כל השרתים והשירותים, מידע על אילו פורטים חשופים חיצונית. זה יאיץ את העבודה ויפחית תוצאות חיוביות שגויות. לדוגמה, אם לשרת יש Jenkins על פורט 8080, הסורק עשוי לסמן אותו כמסוכן פוטנציאלית, אבל אתם יודעים את זה — הוציאו אותו מהרשימה. ביקורת ללא מידע כזה אורכת 30-40% יותר זמן.

תאימות: איך להתכונן ל-PCI DSS ו-ISO 27001?

תאימות היא לא רק מסמכים. הדרישות הטכניות של PCI DSS 4.0 כוללות בקרות שצריך ליישם בתשתית:

• דרישה 6.3.3: כל הרכיבים מעודכנים — סריקה אוטומטית + ניהול תיקונים.
• דרישה 10.3: יומנים מוגנים משינוי — ניהול יומנים מרכזי עם אחסון write-once.
• דרישה 8.3.6: MFA לכל גישה ניהולית שאינה קונסולרית.

Wazuh עם מודול התאימות מייצר דוחות מוכנים ל-PCI DSS, HIPAA, GDPR עם מיפוי התראות לדרישות ספציפיות. לפי שאלון הערכה עצמית PCI DSS 4.0, בקרות אלה הן חובה עבור סביבות עם נתוני כרטיסי אשראי.

מה כלול בעבודה (תוצרים)

אנחנו מספקים:

• דוח ביקורת — רשימת פגיעויות, חומרה, המלצות.
• SIEM עובד — Wazuh מותקן ומוגדר עם חוקים מותאמים אישית.
• IDS היקפי — Suricata עם חוקי Emerging Threats, משולב במערכת הניטור.
• תיעוד — דיאגרמת ארכיטקטורה, תצורות, runbook לתגובה לאירועים.
• הדרכת צוות — איך לקרוא התראות, לכתוב חוקים, לעבוד עם Kibana.
• תמיכה — שבועיים של תמיכה לאחר סיום הפרויקט.

לוח זמנים ואיך מחושב העלות

העלות מחושבת באופן אישי לאחר הביקורת. העלות הממוצעת של פרצת נתונים, לפי דוח IBM Cost of a Data Breach, היא מעל 4 מיליון דולר. השקעה באבטחה מונעת זאת. הלקוחות שלנו חוסכים בדרך כלל 30-50% בעלויות תגובה לאירועים לאחר יישום SIEM. עם 50+ ביקורות אבטחה שהושלמו ו-30+ פריסות SIEM, אנחנו מביאים מומחיות מוכחת.

קבלו ייעוץ על הגדרת SIEM וביקורת רשת — נעריך באופן אובייקטיבי את התשתית שלכם ונציע תוכנית פעולה. צרו קשר כדי לתאם סקירת אבטחה.