Re: Combining rules

[Ian Moyce <ian@ianmoyce.co.uk>]

Grant Taylor wrote:
> On 06/07/07 04:18, Ian Moyce wrote:
>> I am trying to combine a load of ip rules, but I am having problems 
>> fathoming it out.
>>
>> I run a VPS with openVPN. I have the following rules:
>>
>> iptables -t nat -A POSTROUTING -s 192.168.2.3 -j SNAT --to 
>> 85.234.144.236
>> iptables -t nat -A POSTROUTING -s 192.168.2.4 -j SNAT --to 
>> 85.234.144.236
>> iptables -t nat -A POSTROUTING -s 192.168.2.5 -j SNAT --to 
>> 85.234.144.236
>> iptables -t nat -A POSTROUTING -s 192.168.2.6 -j SNAT --to 
>> 85.234.144.236
>> iptables -t nat -A POSTROUTING -s 192.168.2.7 -j SNAT --to 
>> 85.234.144.236
>> iptables -t nat -A POSTROUTING -s 192.168.2.8 -j SNAT --to 
>> 85.234.144.236
>> iptables -t nat -A POSTROUTING -s 192.168.2.9 -j SNAT --to 
>> 85.234.144.236
>> iptables -t nat -A POSTROUTING -s 192.168.2.10 -j SNAT --to 
>> 85.234.144.236
>
> I'm not sure why you would be wanting to SNAT 8 systems to the same 
> IP, but hey, it's your script.  The rules them selves look good enough.

I was just following instructions! Jan gave me a shorter list of 
commands which I hope to try
>
>> Which works great. However, I am wanting to pass any IP traffic from 
>> the 192.168.2.x range to be passed through a socks proxy on a 
>> specific port, which I have been told can work with:
>
> (Comments in line below)
>
>> #!/bin/sh
>>
>> LOCAL_NET=192.168.2.0/24
>> /sbin/iptables -F
>> /sbin/iptables -t nat -F
>> /sbin/iptables -P INPUT ACCEPT
>> /sbin/iptables -P FORWARD DROP
>> /sbin/iptables -P OUTPUT DROP
>
> A default of DROP in the OUTPUT can catch you on a LOT of things.
>
>> /sbin/iptables -t nat -P OUTPUT ACCEPT
>> /sbin/iptables -t nat -A OUTPUT -p udp --dport 53 -j DNAT 
>> --to-destination 127.0.0.1:5353
>> /sbin/iptables -t nat -A OUTPUT -o lo -j RETURN
>> /sbin/iptables -t nat -A OUTPUT -d 127.0.0.1 -j RETURN
>> /sbin/iptables -t nat -A OUTPUT -d $LOCAL_NET -j RETURN
>> /sbin/iptables -t nat -A OUTPUT -m owner --uid-owner 103 -j RETURN
>> /sbin/iptables -t nat -A OUTPUT -p tcp --syn -j DNAT --to-destination 
>> 127.0.0.1:1211
>
> So you are wanting to block all outbound traffic except for the 
> following conditions:
> - Loop back traffic
> - Local host network traffic
> - Local network traffic
> - Any thing sent by uid 103
>
> Is this really what you are wanting to do?
I think so...

The server itself runs exim, dovecot and apache2. I would like these 
services to work, so if someone went to my domain name, or sent me an 
email, that'd work.

