Linux Netfilter discussions
 help / color / mirror / Atom feed
* Combining rules
@ 2007-06-07  9:18 Ian Moyce
  2007-06-07 16:22 ` Grant Taylor
  0 siblings, 1 reply; 3+ messages in thread
From: Ian Moyce @ 2007-06-07  9:18 UTC (permalink / raw)
  To: netfilter

Hello,

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

Which works great. However, I am wanting to pass any IP traffic from  
the 192.168.2.x range be passed through a socks proxy on a specific  
port, which I have been told can work with:

#!/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
/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
/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


If someone is able to help me figure this out, I am offerring a  
reward of £50 (about $100) as it is driving me insane!!!

Thanks

Andy Dixon

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Combining rules
  2007-06-07  9:18 Combining rules Ian Moyce
@ 2007-06-07 16:22 ` Grant Taylor
  2007-06-07 17:36   ` Ian Moyce
  0 siblings, 1 reply; 3+ messages in thread
From: Grant Taylor @ 2007-06-07 16:22 UTC (permalink / raw)
  To: Mail List - Netfilter

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.

> 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?

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.

It looks like you are using a local DNS (proxy?) server and redirecting any DNS queries to it.

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?

> /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

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.

> 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?

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).

Digest this and let me know if you have any more questions.



Grant. . . .


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Combining rules
  2007-06-07 16:22 ` Grant Taylor
@ 2007-06-07 17:36   ` Ian Moyce
  0 siblings, 0 replies; 3+ messages in thread
From: Ian Moyce @ 2007-06-07 17:36 UTC (permalink / raw)
  To: gtaylor+reply; +Cc: Mail List - Netfilter

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. . . .
>



^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2007-06-07 17:36 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-06-07  9:18 Combining rules Ian Moyce
2007-06-07 16:22 ` Grant Taylor
2007-06-07 17:36   ` Ian Moyce

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox