This website uses cookies essential to its operation, for analytics, and for personalized content. By continuing to browse this site, you acknowledge the use of cookies.
For details on cookie usage on our site, read our Privacy Policy
For details on cookie usage on our site, read our Privacy Policy
About ktm530russ
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- LIVEcommunity
- About ktm530russ
11-16-2021
29Posts
4Likes
3Solutions
Nov 16, 2021Last Visited
User
Activity
User
Profile
Latest posts by ktm530russ
| Subject | Views | Posted |
|---|---|---|
| 5954 | 07-08-2013 02:14 PM | |
| 3235 | 07-08-2013 02:00 PM | |
| 1679 | 06-21-2013 10:45 AM | |
| 4044 | 06-20-2013 08:21 AM | |
| 4330 | 06-19-2013 04:45 PM |
My Liked Posts
| Subject | Likes | Posted |
|---|---|---|
| 1 Like | 01-29-2013 02:32 PM | |
| 3 Likes | 09-09-2011 12:17 PM |
User Badges
Community Statistics
| Member Since | 08-29-2011 10:06 AM |
| Date Last Visited | 11-16-2021 07:08 PM |
| Posts | 29 |
| Total Likes Received | 4 |
07-08-2013
02:14 PM
Just wanted to close the loop on this "issue", the RegEx strings that were suggested above DO WORK, I found via Tech Support that the DEFAULT Program will Over-Ride the Custom Programs, even if the Security Rules are set correctly. Example: We were blocking Custom DNS RegEx strings for DDOS blocking, and allowing all other DNS (Worked great) We changed our Security Rules to ALLOW only OUR DNS, then set the DNS rule (default program) to block further down, and it blocked ALL DNS requests. This is due to the APPLICATION inspection taking place BEFORE the Security Rule processing, and with DNS (default) being blocked, it NEVER looked at the Custom DNS applications, and also ignored all the DNS security rules..... Seems kind of a broken thought/engineering process to me... Our fix (via tech support): Created the Custom Application to ALLOW OUR DNS, then created ANOTHER Custom Application that will match for ALL DNS requests . (Regex that looked for this information: "identifying the two bytes for number of Questions, Answers, Authority, and first byte of Additional RRs" (\x 00 01 00 00 00 00 00 \x). We then allowed our DNS Custom Application, and blocked this new Generic DNS custom application, and at the bottom of our Security Rules allow the default DNS application. (This is now getting zero hits). Thanks for all the assistance with this...
... View more
07-08-2013
02:00 PM
Tech Support had my change the Heartbeat Interval to 2000ms from 1000ms, but that did not make any difference. We upgraded to 5.0.5, and have not had the issue since. I cannot say if it was a bug or not, but the upgrade is what seemed to fix our issue. Russ
... View more
06-21-2013
10:45 AM
Well, I THOUGHT it was all working, but still having issues. I believe the answer is in using the HEX Strings, but the format is giving me fits! As long as the Pattern Matching hits for the ENTIRE DNS Request, it seems to work, (I put in --- .*\x 69 73 63 03 6f 72 67 \x ---) for "isc.org", which is EXACTLY 7 bytes, and it is now blocking these requests (Another DDOS URL).) So, I am trying to set up a Pattern Matching for a PORTION of a string inside a DNS request, but the rule fails to match the traffic. (per packet captures). Obfuscated, but if I put in patterns to match these: it.really.is.nt 69 74 02 72 65 61 6c 6c 79 02 69 73 02 6e 74 IT.REALLY.IS.NT 49 54 02 52 45 41 4c 4c 59 02 49 53 02 4e 54 I get matching hits on DNS requests that include ONLY that exact string, anything that prepends or appends to this does NOT hit this rule. (ie: www.it.really.is.nt, or MX1.it.really.is.nt) A couple of options I have tried (only showing the lower-case attempts, but had the upper-case also, under two Custom Applications, and two Security Rules): \x 69 74 02 72 65 61 6c 6c 79 02 69 73 02 6e 74 \x .*\x 69 74 02 72 65 61 6c 6c 79 02 69 73 02 6e 74 \x .*(\x 69 74 02 72 65 61 6c 6c 79 02 69 73 02 6e 74 \x) .*( \x 69 74 02 72 65 61 6c 6c 79 02 69 73 02 6e 74 \x ) I also tried to shorten this to just the "really.is" portion, upper and lowercase, with the same type of results (exact string match, any "extra" characters in the DNS request do not hit the rule). After I clear out my two other open Tech support cases, I am going to open a case for this issue. I am getting WAY too frustrated waiting for the 10-minute "commit" 20-30 times per day! EDIT: Another question: WHAT are valid HEX strings for a "period"? I have seen 02, 03, and 06 in my captures, Message was edited by: Russel Smith
... View more
06-20-2013
08:21 AM
Thanks for the responses. I DO need to see the acual data inside the packets (looking for which DNS request string is hitting each DNS rule), thus the question regarding packet capture. I thought of doing the PCAP comparison to the traffic log, but we had over 17,000 DNS capture packets under 2 minutes... even parsing for time-stamps would be a HUGE undertaking...
... View more
06-19-2013
04:45 PM
I need to confirm what traffic data (specific DNS Request strings inside the packet) is hitting two specific Security rules, so would like to capture just the traffic that is hitting these rules. Is there any way to do this? I have run the Packet Capture (in,out,firewall, and drop), filtered to port 53 (DNS), but have no way of knowing WHICH rule the traffic is hitting. I tried setting one rule to "Block", and was able to see the "Drop" capture traffic for that rule, but my clients started screaming due to legitimate DNS requests failing. Can't do that again.....
... View more
Labels:
- Labels:
-
Configuration
-
Troubleshooting
Contact Me
| Online Status |
Offline
|
| Date Last Visited |
11-16-2021
07:08 PM
|
Latest Tags
No tags yet
LEGAL NOTICES
Copyright 2007 - 2023 - Palo Alto Networks