Technical FAQ

• Why Firewalls and IDS are not enough?
  The firewall was designed as a gateway to allow or deny access to network resources. The firewall makes its decisions based on what the user wants to connect to, not what their intent is. When you have a web server, the firewall must grant access to the web site to allow people on the Internet to be able to give Internet visitors access to the web site content. Therefore, when a hacker requests to access the web server, the firewall has essentially been designed to grant access to the hacker.
  
  A firewall does not have the capability to determine if the content on your web server is good content or bad content, it only sees it as content, regardless if you posted it or if a hacker posted it. Firewalls only look at connections, not at the intent of the users attempting to connect or at the content the users may bring into a network environment. As long as firewalls contain openings for users to access resources, a hacker will continually have a method of gaining access and altering web servers - including web site content.
  
  A firewall is not assigned the task of checking the integrity of web content that is served to the world. When a site is defaced, there is nothing a firewall can do to prevent the damage being visible to the outside world.
  
  An Intrusion Detection System detects harm caused to the site, but cannot do anything to prevent the damage being visible to the outside world. IDS works along with firewalls to notify the administrator of any aberrant events or changes caused to the site. IDS does not prevent any defaced page from being displayed to the user.
  
  
• What does WebGuard do and why it is necessary?
  WebGuard complements firewall security by adding a last line of defence against hacker sabotage of the corporate Web site, even if all other security systems fail. The WebGuard specializes in foiling Web site defacements, thus saving its users expensive downtime, public embarrassment, and legal complications. It automatically replaces defacements with copies of the proper data. Instead of checking whether the people accessing a Web server are the right people, the WebGuard checks whether the data exiting the Web server is the right data — the right text, numbers, pictures, etc.
  
  
• What WebGuard does not do?
  WebGuard does not stop anyone from coming into your site. It doesn't stop people making changes to files resident on your site. It doesn't stop particular protocol packets to enter or leave the site. It doesn't verify the authenticity of the user who accesses the web site. It does not encrypt the channel of communication between the server and user.
  
  
• How can I provide integrity to my web site? Do I need to do make any changes to the existing system?
  No. As WebGuard remains transparent to the WebServer, You don't need to make any changes to your existing system (site or web server). In order to build integrity for your existing system, We will provide you with integrity tool, which webmasters and other legitimate sources can use to securely publish web components.
  
  
• Does WebGuard care about the WebServer or Operating System it is protecting?
  No. WebGuard only protects the static web contents that are there in the WebServer. However, it is also possible to protect entire web server files by running the tripwire kind of integrity checker software. But it demands periodic audit of logging and baseline database information's.
  
  
• Why it's so difficult to protect dynamic components?
  In N-tier architecture, server will contact variety of sources (application server, database server, etc.) in order to get the job done and finally presents html formatted output into the client machine. Because of its diverged behavior it's difficult to protect.
  
  
• How long it will take to integrate WebGuard product into an existing network?
  WebGuard can be implemented in approximately one week. Very little of this time, though, actually requires time from an administrator on site. WebGuard is put onto the network, and requests are redirected to go through WebGuard using IP Tables rule at the Firewall. Once in place, webmasters and publishers can assign with legal roles and start associating WebGuard Headers for each of their web components. This process likewise takes 2 or 3 days and post installation tests will be carried out for 1 or 2 days. Finally, WebGuard will be fully activated in blocking mode to protect the site.
  
  
• How Scalable is WebGuard?
  WebGuard prototype setup consists of a 400 MHz Intel Celeron uniprocessor machine with 128 MB RAM, running RedHat GNU/Linux 7.3. This prototype easily scales up to load intensities of 100 page requests per minute.
  
  WebGuard, by itself, doesn't impose any constraints on total number concurrent connections established with web server. However for web sites that generate high volume traffic, WebGuard can be run in cluster mode with load balancing among different WebGuard instances.
  
  
• How much latency does WebGuard adds to the normal HTTP conversation?
  Again with the help of our prototype setup, we found that it typically adds less than 10ms to the HTTP conversation in the blocking mode.