התקנת חומת אש ארגונית OPNsense עם אוטומציה

כשטייס יש לו שלושה תריסרי ממשקי רשת וכללי חומת אש מתפשטים כמו נמלים בגלל כאוס בכתובות aliases — הגיע הזמן לחשוב על עיצוב מערכת. OPNsense הוא פיצול של pfSense שבחר בדרך של שחרורים תכופים יותר (כל חודשיים), ממשק משתמש מודרני, ומיקוד באבטחה. טכנית הוא מבוסס על HardenedBSD עם אמצעי הגנה נוספים. הוא חומת אש ונתב ברמה ארגונית, שווה ערך פונקציונלית לפתרונות קנייניים אך בקוד פתוח. השתמשנו בו בסביבת ייצור למעלה מ-5 שנים — וצברנו ניסיון שאנו חולקים כאן.

התקנה והגדרה ראשונית

OPNsense זמין כ-ISO עבור bare-metal ו-OVA/VMDK עבור וירטואליזציה. ב-Proxmox או VMware, פשוט פרסו מתבנית, הקצו שני ממשקי רשת, ואתחלו.

לאחר האתחול הראשון, אשף קונסולה (/usr/local/sbin/opnsense-configure או אוטומטי) רץ. הקצו ממשקי WAN ו-LAN. לאחר מכן הכל נעשה דרך ממשק האינטרנט.

עדכנו את המערכת והחבילות דרך CLI:

# Обновление OPNsense
opnsense-update -u && opnsense-update -p

# Или через API
curl -k -u "admin:password" \
  -X POST "https://192.168.1.1/api/core/firmware/update" \
  -H "Content-Type: application/json"

אוטומציה של ניהול OPNsense עם ה-API

ל-OPNsense יש REST API מלא עם תיעוד Swagger. זה משנה את הגישה לניהול תצורה: במקום לחיצות ידניות או עריכת XML — Ansible, Terraform, או סקריפטים מותאמים. יישמנו GitOps עבור OPNsense בשני פרויקטים — שינויים מוחלים דרך CI/CD, מה שהפחית את MTTR משעות ל-15 דקות (הפחתה של 75%). לפי הנתונים שלנו, הגדרה דרך API מהירה פי 5 מאשר דרך GUI — מ-30 דקות ל-6 דקות לכל כלל. הזמינו פריסת OPNsense עם אוטומציה כדי להאיץ את ההשקה פי 5.

דוגמה לניהול כללי חומת אש דרך API:

BASE="https://192.168.1.1/api"
AUTH="admin:password"

# Создаём alias (группу IP)
curl -k -u "$AUTH" -X POST "$BASE/firewall/alias/addItem" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "trusted_mgmt",
    "type": "network",
    "content": "10.10.10.0/24\n192.168.50.0/24",
    "description": "Trusted management networks"
  }'

# Создаём правило разрешающее SSH из trusted_mgmt
curl -k -u "$AUTH" -X POST "$BASE/firewall/filter/addRule" \
  -H "Content-Type: application/json" \
  -d '{
    "rule": {
      "type": "pass",
      "interface": "wan",
      "ipprotocol": "inet",
      "protocol": "tcp",
      "src": "trusted_mgmt",
      "dst": "any",
      "dstport": "22",
      "description": "Allow SSH from trusted mgmt"
    }
  }'

# Применяем изменения
curl -k -u "$AUTH" -X POST "$BASE/firewall/filter/apply"

