About sunilsadanandan

That is a good document , I think this part answers my question , from below we should read packets per second as new connections per second , i.e. if the servers you are protecting can handle the 50000 new connections per second and is protected by a 3050 , you would not need a Syn flood protection using RED to be below the 50000 capable by the 3050. Maybe slightly lesser , but not significantly lesser ? The case is different for Syn cookies as they are more precise on what they drop, i.e. they just drop sessions from clients that do not respond to SYN cookies , most likely spoofed ones. "That means that the packets-per-second metric actually stands for new attempted sessions-per-second. For example in the case of SYN floods, 10,000 pps means 10,000 new SYNs per second. The reason we mention this as pps and not cps (connections per second) is because the session has not been created in the session table yet. It is a half connection" ... View more

Hi Mikand, Thanks for the response. That is a good summary of the issue at hand and details of the various responses. My question was specifically regarding why a decision has been made to ignore source IP and port number while deciding which connection would be cached. If you look at the video by checkpoint you will see that the batch file used to generate the SIP traffic would have run as a different process from the Facebook session running off the Webbrowser , which should have come from a different source port number. I.e. I didnt have to know anything about the running sessions or figure out a source port number to spoof, and if source IP is not being considered for caching then that would mean the poisoning affected every IP behind the firewall talking to the same Dst IP/Port number ? Which (if correct) for me seems like a very serious architectural flaw (I do not know if my reasoning is correct or not , that is why I am looking for comment from someone who might know better). This means from an APPID perspective if there were different sub apps , like facebook chat , mail , or any other app embeded on that Dst IP/Port combination , it would have been poisoned also ? The other aspect is the APP ID engine itself being tricked to think that it was a SIP session with just one packet. I would have expected it to have have more rigorous checks before marking the app to be SIP. I do understand that this might not be possible in certain apps. ... View more

Thanks Ameya. Exactly what I was looking for. -Sunil ... View more

Hi, How uptodate is this document ? Is this proceedure applicable to 4.1 also ? Regards, Sunil ... View more

This is very interesting , could someone from Palo comment on this post ?  There is setting "set application cache no". I am not sure that the default setting is. I would expect application cache to be disabled after running this command and should cause it to identify the application shift. But I has assumed Palo did not do Apllication caching by default and would detect Application shifts by default. The other aspect about this video that concerns me is DNS over a random port being detected as unknown-UDP. I have just set application cache to "no" on my firewall and going to check the what kind of performance or cpu load on the dataplane is seen. ... View more

Hi mmxong, You could consider having  two interfaces configured to be part of a virtual wire , with one end connected to the Internet Vlan and the other end connected to your video conferencing system (which has an external IP). Or you could just have two interfaces in L2 with one plugged into your Internet VLAN and the other termimating on the Video conferencing system. Both configurations should let you control the traffic through security policies. Hope that helps, Regards, Sunil ... View more

Hi , Just checked again , its been under 15 mintues sisnce I activated it. There are loads of files showing up on my wildfire portal. Regards, Sunil ... View more