Snort กำลังรับปริมาณการใช้งาน แต่ไม่ปรากฏว่ากำลังใช้กฎ


11

ฉันติดตั้ง snort แล้วและทำงานในโหมดอินไลน์ผ่าน NFQUEUE บนท้องที่ของฉัน (ในขณะที่ฉันสามารถเดินในห้องถัดไปและแตะ) เกตเวย์ ฉันมีกฎต่อไปนี้ในของฉัน/etc/snort/rules/snort.rules:

alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"ET CURRENT_EVENTS D-LINK Router Backdoor via Specific UA"; flow:to_server,established; content:"xmlset_roodkcableoj28840ybtide"; http_header; pcre:"/^User-Agent\x3a[^\r\n]*?xmlset_roodkcableoj28840ybtide/Hm"; reference:url,www.devttys0.com/2013/10/reverse-engineering-a-d-link-backdoor/; classtype:attempted-admin; sid:2017590; rev:2; metadata:created_at 2013_10_13, updated_at 2013_10_13;)

กฎนี้เกี่ยวข้องกับแบ็คดอร์ที่พบในเราเตอร์ DLink บางตัว ฉันเลือกกฎนี้เพราะดูเหมือนว่าจะทดสอบได้ง่าย ตัวกฎถูกเพิ่มโดย pullpork จากการคุกคามที่เกิดขึ้นใหม่ดังนั้นฉันจึงสันนิษฐานว่าไวยากรณ์ของกฎนั้นถูกต้อง

สำหรับการทดสอบฉันได้กำหนดค่าเกตเวย์ของฉันด้วย lighttpd ที่พอร์ต 80 หันหน้าไปทางอินเทอร์เน็ตและยืนยันว่าสามารถเข้าถึงได้ curl -A 'xmlset_roodkcableoj28840ybtide' 'http://<EXTERNAL_IP>'จากนั้นบนเครื่องระยะไกลฉันวิ่งคำสั่ง สิ่งนี้จะพิมพ์การตอบสนองจาก lighttpd ไปยังคอนโซลและออกทันที ไม่มีการแจ้งเตือน snort บนเกตเวย์

นอกจากนี้ netfilter ดูเหมือนจะใช้ประโยชน์จากกระบวนการ snort สองในสี่ที่ฉันใช้อยู่ ฉันสามารถเห็นสิ่งนี้ในhtopขณะที่กระบวนการ snort บน CPUs 1 และ 2 พัฒนาภาระหนักเมื่อทดสอบกับ bittorrent ... แต่กระบวนการ snort ใน CPUs 0 และ 3 ยังคงไม่ทำงานอย่างสมบูรณ์

วิธีการทดสอบของฉันผิดหรือเปล่า? หรือ snort ไม่แจ้งเตือนเมื่อมันควร (เช่นเนื่องจากข้อผิดพลาดการกำหนดค่า)? ฉันจะดูได้อย่างไรว่าทำไม netfilter ถึงไม่สร้างความสมดุลระหว่างปริมาณข้อมูลทั้งสี่คิว

องค์ประกอบ

My Snort / Netfilter Config

ส่วนที่เกี่ยวข้องเฉพาะของเครือข่าย netfilter ของฉันคือ:

Chain wan-fw (1 references)
 pkts bytes target     prot opt in     out     source               destination         
25766 2960K smurfs     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate INVALID,NEW,UNTRACKED
    4  1380 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpts:67:68
 4267  246K tcpflags   tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           
 3820  550K ~comb0     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate ESTABLISHED     <<=== this one for established connections ====!
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED
  937 79669 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp flags:!0x17/0x02
   13   506 DROP       icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 8 /* Ping */
    4   240 ~log0      tcp  --  *      *       <remote_server>      0.0.0.0/0            tcp dpt:80 /* Tiphares Allowed In */     <<=== this one for new connections ====!
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            ADDRTYPE match dst-type BROADCAST
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            ADDRTYPE match dst-type ANYCAST
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            ADDRTYPE match dst-type MULTICAST
21506 2454K NFLOG      all  --  *      *       0.0.0.0/0            0.0.0.0/0            limit: up to 1/sec burst 10 mode srcip nflog-prefix  "IPv4 wan-fw REJECT " nflog-threshold 1
24808 2878K reject     all  --  *      *       0.0.0.0/0            0.0.0.0/0           [goto] 
Chain ~log0 (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    4   240 NFLOG      all  --  *      *       0.0.0.0/0            0.0.0.0/0            limit: up to 1/sec burst 10 mode srcip /* Tiphares Allowed In */ nflog-prefix  "IPv4 HTTPTest NFQUEUE " nflog-group 1 nflog-threshold 1
    4   240 NFQUEUE    all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* Tiphares Allowed In */ NFQUEUE balance 0:3 bypass cpu-fanout     <<=== passes packets to one of 4 snort processes ====!
Chain ~comb0 (4 references)
 pkts bytes target     prot opt in     out     source               destination         
 474K  196M NFQUEUE    all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate ESTABLISHED NFQUEUE balance 0:3 bypass cpu-fanout     <<=== all established connections from 'wan' are monitored by snort ====!
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0      

ริ้วรอยเพิ่มเติม:

ฉันไม่แน่ใจว่ามันเกี่ยวข้องหรือไม่ ฉันได้ค้นพบสิ่งที่ดูเหมือนจะเป็นอะไรบนเกตเวย์ของฉันที่ส่งแพ็คเก็ต TCP รีเซ็ตไปยัง IP บนอินเทอร์เน็ต และแพ็คเก็ตเหล่านี้จะไม่เกี่ยวข้องกับการเชื่อมต่อที่มีอยู่

ระบุว่าสิ่งนี้เกิดขึ้นเมื่อใช้ bittorrent บนเครื่องที่อยู่ด้านหลังเกตเวย์นี้และแพ็คเก็ตรีเซ็ตส่วนใหญ่จะแสดงรายการพอร์ต torrent เป็นพอร์ตต้นทางสิ่งเดียวที่สมเหตุสมผลสำหรับฉันก็คือ snort กำลังส่งรีเซ็ตเมื่อบล็อกบางสิ่ง (ใช่ไหม? )

แต่ฉันใช้ nfqueue daq ... ดังนั้นหากเป็น snort แล้วทำไม snort จึงส่งแพ็กเก็ตเหล่านี้ในวิธีที่ netfilter มองว่าเป็นการเชื่อมต่อใหม่แทนที่จะแทรกแพ็กเก็ตลงในเครือข่าย netfilter โดยตรงและเชื่อมโยงกับที่มีอยู่เดิม การเชื่อมต่อที่กำลังบล็อกอยู่หรือไม่ และ snort ไม่ได้ถูกตั้งค่าให้ดร็อปแพ็กเก็ตหรือส่งการรีเซ็ต (แจ้งเตือนเท่านั้น) ... ดังนั้นทำไมจึงต้องเริ่มต้นด้วย เหตุใดฉันจึงไม่แน่ใจว่านี่เป็นสิ่งที่ทำเสียงดังลั่น

ข้อมูลอื่น ๆ

ตามคำแนะนำของ @ Lenniey ฉันได้ทำการทดสอบด้วยcurl -A 'asafaweb.com' http://server-ipเช่นกัน สิ่งนี้ยังไม่สร้างการแจ้งเตือน ฉันตรวจสอบอีกครั้งว่ามีกฎสำหรับสิ่งนี้อยู่ในไฟล์กฎของฉัน มีสอง:

alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"ET POLICY ASafaWeb Scan User-Agent (asafaweb.com)"; flow:established,to_server; content:"User-Agent|3a| asafaweb.com|0d 0a|"; http_header; reference:url,asafaweb.com; classtype:network-scan; sid:2014233; rev:2; metadata:created_at 2012_02_16, updated_at 2012_02_16;)

