Where does a WAF fit in the data path?

Proxy-based web application firewalls (WAFs) are an integral component of application protection. In addition to being a requirement for complying with PCI-DSS, WAFs are excellent at protecting against the OWASP Top 10. They’re also a go-to solution for addressing zero-day vulnerabilities either through rapid release of signature updates or, in some cases, the use of programmatic functions to virtually patch applications while a long term solution is being deployed.

The question is, where do you put such protection?

There are options, of course. The data path contains multiple insertion points at which a WAF can be deployed. But that doesn’t mean every insertion point is a good idea. Some are less efficient than others, some introduce unacceptable points of failure, and others introduce architectural debt that incurs heavy interest penalties over time.

Ideally, you’ll deploy a WAF behind your load balancing tier. This optimizes for utilization, performance, and reliability while providing the protection necessary for all apps – but particularly for those exposed on the Internet.

Utilization

The resource requirements (CPU and the like) involved in making a load balancing decision are minimal. This is generally why a LB is able to simultaneously support millions of users, and WAFs require more utilization – because they're inspecting the entire payload and evaluating it against signatures and policies to determine whether the request is valid and safe.

Modern data center models borrow heavily from cloud and its usage based cost structure. Utilization becomes a key factor in operational costs. Higher utilization leads to additional resource requirements, which consumes budgets. Optimizing for utilization is therefore a sound strategy for constraining costs in both the data center and in public cloud environments.

Reliability

It is common practice to scale WAFs horizontally. That is, you use the LB to scale WAFs. This architectural decision is directly related to utilization. While many WAFs scale well, they can still be overwhelmed by flash traffic or attacks. If the WAF is positioned in front of the LB, you either need another LB tier to separately scale it or you risk impacting performance and availability.

Alternative Placement: WAF in front of One Load Balancing Tier...and behind Another

Performance

Performance is a key concern in an application economy. With so many variables and systems interacting with data as it traverses the data path, it can be frustrating to nail down exactly where performance is being bogged down let alone to tune each one without impacting others. As has been noted many times before, as load on a system increases, performance decreases. This is one of the unintended consequences of not optimizing for utilization, and a key reason why seasoned network architects use a 60% utilization threshold on network devices.

Deploying a WAF behind the LB tier eliminates the need for an upstream designated WAF load balancing tier, which removes an entire layer of network from the equation. While the processing time eliminated may not seem like much, those precious microseconds spent managing connections and scaling WAF services and then doing it again to choose a target app instance/server matters. Eliminating this tier by deploying the WAF behind the LB tier gives back precious microseconds that today’s users will not only notice, but appreciate.

Visibility

Visibility is a key requirement for security solutions in the data path. Without the ability to inspect the entire flow – including the payload – much of the security functions of a WAF are rendered moot. After all, most malicious code is found in the payload, not in protocol headers. Positioning a WAF behind the LB tier enables decryption of SSL/TLS before traffic is passed on to the WAF for inspection. This is a more desirable architecture because it is likely the load balancer will need visibility into secured traffic anyway, to determine how to properly route requests.

Recommended Configuration: Decryption and Inspection for added Security

All that said, a WAF fits in the data path pretty much anywhere you want it to. It’s an L7 proxy-based security service deployed as an intermediary in the network path. It could ostensibly sit at the edge of the network, if you wanted it to. But if you want to optimize your architecture for performance, reliability, and utilization at the same time, then your best bet is to position that WAF behind the load balancing tier, closer to the application it is protecting.

Source: F5.com

What Makes a WAF Advanced?

As the threat landscape evolves, so must our security controls and countermeasures. The most advanced perimeter threats for data loss or exfiltration occur at the application layer, rendering most next-gen firewalls (NGFW) and intrusion prevention systems (IPS) much less effective. This effect is compounded by the fact that most communications are moving to encrypted data channels not well-supported by NGFW or IPS, particularly at scale. Web application firewalls (WAF) are specifically designed to analyze each HTTP request at the application layer, with full decryption for SSL/TLS.

