About mikand

What about the Cisco ASA? It wouldnt be the first time Cisco has a malfunction in their code... ... View more

As I understand it Panorama is supposed to use a "delivery guaranteed" method of transfering logs between the firewall and the Panorama (and if it fails it should be logged which block of logs is missing). That is in order to get the logs reliably from your firewall to your syslog-server something like this should work: PA-firewall -> unreliable link (satellite link or whatever) -> Panorama -> reliable link (like in the same or nearby rack) -> Syslog-server ... View more

https://live.paloaltonetworks.com/message/17280#17280 I wonder what happend to TLS1.2 support? ... View more

Sounds like you should contact the tech support... and then update this thread with the result. To me disabling l3-forwarding for a particular vlan-interface, no matter if this vlan-interface has an ip address attached to it or not, should mean that this vlan-interface wont forward packets to other vlan-interfaces and it should not accept packets from other vlan-interfaces aswell. However it should still forward packets to/from physical interfaces which are part of this vlan. In your case ethernet1/1 should be able to forward packets to/from ethernet1/10 since both are part of vlan.10 but ethernet1/1 should not be able to forward packets to/from ethernet1/7 since that interface is part of vlan.2 which is different vlan. ... View more

You mean that even if you disable l3-forwarding for a specific vlan-interface it can still route traffic? That is the output from "show vlan all" says "disabled" regarding layer3 forwarding? To me disabling "l3-forwarding" is the same as running "no ip routing" in a cisco l3-switch. That is you can still ping this vlan-interface (if it has a mgmt-profile that allows ping attached to it) but if you send a packet to it with a dstip which isnt the ip of this vlaninterface then the packet should be dropped. ... View more

With some luck there should be some ssl related info in dp-log or the mp-log. Try with "less dp-log" or "less mp-log" followed by a press on the tab-key to see which files are available. Once located you can tail the file with: tail follow yes dp-log <filename> or tail follow yes mp-log <filename> (dp = dataplane, mp = managementplane) You can also use grep to search for strings withing these logfiles. ... View more

First of all I would try without the inbound inspection to verify that there isnt something else thats borked. Then I would verify that I have the inbound inspection properly setup including: Block sessions with unsupported version Block sessions with unsupported cipher suites Block sessions if resources not available Verify then in monitor -> logs -> traffic that when you visit using browser (from computer and not iPhone/Android) that the traffic is really decrypted (should be a checkbox in the "Decrypted" part to the right of the popup - you get the popup if you click on the magnify-icon to the left of the traffic log row). Then do the same for the visit from your iPhone/Android device and compare. Third I would take a tcpdump of the traffic which your iPhone and Android produces to look into which cipher suites are being requested and what is actually happening on the line (preferly compare this with the traffic generated when your browser from your computer (non iPhone/Android device) visits this https-site). For example PA has problems with newer versions of TLS (not supported at all) and the inbound inspection wont work at all if DH (Diffie Hellman) is being used for obvious reasons (both would the tcpdump help you with to find out). ... View more

According to IEEE you should use auto/auto if you want to go Gbit... "hardcoding" is only valid for speeds of 10 or 100Mbit/s. Verify what the ISP has put at their end... if they have 10 or 100Mbit link then its most likely that its "hardcoded" settings into 10 or 100Mbit and full duplex - in this case you should do the same on your PA. ... View more

Since the SSL is not decrypted the PA cannot investigate the HTTP GET command and as far as I know the PA never performs RDNS to verify servers (only CRL/OCSP checks of the cert is performed if you have this enabled). Which gives if you run this exclude-cert thingy then PA will look at the (I think it was) CN part of the cert and if that matches your exclude-list then the traffic will not be terminated/inspected. ... View more

Well that sounds like DNS tunneling to me, compared to this current vuln which according to pcaps seems to completely switch protocol without the PA device will notice. And speaking of which... still no official response from PA or even a fix for the current issue? 😞 Which is also mentioned on the blog which reported this: Bypassing application control, Having fun with Fortigate – Take 2 ... View more

Verify so the ip of mgmt interface is different on both boxes... ... View more

Check out these docs if they might have something interresting? ... View more

Context: http-req-header Qualifier: http-method Value: POST and yet it complains that there is no pattern... hmpf... so damn close 😞 Is there some kind of bogus wildcard one can use to make the GUI happy, like ******* (seven * in a row) or such? There is this example in the manual which is sort of what is needed, except that this signature (which this thread is needing) should trigger on ANY site (no matter if its ipv4, ipv6 or fqdn) and that this example is an appid instead of a vuln signature which would be a better choice: set application specifiedblog_posting category collaboration subcategory web-posting technology browser-based signature s1 and-condition a1 or-condition o1 operator pattern-match context http-req-host-header pattern specifiedblog.com qualifier http-method value POST ... View more

Actually there is a way (or several)... This might break stuff so you need to test it first with the most common urls you use but you can create a signature which force use of "Host:" in the http-request and in combination with this disallow "Host: <ipv4>" (dont forget ipv6 aswell). Something like (if I get the logic right :smileysilly:): http-request: host must exist AND not (host eq <ipv4> OR host eq <ipv6>) <ipv4> in this case would be a regexp (or such) that identifies *.*.*.* where the * is numbers 0-255. Another method would be to put a webproxy and do the filtering regarding ip-based requests in there. The best method I think is to simply disallow "unknown". This way you will also avoid new uncategorized malware-sites aswell. The drawback (as already mentioned) is that you need to setup a method so you can easily take complains from clients and add uncategorized sites to a whitelist (that is a client complain that they cannot reach a specific site - then you can manually allow this url until its being categorized (perhaps at the same time send a hint to PA to put this url into PANDB)). ... View more

Also when using two or more ISPs and multihoming is to use a dynamic routing protocol such as BGP on the external interface (either in PA or perhaps even better in the routers on the outside of the PA). ... View more