Enable Packet Captures - not working as expected
-
Hi,
have pfsense 2.4.5-RELEASE-p1 running on a PC Engines APU2
Have Snort configured on LAN interface and no blocking on.
Alerts are comming in, so i thought, i enable packet capturing for alerts in the snort interface config.After restarting the snort interface snort...log is created in /var/log/snort, but for only 1 Alerts, which was created after the snort interface restart.
Is this a bug or a feature?
I had the impression, that for every alert a snort log is created.Restarting snort interface picks up the next alert, which is coming in......
Then the next snort log is created for only one alert.....How do i capture alerts without this start / stop triggeing of the snort interface?
regards
Mat
-
@mamema said in Enable Packet Captures - not working as expected:
so i thought, i enable packet capturing for alerts
Hi,
if you want to investigate every single alarm with a package capture, you will have a lot of work to do
this is not how it works,.... that is, it would be a goliath job
(mainly because there are some that are not so interesting and some are false positives, etc.)You can view the blocked IPs in IDS mode here - Diagnostics / Tables / snort2c
or on the GUI Alerts or Blocks or Logs View tab(s) (IPS / IDS different)
BTW:
if you ask your question on the Snort / Suricata topic, Bill @bmeeks, will help
-
Hi,
i have not blocked IPs in diagnostic/snortc, as i haven't blocking enabled.
Sure, there would be a lot of captureing going on, if a lot alerts came up. in my case there were only five of them and the captured one had 5 entries with 4096 bytes total. So not much...
For which situation is this snort capture setting even there, if i follow your argument?
It's quite nice to capture the offending package frarmes when they come up. But when i have to restart the interface to trigger this, then i'm unable to know what gets triggered next....
Then i could use the capturing of the pfsense app itself.
I just don't see the advantage of the setting in snort then.....regards
Mat
-
You are going about this the wrong way. Alerts are not packet captures. Alerts simply tell you that something happened to trigger a rule, and it prints the information associated with that alert to the alerts log file.
Sounds like you want to enable the packet capture option. That is on the INTERFACE SETTINGS tab for the interfaces where you have Snort enabled. In your case, sounds like that will be on the LAN, so go to the INTERFACES tab in Snort and click the edit icon for your LAN interface. That will bring up the Interface Edit screen. Find the Enable Packet Captures option and enable it. I've highlighted the appropriate section in a red rectangle.
Snort will then generate a
tcpdumpcompatible packet capture for each generated alert. Be forewarned! On a busy network with lots of traffic this option can eat up a ton of disk space quickly! That's why it is disabled by default. I suggest you visit the LOGS MGMT tab in Snort and enable automatic logs management and set some reasonable limits on how many packet capture files are retained. -
Hi,
thats exactly what i did, perhaps my wording wasn't correct, sorry for that. So let's call it tcpdump then, for Wireshark in my case.
I had 5 alerts while this option was enabled and only one was recorded with 4096 bytes in total, so this alert was recorded (dumped), but the other four weren't
I had to restart the interface to trigger the next (only one) alert.
The implications about amount of data and number of alerts are clear to me. My point ist, it's not working as expected completely aside the logging implicationsRegards
Mat
-
Try enabling Unified2 logging.
You can use u2spewfoo to view the capture and u2boat to create a wireshark packet capture.
[2.4.5-RELEASE][admin@pfsense]/var/log/snort/snort_pppoe054518: u2spewfoo snort_54518_pppoe0.u2 (Event) sensor id: 0 event id: 3572891649 event second: 1608632345 event microsecond: 398191 sig id: 5 gen id: 122 revision: 1 classification: 3 priority: 2 ip source: 4.79.142.206 ip destination: xx.xx.xx.xx src port: 0 dest port: 0 protocol: 6 impact_flag: 0 blocked: 0 mpls label: 0 vland id: 0 policy id: 0 appid: Packet sensor id: 0 event id: 3572891649 event second: 1608632345 packet second: 1608632345 packet microsecond: 398191 linktype: 0 packet_length: 166 [ 0] 02 00 00 00 45 00 00 A6 F0 00 00 00 E5 FF F1 00 ....E........... [ 16] 04 4F 8E CE 52 45 0F 68 50 72 69 6F 72 69 74 79 .O..RE.hPriority [ 32] 20 43 6F 75 6E 74 3A 20 30 0A 43 6F 6E 6E 65 63 Count: 0.Connec [ 48] 74 69 6F 6E 20 43 6F 75 6E 74 3A 20 32 30 30 0A tion Count: 200. [ 64] 49 50 20 43 6F 75 6E 74 3A 20 39 0A 53 63 61 6E IP Count: 9.Scan [ 80] 6E 65 72 20 49 50 20 52 61 6E 67 65 3A 20 34 2E ner IP Range: 4. [ 96] 37 39 2E 31 34 32 2E 32 30 36 3A 31 39 33 2E 32 79.142.206:193.2 [ 112] 37 2E 32 32 39 2E 32 30 37 0A 50 6F 72 74 2F 50 7.229.207.Port/P [ 128] 72 6F 74 6F 20 43 6F 75 6E 74 3A 20 32 30 30 0A roto Count: 200. [ 144] 50 6F 72 74 2F 50 72 6F 74 6F 20 52 61 6E 67 65 Port/Proto Range [ 160] 3A 20 30 3A 31 35 : 0:15 [2.4.5-RELEASE][admin@pfsense]/var/log/snort/snort_pppoe054518: -
@mamema said in Enable Packet Captures - not working as expected:
Hi,
thats exactly what i did, perhaps my wording wasn't correct, sorry for that. So let's call it tcpdump then, for Wireshark in my case.
I had 5 alerts while this option was enabled and only one was recorded with 4096 bytes in total, so this alert was recorded (dumped), but the other four weren't
I had to restart the interface to trigger the next (only one) alert.
The implications about amount of data and number of alerts are clear to me. My point ist, it's not working as expected completely aside the logging implicationsRegards
Mat
Sorry, your post was not clear to me. I thought you were talking about the alerts log.
Snort opens a packet capture file when it starts, and then writes to that file until it hits the configured size limit (128 MB by default), then it rotates that file and starts a new one. The
tcpdumpformat option is not very efficient, however, and on a busy system could lead to lost logging I suspect. That's why the U2 format is there. Try what @NogBadTheBad mentioned and see how that works.I will investigate the
tcpdumpoption to see if I can replicate the issue. -
@bmeeks said in Enable Packet Captures - not working as expected:
Sorry, your post was not clear to me.
I'm joining
@NogBadTheBad " this is good stuff I will try"
-
@nogbadthebad did you ever get a resolution to this. I am having the same issue. PCAPs are enabled under the snort interface and alerts are going off but no option to see the pcaps in the GUI. The only way to see any captures is to log in via CLI and navigate to the directory.
@bmeeks are we doing something wrong here? Im currently operating in IDS mode -
@michmoor said in Enable Packet Captures - not working as expected:
PCAPs are enabled under the snort interface and alerts are going off but no option to see the pcaps in the GUI. The only way to see any captures is to log in via CLI and navigate to the directory.
@bmeeks are we doing something wrong here? Im currently operating in IDS modeNo, you're not doing something wrong. There is no capability within the Snort GUI to view or otherwise manipulate captured data. The whole idea is for users to have an external logging and analysis system if they want to get to that level of detail. There is only so much horsepower within the PHP environment on pfSense. And adding a lot of extra libraries for fancy displays adds additional attack surfaces. Much better in my opinion to have the firewall capture and log, but then send that data off to a third-party system for detailed analysis.
-
@bmeeks for logging it makes sense to send it off to “enter syslog server of your choice” but what system is there to send pcaps off for analysis?
I understand what you’re stating from a security php perspective but then the heavy lifting is still on the consumer (pfsense user) to figure out how to make the IDS a useful tool. Seems counterintuitive then to have it but then it’s not convenient enough to use.