In recent years, most WAF technologies have remained largely unchanged, as passive filter-based detection systems, much like the related NGFW and IPS technologies. WAF systems apply protocol compliance (ensuring a well-formed request) and signature comparisons (ensuring no known malicious content) to filter and block potential attacks. Additional features have been added to enable session- and user-awareness to fight hijacking and brute force attacks, and IP reputation feeds are applied to attempt to filter out known-bad sources such as botnets, anonymizers, and other threats. These are still largely passive technologies at the data center perimeter, with very limited capacity for interrogating the client.

 There are a few things we know about the current threat landscape:

• Most threats are automated in nature. Attackers automate scans for vulnerabilities. They automate resource hoarding such as purchases of tickets or 
• sneakers for grey-market resale. Distributed denial-of-service (DDoS) attacks are fully-automated to enable the kind of 1Tbps+ attack traffic volume that has become commonplace. Automation is difficult to detect because it is often designed to mimic good traffic and go undetected. Technologies like CAPTCHA have been used to detect such automation, but these verification methods prove ineffective over time and impact the experience of legitimate users.
   
• Credential stuffing is a specific kind of automated attack which leverages the billions of known username and password combinations from prior breaches. Use of stolen credentials was the most prevalent type of application attack of 2017, according to recent threat reports. These attacks prey upon password re-use common for the average citizen of the Internet. Credential stuffing is particularly difficult to detect because these requests not only look normal, they are often “low and slow” by design to avoid detection as a brute force attack.
• Malware is pervasive and is used to exploit weaknesses in browsers and the users operating those browsers. Malware has many delivery methods, from email attachments to malicious links on social media and in ads. These compromised machines are used to attack other websites for DDoS, data theft, and resource hoarding. Limited detection and mitigation methods are available unless the client machine is managed by an experienced IT infosec team.
   
• DDoS attacks are not just volumetric in nature. Many attacks are designed to cause resource exhaustion somewhere in the application stack, the application servers, middleware, or back-end database. Detecting these conditions can be difficult since the traffic conforms to most standard input validation checks.

Simply put, these attacks bypass virtually all traditional WAF detection mechanisms since they often do not appear malformed in any way. IP address reputation feeds are of limited effectiveness due to the almost inexhaustible supply of easily compromised targets,
including cable modems, IoT devices, public cloud server instances, and more. Source address information changes too rapidly for even a crowd-sourced feed to be very effective in combatting the level of automation typical of these attack vectors. A more advanced web application firewall is clearly needed to fight these threats.
The good news is that Advanced WAF technology is already available and has been for some time. F5 pioneered technology for CAPTCHA-free detection of bots attempting to scrape price data from online retailers nearly a decade ago, when Web Scraping protection was introduced in 2009. F5 has progressively advanced that technology and expanded it into what is now known as Proactive Bot Defense, introduced in 2015. Proactive Bot Defense (PBD) enables interrogation of the requesting client to verify that a human user with a legitimate browser is present. This is a far more effective solution than relying on 
blocking known botnets by IP address.
With the new F5 Advanced WAF offering, F5 is expanding on their market-leading WAF technology to include capabilities necessary to combat the evolving threats seen in the application security landscape. Advanced WAF includes:
• Proactive Bot Defense. By utilizing cutting edge fingerprinting and challenge/response techniques in conjunction with other behavioral analysis, PBD enables session-level detection and blocking of automated threats.
   
• Layer 7 Behavioral DoS detection and defense. The Advanced WAF is able to dynamically profile traffic and create signatures of anomalous traffic patterns, stopping layer 7 DoS attacks before they impact your application.
   
• DataSafe credential protection. DataSafe dynamically encrypts page content to prevent man-in-the-browser attacks usually caused by malware. DataSafe also dynamically encrypts credentials as 
• they are entered to protect the user at the browser.
   
• Anti-Bot Mobile SDK integration. The techniques used by Proactive Bot Defense work to identify legitimate browsers. For mobile apps, a browser is not present. The Anti-Bot Mobile SDK enables organizations to fight bots with advanced techniques even on mobile API endpoints.

The F5 Advanced WAF is a dedicated security platform to deliver the most advanced application security capabilities available on the market today. F5 is committed to providing cutting edge application security solutions to mitigate even the most sophisticated attacks. 
Source:F5.com

Introduction of WAF

WAF is abbreviation for Web Application Firewall. A Web Application Firewall (WAF) is a network security firewall solution that protects web applications from HTTP and web application-based security vulnerabilities.Let’s understand the need for WAF –

Inspite of networks deployed with proxies, IPS/IDS devices including network firewalls in their network to prevent attacks, web applications are still vulnerable to other attacks.Some of the most common types of attacks which are targeted at web servers (Web Applications) include –

• SQL injection attacks
• cross-site scripting (XSS) attacks
• DDoS attacks.

WAF devices are widely used to protect websites, E-commerce, mobile apps and other online applications. A WAF is deployed between application servers and network edge routers and firewalls. A WAF filters, monitors, and blocks HTTP/HTTPS traffic to and from a web application to protect against attack to compromise the system data. WAF solutions also become more important especially in financial customers they can also help your organization comply with PCI-DSS and HIPAA regulations.

Some of WAF Appliances preferred across globe are –

• Imperva SecureSphere
• Barracuda Web Application Firewall
• Citrix Netscaler Application Firewall
• Fortinet FortiWeb
• F5 BIG-IP Application Security Manager (ASM)

Source:ipwithease.com

WAF vs IPS vs NGFW

Can you please let me know what are the deployment types in F5?
Ans:--

Routed mode
In route mode, the BIG-IP ASM system is in the routing path of the web servers, and all traffic to the server flows through the system.

• Servers detect the actual client IP address in the IP header for security and logging purposes. Since all communication traverses the BIG-IP system, there are no alternate, unprotected routes to the protected applications.
• The BIG-IP system must be configured to allow administrative and non-application traffic.
• Response traffic must be routed through the BIG-IP system. You usually accomplish this by setting the default gateway of the web server to the floating self-IP of the BIG-IP system.
One-armed mode
In one-armed mode, only application traffic flows through the BIG-IP ASM system, and the server-side connection uses a SNAT. The BIG-IP ASM appliance is logically in line with the web application traffic flow, but not physically in line with all traffic to and from the web servers.
Note: Requests and responses must go through the BIG-IP system. This means that if you do not use NAT on the source IP address of the client, the default gateway of the server needs to be the BIG-IP system. If you do use SNAT for all traffic from the client to an IP address of the BIG-IP system, all responses are sent back to the IP. To keep track of the original client IP address, you can enable the X-Forwarded-For feature of the HTTP profile. This adds the client IP address to the HTTP header that was sent to the web server.


• No changes to routing are required on the servers.
• Only application traffic is sent through the BIG-IP system, which reduces traffic traversing the device.
• Servers detect the IP address of the BIG-IP system in the TCP/IP header, which may complicate logging.
• There is more than one path to the protected application. You need additional security controls such as firewalls to ensure that malicious users do not access the application.

GTM

Informal poll: If your organization uses the F5 GTM or BigIP DNS, is it your entire DNS infrastructure or do you only use it where it is needed for intelligent DNS resolution?

Ans:--
It can be Authoritative DNS for both. However in many Enterprises GTM being name server mostly for Web Applications and Infrastructure DNS for Physical Devices set on infoblox etc. 

Big-ip hardware

Linux

Command	Description
1	top	used to get cpu  information,memory info,process id,user who is running the process(user),what command is running.
2	df -h	used to check whether any mount point id 100% in disk space utilization.
3	du	if in the df -h command,any mount point is full. then by using du cmd delete large unwanted file.
4	dmesg	Anything that is related to hardware issue can be found here. ex: issue with memory.       issue with memory leak       issue with mother board.       issue with CPU crash.
5	iostat stands for I/o statistics	Gives read/write speed of each disk cmd: iostat 1          will refresh for every  second and display the output of iostat in the                       same putty terminal session.
6	netstat -rnv netstat | more	print network connections,routing tables,interface statistics,masquerade connections and multicast memberships.
7	free	It is used to check physical memory and virtual memory. output of free command looks like: $free                   total          used        free     shared    buff/cache    available Mem :    1016232     640252    79500   5152      296480          195024 Swap:     1048572    2724       1045848 Here: Mem - physical memory Swap - Virtual memory.
8	cat /proc/cpuinfo	To check all the CPU information of the system
9	cat /proc/meminfo	To check all the memory information of the system