"Hijacking" a site

This description is addressed to advanced users only.
Incorrect editing of the firewall rules may cause security risks!

As you can see by examples 2 and 3, it is usually the outside interface that handles the flows. But all interfaces are capable of creating flows.

It is however very seldom you need to create any flows on any other interfaces than the outside one. But there are certain special cases that demand use of flows on inside interfaces.

In this example we will redirect all www.yourcompany.com web accesses to your own internal web server (192.168.10.31).

1. The web access will come as a TCP packet from your PC (192.168.0.31) going to port 80 of IP Address 80.244.64.10 (the IP address www.yourcompany.com resolves to). The packet arrives to the incoming super rules of the ET2 (inside) interface. That ruleset already contains a saddr == 192.168.0.1/255.255.255.0 accept rule allowing the packet through.

2. The next stop for the packet will be the incoming user rules of the ET2 (inside) interface. Here we do the actual “hijack”:

daddr == www.yourcompany.com modify static daddr 192.168.10.31 This needs some explanation.

daddr == www.yourcompany.com is resolved to daddr == 80.244.64.10 when the security profile becomes activated.

modify static daddr 192.168.10.31 results in modifying the destination address in the packet to 192.168.10.31.

4. The outgoing user and super rules of the USB interface are both proto != noproto accept thus they allow the packet through.

5. The packet is thus sent out on the USB interface to port 80 of the 192.168.10.31 PC connected to it. If you run a web server on that PC, that web server will answer instead of www.yourcompany.com!

6. The answer will be addressed back to 192.168.0.31, and sent to the USB interface.

7. The incoming super rules of the USB interface allow the return packet through, as it comes from the 192.168.10.x subnet.

saddr == 192.168.10.1/255.255.255.0 accept 8. The incoming user rules of the USB interface also allow the packet through, as it goes to the 192.168.0.x subnet:

daddr == 192.168.20.1/255.255.255.0 || daddr == 192.168.0.1/255.255.255.0 accept 9. The router sends the packet to ET2 as it is that interface that handles the 192.168.0.x subnet.

10. As we have created a flow and a return flow in step 2 above, the outgoing user rules of ET2 are ignored, as the return packet matches the return flow.

11. The outgoing super rules of ET2 allow all packets through.

Now all data flows headed to www.yourcompany.com are “hijacked” and redirected to your internal server, without your web browser noticing anything. An otherwise impossible task to configure is very easily done by manually adding one simple rule to the right ruleset!