ספק ה-Terraform עבור OPNsense (# Обновление OPNsense opnsense-update -u && opnsense-update -p # Или через API curl -k -u "admin:password" \ -X POST "https://192.168.1.1/api/core/firmware/update" \ -H "Content-Type: application/json" ) מאפשר לתאר את כל התצורה כקוד:

resource "opnsense_firewall_alias" "trusted_networks" {
  name        = "trusted_mgmt"
  type        = "network"
  description = "Trusted management networks"
  content = [
    "10.10.10.0/24",
    "192.168.50.0/24"
  ]
}

resource "opnsense_firewall_rule" "allow_ssh_mgmt" {
  enabled         = true
  action          = "pass"
  interface       = "wan"
  protocol        = "tcp"
  source          = opnsense_firewall_alias.trusted_networks.name
  destination     = "any"
  destination_port = "22"
  description     = "Allow SSH from trusted mgmt"
}

למה להשתמש ב-Zenarmor לשכבה 7?

התוסף המובנה Zenarmor (לשעבר Sensei) מוסיף בדיקת חבילות עמוקה עם זיהוי יישומים, סינון לפי קטגוריות, ודיווח. הוא עובד בשני מצבים: מנותב (מנתח תעבורה מועברת) וגשר (שקוף inline).

תרחיש: אפשרו Office 365 ו-Google Workspace, חסמו טורנטים ורשתות חברתיות, ותעדו את כל התעבורה לקטגוריית "איום אבטחה" — ללא ציון מפורש של IPs ודומיינים. Zenarmor פותר זאת דרך מסד נתונים של יישומים עם עדכונים שוטפים. הוא חוסם עד 95% מהיישומים הלא רצויים ללא כתיבת כללים ידנית. בפרויקט אחד, העברנו 50 VLANs ו-200 כללים מ-Cisco ASA ל-OPNsense בשבועיים באמצעות Terraform — העברה ידנית הייתה אורכת חודש.

מניעת חדירות — Suricata או Zeek

OPNsense תומך בשניהם. Suricata לחסימה אקטיבית (IPS inline). Zeek (bro) לניתוח פסיבי ובניית מטא-דאטה של תעבורה (מי דיבר עם מי ומתי, ללא תוכן).

# Обновление Suricata правил через CLI configctl ids update rules configctl ids reload 

לתשתית רצינית, הגיוני לייצא eve.json מ-Suricata ל-ELK או Loki:

// /usr/local/etc/suricata/suricata.yaml (фрагмент)
outputs:
  - eve-log:
      enabled: yes
      filename: /var/log/suricata/eve.json
      types:
        - alert
        - dns
        - http
        - tls

מה כלול בעבודה

פירוט מפורט: הגדרת קלאסטר זמינות גבוהה

זמינות גבוהה מיושמת דרך פרוטוקול CARP וסנכרון תצורה. ההגדרה אורכת כ-3 שעות. המעבר מתרחש בפחות משנייה אחת. חשוב להגדיר סנכרון חיבורים מבוססי מצב (pfsync) כדי למנוע שבירת סשנים פעילים. אנו משתמשים בכתובות VIP לכל שירות וניטור דרך keepalive.

לוחות זמנים ועלויות משוערים

הפחתת עלויות רישוי — OPNsense חינמי, חוסך עד 80% בהשוואה לפתרונות קנייניים (לדוגמה, Cisco ASA יכול לעלות מעל $10,000 בשנה לחברה בינונית). לפריסה טיפוסית, הגדרה בסיסית מתחילה ב-$2,500, בעוד אוטומציה מלאה ו-HA יכולים להגיע ל-$15,000. במשך 3 שנים, החיסכון ברישוי בלבד עולה על $30,000.

העלות מחושבת באופן אישי לאחר ביקורת על התשתית שלכם. פרויקטים טיפוסיים מתחילים ב-$2,500 להגדרה בסיסית ועולים עד $15,000 לאוטומציה מלאה ו-HA. סיפקנו למעלה מ-30 פריסות OPNsense לחברות הנעות בין 50 ל-5000 עובדים. אנו מבטיחים תצורה מוכנה לשימוש, סט תיעוד מלא, והדרכה לצוות שלכם.

תהליך העבודה

1. ניתוח — מלאי רשת, איסוף דרישות אבטחה, אישור פורטים/פרוטוקולים.
2. עיצוב — דיאגרמת L3, חלוקת VLAN, תוכנית IP, מדיניות גישה.
3. יישום — התקנה, הגדרה דרך API/Terraform, הגדרת Zenarmor/Suricata.
4. בדיקות — בדיקות חדירה מבחוץ/מבפנים, בדיקות עומס, אימות מעבר.
5. פריסה — מעבר תעבורה, ניטור במהלך 48 השעות הראשונות, מסירת תיעוד.

טעויות נפוצות וכיצד להימנע מהן

הקצאת ממשק שגויה.

תמיד בדקו פעמיים איזה פורט פיזי מתאים ל-WAN/LAN. השתמשו ב-BASE="https://192.168.1.1/api" AUTH="admin:password" # Создаём alias (группу IP) curl -k -u "$AUTH" -X POST "$BASE/firewall/alias/addItem" \ -H "Content-Type: application/json" \ -d '{ "name": "trusted_mgmt", "type": "network", "content": "10.10.10.0/24\n192.168.50.0/24", "description": "Trusted management networks" }' # Создаём правило разрешающее SSH из trusted_mgmt curl -k -u "$AUTH" -X POST "$BASE/firewall/filter/addRule" \ -H "Content-Type: application/json" \ -d '{ "rule": { "type": "pass", "interface": "wan", "ipprotocol": "inet", "protocol": "tcp", "src": "trusted_mgmt", "dst": "any", "dstport": "22", "description": "Allow SSH from trusted mgmt" } }' # Применяем изменения curl -k -u "$AUTH" -X POST "$BASE/firewall/filter/apply" בקונסולה לפני האשף. איבדנו עד שעתיים לפרויקט בגלל הטעות הזו.

כללים מתירניים מדי.

התחילו עם deny all ופתחו רק פורטים הכרחיים. תארו חריגים בכתובות aliases.

התעלמות מעדכונים.

OPNsense משחרר תיקוני אבטחה כל שבועיים — הגדירו עדכונים אוטומטיים דרך API או cron.

סיפקנו למעלה מ-30 פריסות OPNsense לחברות הנעות בין 50 ל-5000 עובדים. אנו מבטיחים תצורה מוכנה לשימוש, סט תיעוד מלא, והדרכה לצוות שלכם. לקריאה נוספת, ראו תיעוד OPNsense. צרו קשר לייעוץ — נעריך את הפרויקט שלכם ביום אחד ונבחר את התצורה האופטימלית.

חסכו בתקציב — OPNsense חינמי, ואוטומציה מפחיתה עלויות תפעוליות בעד 75% לפי הלקוחות שלנו. הזמינו פריסה עכשיו.