Re: CIP Packet not being Classified
"Sreedhar Reddy \(mopreddy\) via Snort-users" <[email protected]> Wed, 21 Aug 2024 17:09:48 +0000
| Newsgroups | gmane.comp.security.ids.snort.general |
|---|---|
| Message-ID | <MW5PR11MB5810E59759AEE5F739F2AF99DC8E2@MW5PR11MB5810.namprd11.prod.outlook.com> |
Thanks Russ and Lewis.. Regards, Sreedhar Reddy ________________________________ From: Russ Combs (rucombs) <[email protected]> Sent: Wednesday, August 21, 2024 9:35 PM To: Al Lewis (allewi) <[email protected]>; Sreedhar Reddy (mopreddy) via Snort-users <[email protected]>; Sreedhar Reddy (mopreddy) <[email protected]> Subject: Re: CIP Packet not being Classified Re your earlier questions: 1. It doesn't matter which is the source or dest ports. W/o at least a SYN-ACK packet, Snort uses the heuristic that the lower port number is the server which is often true. The lock 2 pcaps have ports 1054 and 44818. In both cases Snort is guessing that 1054 is the server so it won't match this binder rule: { when = { proto = 'tcp', ports = '44818', role = 'server' }, use = { type = 'cip' } }, Because that is looking for 44818. If you change 44818 to 1054, it will detect cip but the direction will still be wrong. The pcap from Al uses client port 53394 but that would have worked just as well with client port 1054. 2. There is not a bug in Snort, but it could be enhanced to make a better guess in cases like this. ________________________________ From: Al Lewis (allewi) <[email protected]> Sent: Wednesday, August 21, 2024 10:46 AM To: Russ Combs (rucombs) <[email protected]>; Sreedhar Reddy (mopreddy) via Snort-users <[email protected]>; Sreedhar Reddy (mopreddy) <[email protected]> Subject: Re: CIP Packet not being Classified Hello Sreedar, If the packet you sent is wrapped in a session it is identified as CIP. The config file and pcap created are attached. box@box:/var/tmp/snort3$ ./bin/snort -c etc/snort/mopreddy.lua -r /home/xubuntu20/Downloads/PCAPS/CIP-LOCK-2-IP.pcap -Acmg -k none -q 01/12-09:46:45.1001000 [**] [148:2:1] "(cip) CIP data is non-conforming to ODVA standard" [**] [Priority: 3] {TCP} 192.168.1.110:53394 -> 192.168.1.110:44818 cip.stream_tcp[60]: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 70 00 24 00 00 01 02 12 00 00 00 00 00 00 00 00 p.$..... ........ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 ........ ........ A1 00 04 00 4C 00 FE 80 B1 00 10 00 EE 1B 83 00 ....L... ........ 00 00 01 00 05 00 00 00 00 00 00 00 ........ .... - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Its listed in the exit stats: -------------------------------------------------- cip packets: 1 session: 1 max_concurrent_sessions: 1 -------------------------------------------------- Albert Lewis Email: [email protected]<mailto:[email protected]> ________________________________ From: Snort-users <[email protected]> on behalf of Sreedhar Reddy (mopreddy) via Snort-users <[email protected]> Sent: Tuesday, August 20, 2024 3:49 PM To: Russ Combs (rucombs) <[email protected]>; Sreedhar Reddy (mopreddy) via Snort-users <[email protected]> Subject: Re: [Snort-users] CIP Packet not being Classified Hi Russ, I was trying to use/decode externally procured CIP flow and it was not classifying any of the packets as CIP packet. Attaching the original packet. Then I exported one packet so that I could see logs and debug and that's the one I sent earlier. Unfortunately, even the original source capture doesn't have TCP establishment captured. After your response, I extracted another CIP packet from the source file whose dst port is the lesser than src, but still, it is not classifying as cip. Any help here is appreciated. Just one question on your earlier response - Are you saying that there may be an issue with snort code that it takes lower port side as server? Or did I misunderstand? Isn't it that 44418 is the port reserved for cip and should be used? ( Actually I have seen this issue with other CIP packets also but unable to get now - Will add to this chain once I find ) Regards, Sreedhar Reddy ________________________________ From: Russ Combs (rucombs) <[email protected]> Sent: Tuesday, August 20, 2024 9:41 PM To: Sreedhar Reddy (mopreddy) via Snort-users <[email protected]>; Sreedhar Reddy (mopreddy) <[email protected]> Subject: Re: CIP Packet not being Classified Sreedhar, Both pcaps contain only 1 data packet; neither contains the TCP setup. Consequently, Snort is guessing that the end with the lower port number is the server. For the enip_one pcap, that guess is correct. For the lock_attempt pcap, the guess is not correct. If you can get a full flow, or cook one, you will get the lock_attempt to process correctly. In the meantime, we can investigate tweaks for that assumption. We should be able to leverage knowledge of binder ports. Hope that helps. Russ ________________________________ From: Snort-users <[email protected]> on behalf of Sreedhar Reddy (mopreddy) via Snort-users <[email protected]> Sent: Tuesday, August 20, 2024 9:19 AM To: Sreedhar Reddy (mopreddy) via Snort-users <[email protected]> Subject: Re: [Snort-users] CIP Packet not being Classified ________________________________ From: Sreedhar Reddy (mopreddy) Sent: Tuesday, August 20, 2024 6:48 PM To: Sreedhar Reddy (mopreddy) via Snort-users <[email protected]> Subject: CIP Packet not being Classified Team, I am facing an issue where some of CIP Packets are not getting classified as CIP packets. Everything else is same except input CIP packet. Your help is greatly appreciated. Working Case: snort --talos -r ~/pcaps/cip_enip_one.pcapng -c /etc/snort/snort.lua --lua 'trace = { modules = { all = 1 } };' ==> -------------------------------------------------- Module Statistics -------------------------------------------------- appid packets: 1 processed_packets: 1 total_sessions: 1 -------------------------------------------------- binder new_flows: 1 inspects: 1 -------------------------------------------------- cip packets: 1 -------------------------------------------------- detection analyzed: 1 -------------------------------------------------- Non-Working Case: snort --talos -r ~/pcaps/cip_lock_attempt_1.pcap -c /etc/snort/snort.lua --lua 'trace = { modules = { all = 1 } };' -k none ==> -------------------------------------------------- Module Statistics -------------------------------------------------- appid packets: 1 processed_packets: 1 total_sessions: 1 -------------------------------------------------- binder new_flows: 1 inspects: 1 -------------------------------------------------- detection analyzed: 1 -------------------------------------------------- port_scan packets: 1 trackers: 2 -------------------------------------------------- stream flows: 1 -------------------------------------------------- stream_tcp sessions: 1 max: 1 created: 1 released: 1 instantiated: 1 setups: 1 data_trackers: 1 segs_queued: 1 segs_released: 1 rebuilt_packets: 1 rebuilt_bytes: 56 client_cleanups: 1 max_segs: 1 max_bytes: 56 asymmetric_flows: 1 -------------------------------------------------- Appid Statistics -------------------------------------------------- detected apps and services Application: Services Clients Users Payloads Misc Referred unknown: 1 0 0 0 0 0 -------------------------------------------------- Summary Statistics No CIP statistics here ( added -k none for now as it was showing tcp checksum error ) Regards, Sreedhar Reddy _______________________________________________ Snort-users mailing list [email protected] Go to this URL to change user options or unsubscribe: https://lists.snort.org/mailman/listinfo/snort-users To unsubscribe, send an email to: [email protected] Please visit http://blog.snort.org to stay current on all the latest Snort news! Please follow these rules: https://snort.org/faq/what-is-the-mailing-list-etiquette