About aisherwood

aisherwood · ‎11-17-2019

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...

aisherwood · ‎10-21-2015

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?

aisherwood · ‎10-18-2015

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.

aisherwood · ‎10-17-2015

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?

Member Since	‎05-01-2015 02:02 AM
Date Last Visited	‎12-28-2019 08:28 AM
Posts	4
Total Likes Received	2

Online Status	Offline
Date Last Visited	‎12-28-2019 08:28 AM

About aisherwood

Re: Minemeld Regex Syntax Issue

Re: VM-100 responding with SYNACK on all ports

Re: VM-100 responding with SYNACK on all ports

VM-100 responding with SYNACK on all ports

Re: Minemeld Regex Syntax Issue

Re: Minemeld Regex Syntax Issue

Re: VM-100 responding with SYNACK on all ports

Re: VM-100 responding with SYNACK on all ports

VM-100 responding with SYNACK on all ports

Network Security

Cloud Security

Security Operations

About aisherwood