Hi forum,

I know that many single features are possible with RouterOS, but what is about a merger, if I like to realize the following:

1.

I like to setup some specific firewall rules, for example if a webserver on port 80 is requested, this starting flow should be sorted into a queue and wait.

2.

Because this flow was put into the waiting queue, a script should trigger an action, which means, a "script" sends the complete paket (or maybe only http header) to an external host.

3.

The external host examines the paket, decides about an permit/deny and put the flow from the waiting queue into the forwarding/output queue or install a blocking rule or delete the paket.

I know many thinks are actual possible (scripting, API, waiting queue) but combing this three steps seems impossible now. The hole idea is to decide about the forwarding of a paket through an external XACML policy. At the moment this is for an research project at university, so please do not discuss about the pros or cons.

Maybe someone can give me other hints to opensource projects which already able to do that? OpenFlow doen't seems to be an option, because you don't get the hole paket per default, only some limited parameters. Which would be okay for an first approach, but not satisfying. Maybe squid is useable, but we are also interessted on layer 3 and 4.

Thanks!!!

It sounds like what you're after is a transparent proxy.

The easiest way to do that is via a simple firewall dst-nat rule. Have it match all IPs of web sites you want to process, and redirect traffic to a different web server that you control. Once there, you can use whatever language you have there (PHP, ASP.NET, etc.) to inspect the HTTP request - the same HTTP request that was originally meant for the 3rd party web server - and act accordingly. You can even alter whatever the original web server sends as response by simply forwarding the complete HTTP request, and then capture and alter the original server's response.

Side note: This doesn't work with HTTPS pages, as this is exactly what's known as "man in the middle attack" - your custom script is in a position to inspect and potentially keep sensitive information, if you choose to do so.

Year, it seems to be a transparent proxy, but I like to handle also iso/osi layer 3 and 4, which means checking the ip addresses and maybe the syn bits.

The clue is: I don't want to alter the destination websites. Our dynamic filter and access control have to work transparently in the middle, like any other router/linux box who does routing. Cisco is doing something like that with the ACEs.

RouterOS itself can inspect and alter pretty much everything from an layers 3 and 4 via filter, mangle and NAT rules. If the rules need to be "dynamic", you can use scripting and/or API to alter those rules when certain conditions are met.

The only thing you can't alter is the actual (layer 7) content - for that, you'd need a transparent proxy. You can use a combination of such firewall rules to first inspect layers 3 and 4, and pass them to a transparent proxy only if you need to.

The clue is: I don't want to alter the destination website

Right. That's what the "transparent" in "transparent proxy" means - the user can't detect that they're using a different web server than the original. They send a request to the original IP, and they see a reply from the original IP. Their device doesn't know that the reply actually comes from your web server, pretending to have the original server's IP.