- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
06-05-2018 01:51 PM - edited 06-05-2018 01:51 PM
So I've had some issues with the most recent custom app I'm attempting to make. Our server team is implementing Papercut on campus and there doesn't seem to be a pre-built app for it. I submitted a request for it but figured I'd try to take a crack at it myself.
It's turned out to be fairly interesting... Windows and Apple iOS devices ended up being pretty easy to identify but Android lacked any of the custom signaturese I was looking at in Windows. I ended up just basing it on the SSL cert for now.
ChromeOS has been the latest pain. I found something in the pcap that looks promising... basically a Chrome extension ID that, I believe, should be static and unique (you can see the Origin line is highlighted):
Next, I started a custom app using tcp/9163.
With the signature, I started including the chrome-extension but ended up doing just the ID after many attempts to get it to identify it with no luck.
The traffic is still just identified as web-browsing... any idea what I might be doing wrong here?
Also, on the page:
What happens if I add more signatures here? There doesn't seem to be a way to move them around for order of precidence... is this considered an OR list or an AND list?
Thanks!
06-06-2018 02:42 AM
Hello,
adding complexity to the signature will not make it trigger more offten or better, it will trigger less, right? Probably 🙂
Anyhow, I'd try to do this with hex pattern. Do you have a pcap of that communication?
alhngdk should be sufficient, and it goes into hex as 61 6c 68 6e 67 64 6b. Can you try with that and see what is your mileage? Once you get the hit with 7 bytes (minimum for signature) you can expand that hex to cover the whole string of yours (to avoid FPs).
Best regards,
Luciano
06-06-2018 06:40 AM
Thanks for the reply. I was under the impression that it was recommended to add additional signatures to help to further ensure the traffic is actually for your application and not false positives? Whether those additional signatures are complex or not depends on the signatures I guess.
I'll try it as hex... I've done some others like that but I figured it was unnecessary since I was tyring to match something that the http-req-header filter says it covers according to the documentation (Origin field in particular). I originally had this signature looking only at http-method POST but I removed it to try to get it to match.
I've attached the pcap I'm working with. I hope Palo Alto makes an official app. The work is interesting but there are so many device types out there that all seem to want to do the same thing differently.
Thanks
06-06-2018 08:52 AM - edited 06-06-2018 08:52 AM
Hi,
as far as additional items in the signature go - sure, correct, it is better to "pin-point" it with more details, but as we aren't hitting original traffic with more detail, it makes more sense to have less detail until we hit it and then work our way back up to more details in the signature 🙂
If you have problems with hex, lemme know - I will try to lab it up internally on my side and let test it, if it doesn't work for you.
BR
Luciano
06-06-2018 11:21 AM
Unfortunately it still looks to be identified as web-browsing on our most recent test. I created a secondary rule to allow web-browsing over tcp 9163 to see if maybe the application wasn't getting identified at first and so was being denied as web-browsing before ID (that HTTP Post is really at the end of the session)... it's still just going through as web-browsing.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!