I am wanting any of the VPN users who are on the local IP range - 
192.168.2.x to have all their traffic go through Tor's SOCKS server. 
Following the instructions at 
http://wiki.noreply.org/noreply/TheOnionRouter/TransocksifyingTor, I am 
using a magical program (all but black magic to me) to convert generic 
TCP network traffic redirected by iptables into a socks compatible 
request which it then passes to tor, so localhost/127.0.0.1 traffic 
needs to be outside of these rules.
The second set of queries is something directly from the site. I hate to 
admit it, but I am weak at iptables, which is why I am on my knees 
asking for help.
> Loop back and local host network are really about the same unless you 
> have other subnets bound to your loop back interface or for some 
> strange reason the 127.0.0.0/8 subnet bound to something other than 
> loop back.
*looks blank*
> It looks like you are using a local DNS (proxy?) server and 
> redirecting any DNS queries to it.
Thats correct
>
> Then there is the main critter where you are redirecting any new TCP 
> traffic to a service on the local host.  I'm not quite sure what will 
> happen to the destination IP and port of the request traffic.  I'm 
> afraid that they will be translated to be the local host and port you 
> are DNATing to, not the original destination.  If the original 
> destination is lost, how is your proxy going to work?  I guess I 
> should as, are you trying to transparent proxy or are you really 
> telling your client systems that they are using a proxy?
I am wanting it to work transparently. I guess I could survive if I 
block all outbound traffic from the 192.168.2.x IP addresses from going 
outside the server - so clients have no option but to use the socks 
server. It sounds easier, but there is the IBKAC factor, and I want to 
make it as easy as possible.
>> /sbin/iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
>> /sbin/iptables -A OUTPUT -o lo -j ACCEPT
>> /sbin/iptables -A OUTPUT -d 127.0.0.1 -j ACCEPT
>> /sbin/iptables -A OUTPUT -d $LOCAL_NET -j ACCEPT
>> /sbin/iptables -A OUTPUT -m owner --uid-owner 103 -j ACCEPT
>> /sbin/iptables -A OUTPUT -j LOG
>> /sbin/iptables -A OUTPUT -j REJECT 
>
> Again, you are wanting to block all outbound traffic except for the 
> following conditions:
> - Loop back traffic
> - Local host network traffic
> - Local network traffic
> - Any thing sent by uid 103
Not sure, sorry, I hope my previous responses cover this.. UID 103 is 
the SOCKS server, so the traffic from this uid does not need to go 
through itself. That would be a bit wrong..
>
> Any thing that is not allowed out is logged and rejected.
>
> The state rule is the normal short cut to by pass the rules for 
> previously seen traffic.
>
> As an aside:  Why are you filtering in your nat table?  Filtering 
> really is better done in the filter table.
Havent a clue. I was just doing what I was told!

>
>> If someone is able to help me figure this out, I am offering a reward 
>> of £50 (about $100) as it is driving me insane!!!
>
> I don't see any thing to out standing other than the fact, which may 
> be my unfamiliarity with Socks, that any traffic not explicitly 
> allowed TCP traffic is being redirected in to one port on the system.  
> I'm not sure that this will work.  However like I have said, I do not 
> use Socks so I am not familiar with it.  To me, when you are DNATing 
> to the local port, you are going to loose your destination IP and 
> port.  Thus, how will your service know where to send the traffic to 
> unless there is some sort of indicator in what is coming in to the 
> service.  If there is data coming in to the service telling it where 
> to connect to, then you have obviously configured the clients to talk 
> to the service.  If you have configured the client to talk to the 
> service, why are you having to redirect the traffic?  Why did you not 
> configure the client to talk directly to the correct port of the service?
I am just wanting to make this as simple as possible for the end user- 
they connect with OpenVPN, get a 192.168.2.x IP address, and all their 
network traffic going out of the network goes through tor. I am leaning 
towards blocking all but traffic to 192.168.2.x addresses, which forces 
them to use SOCKS, however I am wanting to cover all the bases for 
things like SSH and other TCP programs which dont have any obvious SOCKS 
support without having to have some kind of wrapper.
>
> It almost sounds like you are wanting to do transparent proxy with 
> Squid.  Squid is an entirely different prosy than Socks.  Socks (to my 
> knowledge) is a system for a client to request that an intermediary 
> (bastion) host make the connection on the client's behalf.  With 
> Socks, the client passes information on where it wants to connect to 
> the Socks proxy.
> Squid transparent proxy on the other hand is entirely different.  
> Squid is primarily used to proxy HTTP / HTTPS requests on behalf of 
> clients.  Part of the HTTP protocol is the information that you are 
> trying to request.  I.e. you pass what host (name) and item that you 
> want.  Squid can interpret these requests and make the appropriate 
> connection on your behalf.  Or, you can do the standard thing and 
> configure Squid as a standard proxy and just point the clients to it 
> and it will behave more like a Socks proxy where the client tells 
> Squid what it wants and Squid then goes and gets it.
>
> Incidentally, setting Squid up as a transparent proxy and redirecting 
> any and all HTTP traffic in to it is not difficult and can be done in 
> a very similar manner (as far as the redirects on the router).

Agreed. I though of this, but I was hoping to cover more than HTTP/S 
traffic. However, I am seriously considering doing this in the 
meantime... Are you able to point me in the right direction on what I 
need to do to transparently handle all http/https traffic to go to 
squid..? Sorry if I am being cheeky!
>
> Digest this and let me know if you have any more questions.
>
>
Thanks grant for your reply.. I am pretty new to netfilter, and I think 
I may have bitten off more than I can chew..
>
> Grant. . . .
>