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 aisherwood
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- LIVEcommunity
- About aisherwood
12-28-2019
4Posts
2Likes
1Solution
Dec 28, 2019Last Visited
User
Activity
User
Profile
Latest posts by aisherwood
| Subject | Views | Posted |
|---|---|---|
| 2854 | 11-17-2019 11:50 PM | |
| 2432 | 10-21-2015 03:21 AM | |
| 2495 | 10-18-2015 03:58 AM | |
| 2509 | 10-17-2015 11:24 PM |
My Liked Posts
| Subject | Likes | Posted |
|---|---|---|
| 2 Likes | 11-17-2019 11:50 PM |
User Badges
Community Statistics
| Member Since | 05-01-2015 02:02 AM |
| Date Last Visited | 12-28-2019 08:28 AM |
| Posts | 4 |
| Total Likes Received | 2 |
11-17-2019
11:50 PM
2 Kudos
If I hazard a guess, would I be right in saying you're having trouble with the AusCERT prototype?
If so, I had the same problem, came up with the same fix (i.e. mark the regex as ungreedy), become confused when it didn't work, searched Google trying to find Minemeld's handling of regexes, found nothing, then ending up finding this thread.
Assuming you're having the same problem, I came up with a workaround since there didn't seem to be any documentation on how this is supposed to be handled.
Modify the auscert.yml prototype, and replace 'xml' with 'txt' in all the URLs. Then, comment out the 'indicator:' section of each prototype.
For example, change:
7days_combo:
author: Simon Coggins
development_status: STABLE
node_type: miner
indicator_types: [ URL ]
tags:
- ConfidenceHigh
- ShareLevelRed
description: 7 days combo
config:
age_out:
default: null
sudden_death: true
source_name: auscert.7days_combo
url: https://www.auscert.org.au/api/v1/malurl/combo-7-xml
indicator:
regex: '<uri>(.*)</uri>'
transform: '\1'
attributes:
type: URL
share_level: red
confidence: 80
class: minemeld.ft.auscert.MaliciousURLFeed
to:
7days_combo:
author: Simon Coggins
development_status: STABLE
node_type: miner
indicator_types: [ URL ]
tags:
- ConfidenceHigh
- ShareLevelRed
description: 7 days combo
config:
age_out:
default: null
sudden_death: true
source_name: auscert.7days_combo
url: https://www.auscert.org.au/api/v1/malurl/combo-7-txt
attributes:
type: URL
share_level: red
confidence: 80
class: minemeld.ft.auscert.MaliciousURLFeed
Then just restart the Minemeld process.
If I've deduced incorrectly and your problems have nothing to do with AusCERT, then please ignore this post...
... View more
10-21-2015
03:21 AM
I did have a zone protection profile set, but I've disabled it for troubleshooting purposes (and in any regards, syn-cookies didn't appear to be enabled in it). I've got no DoS Protection profiles either.
I tried running a packet capture and the results were interesting. When capturing on ethernet1/2 (untrust) I can see syn-ack packets from the target server in the packet capture which seems to suggest the server really is replying -- however, if I do the same nmap scan to a completely made up IP like 1.2.3.4 I also see syn-ack replies - so whilst they're in the captures, they can't be from the real source IP.
Traffic logs list the session as 'incomplete'.
In regards to the NAT policy, I had it configured the policy via the PA web GUI, and that IP was actually selected from a drop-down list of valid addresses and not me entering it directly (i.e. so I couldn't select /32 even if I wanted to). To simplify the rule I removed the IP address entirely so now it's just:
NAT POLICIES Source Zone: trust Destination Zone: untrust Destination Interface: any Service: any Source Address: any Destination Address: any Translation Type: Dynamic IP and Port Address Type: Interface Address Interface: ethernet1/2 IP address: none
Is there anywhere else where syn-cookies could be configured that I've missed or got any other suggestions?
... View more
10-18-2015
03:58 AM
Hi Raido,
If I do a nmap of a webserver in the same zone and subnet then nmap returns 'normal' results (i.e. only the ports that are really open are reported as open, ports that are really closed are reported as closed.). However, when I do this, traffic isn't flowing through the PA VM-100 (i.e. because it's in the same subnet it doesn't hit the default gateway - the firewall).
I had the same thought that it could have been caused from service=any rather than servce=application-default in one of the security rules. In my security rules I did have a few instances of service=any. For the purposes of troubleshooting I changed all those rules to application-default but the nmap scan kept saying all ports were open.
I also created a new security rule at the very top of the list with: source_zone=trust, dest_zone=untrust, dest_ip=serverA, application=any,service=application-default,action=allow,profile_type=none which I thought would override any problem security policies, but it didn't change the behavior, the nmap scan showed it still responding on all ports.
... View more
10-17-2015
11:24 PM
Hey,
I've got an evaluation of the VM-100 (v7.0.2) setup, but I'm finding that for some reason the firewall appears to be intercepting requests and completing a TCP 3-way handshake, regardless if the ultimate destination has the port open or not. Has anyone got any idea if this is normal behaviour, or if I've miss-configured something somewhere (and if so, what specifically I need to do to undo it?)
Steps to replicate: 1. Configure VM-100 as follows: NETWORK INTERFACES Interface: ethernet1/1 Interface Type: Layer3
Virtual Router: default
Zone: trust IP: 192.168.0.1/24
Interface: ethernet1/2 Interface Type: Layer3
Virtual Router: default
Zone: untrust IP: 192.168.100.5/24
VIRTUAL ROUTERS
Name: default
Interfaces: ethernet1/1, ethernet1/2
Static Route
Name: default-route
Destination: 0.0.0.0/0
Interface: ethernet1/2
Next Hop: IP Address - 192.168.100.1
Metric: 10
NAT POLICIES Source Zone: trust Destination Zone: untrust Destination Interface: ethernet1/2 Service: any Source Address: any Destination Address: any Translation Type: Dynamic IP and Port Address Type: Interface Address Interface: ethernet1/2 IP address: 192.168.100.5/24
2. On the Internet (untrust zone) setup a webserver 'ServerA' and configure the host firewall to have TCP port 80 open, but all other ports (e.g. 1-79 and 81-65536) closed.
3. On the local network (trust zone) setup a Windows computer 'WorkstationB' perform a nmap 'Quick Scan' with a target of 'ServerA'
Expected Behavior: nmap reports that port 80 is open, and all other ports closed/filtered.
Actual Behavior: nmap reports that TCP ports 7, 9, 13, 21, 22, 23, 25, 25, 37, 53, 79, 80, 81, 88, 106, ... [cut]..., 49516, 49157 are all open.
The same thing happens if you attempt a nmap in the other direction (e.g. run the scan on ServerA targeting the ethernet1/2 interface on the firewall - nmap returns all ports open, even though in reality only a couple of ports have a NAT rule configured to do destination address translation).
We've got a 7050 at work and it doesn't exhibit this behaviour (i.e. if the destination port is closed, there will be no SYNACK packet sent back to the source and the 3-way TCP handshake never completes). I'm not sure if this is because I've miss-configured something on the VM side, or because the virtual and hardware appliance functions differently.
All of this isn't a problem as such, the Internet still works just fine and servers in the trust zone accessed from untrust with a destination address NAT rule operate normally - it's just really confusing when I'm trying to troubleshoot problems and are not able to figure out if a destination address has a particular TCP port open.
Anyone got any thoughts?
... View more
Contact Me
| Online Status |
Offline
|
| Date Last Visited |
12-28-2019
08:28 AM
|
Latest Tags
No tags yet
LEGAL NOTICES
Copyright 2007 - 2023 - Palo Alto Networks