และ

alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"MALWARE-CNC User-Agent ASafaWeb Scan"; flow:to_server,established; content:"User-Agent|3A| asafaweb.com"; fast_pattern:only; http_header; metadata:policy balanced-ips alert, policy security-ips drop, ruleset community, service http; reference:url,asafaweb.com; classtype:network-scan; sid:21327; rev:7;)

ฉันได้อัปเดตการกำหนดค่าของฉันด้วย สิ่งที่ฉันอัปโหลดคือชัดและเก่า (แสดงยอมรับแทนที่จะเป็น NFQUEUE สำหรับกฎ http netfilter)


ความคิดเห็นไม่ได้มีไว้สำหรับการอภิปรายเพิ่มเติม การสนทนานี้ได้รับการย้ายไปแชท
Michael Hampton

iptablesผลลัพธ์ไม่ใช่ทางเลือกที่ดีเว้นแต่คุณจะสนใจเคาน์เตอร์เป็นพิเศษ iptables-saveจะดีกว่าถ้าคุณคาดหวังว่ามนุษย์จะอ่านมัน
poige

@poige เห็นด้วย ในขณะที่ฉันทำตามคำแนะนำที่มาพร้อมกับแท็ก "iptables" อย่างไรก็ตามในอนาคตฉันอาจจะใช้ iptables-save
Cliff Armstrong

คำตอบ:


5

"แก้ไข" ในการแชท

หลังจากการดีบั๊กทุกอย่าง (iptables + NFQUEUE, systemd.service และ drop-in units, snort alert เป็นต้น) ปัญหาที่เกิดขึ้นในแบบที่การทดสอบเสร็จสิ้น

โดยปกติแล้ว snort ใน inline IDS / IPS นั้นไม่ได้ถูกกำหนดให้ตรวจสอบการรับส่งข้อมูลที่น่าสงสัย แต่จะเป็นเพียง HOME_NET (หรือที่รู้จักในเครือข่ายย่อย LAN ท้องถิ่น) แต่ไม่ใช่ IP สาธารณะของตัวเอง กฎระเบียบเดิมได้มีการทดสอบต่อนี้กล่าวว่า IP สาธารณะและอื่น ๆ ไม่ได้สร้างการแจ้งเตือนใด ๆ EXTERNAL_NET any -> HOME_NET anyเป็นค่าเริ่มต้นสำหรับการแจ้งเตือนเป็นสิ่งที่ตามสายของ


นอกจากนี้เนื่องจากคำถามเป็นหลักเพียงเพื่อยืนยันว่าวิธีการทดสอบของฉันถูกต้องและคุณเป็นคนแรกที่ยืนยันว่าเป็น ... คำตอบที่ยอมรับ
Cliff Armstrong

คุณช่วยเพิ่มบิตที่เกี่ยวข้องอีกเล็กน้อยในโพสต์นี้ได้ไหม ในอุดมคติแล้วคนไม่ควรรู้สึกว่าพวกเขาควรอ่านผ่านบันทึกการสนทนาทั้งหมดเพื่อให้แน่ใจว่าพวกเขาเข้าใจคำตอบ
Michael Hampton

@MichaelHampton จริงมากฉันเพิ่มข้อมูลบางอย่าง ดีขึ้นหรือไม่
Lenniey

1
ตกลงตอนนี้ฉันเข้าใจแล้ว ซึ่งหมายความว่าผู้อ่านคนอื่น ๆ ก็อาจจะเช่นกัน
Michael Hampton
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.