Firewall rule tutorial example 4:

"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 our own internal web server (192.168.10.31).

Firewall path. See steps below for description.

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 ET1 (inside) interface. That ruleset already contains a saddr == 192.168.0.1/24 accept rule allowing the packet through.

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

daddr == www.yourcompany.com modify static daddr 192.168.30.31

This needs some explanation.

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

modify static daddr 192.168.30.31 results in modifying the destination address in the packet to 192.168.30.31, an address on the ET4 subnet. The router will forward the packet to ET4.

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

5. The packet is thus sent out on the ET4 interface to port 80 of the 192.168.30.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 ET4 interface.

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

saddr == 192.168.30.1/24 accept

8. The incoming user rules of the ET4 interface also allow the packet through, as it goes to the 192.168.0.x subnet:

daddr == 192.168.50.1/24 || daddr == 192.168.0.1/24 accept

9. The router sends the packet to ET1 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 ET1 are ignored, as the return packet matches the return flow.

11. The outgoing super rules of ET1 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!

Entering the rule

You enter the rule of step 2 above into the “Additional rules” fields of the security profile page:

ET1 Incoming user post daddr == www.yourcompany.com modify static daddr 192.168.10.31

All other necessary rules are already present in the standard firewall ruleset.

1) Please notice that it is resolved only once, at the time firewall rules are loaded. It is not resolved for each packet received! Also, if the URL resolves to several IP addresses only one of them will be used!
firewall/example_4.txt · Last modified: 2010/11/04 14:00 by tibor
CC Attribution-Noncommercial-Share Alike 3.0 Unported
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0