[Firewall] DMZ-IP

Lonnie Abelbeck lists at lonnie.abelbeck.com
Mon Jan 19 16:24:24 CET 2009


Arno,

I think I have convinced myself that NAT_FORWARD will work to forward,  
otherwise denied traffic, to a local DMZ-IP address.

The problem is the NAT_FORWARD variable constantly needs to be  
adjusted when OPEN_, HOST_OPEN_ or other NAT_FORWARD_'s are changed.   
This now becomes a maintenance issue.

The idea is to have a single variable, possibly:

FORWARD_DENIED="ip.add.re.ss"

1) One solution is to add the iptables DNAT/ACCEPT commands for all  
udp/tcp ports (1:65535) to FORWARD_DENIED, in the appropriate chain  
such that any OPEN_, HOST_OPEN_ or other NAT_FORWARD_'s have already  
matched, thereby only match the remainder.

I don't know what chain that would be.


2)  A different approach would be to create a script (plugin) that  
calculates what are the "$remainder" ports to forward to  
FORWARD_DENIED that are not otherwise handled on the inbound EXTIF,  
and then automatically calculate the NAT_FORWARD...

Input: $HOST_OPEN_TCP, $OPEN_TCP, $NAT_FORWARD_TCP

Output: NAT_FORWARD_TCP="$NAT_FORWARD_TCP  $remainder>$FORWARD_DENIED"

and for UDP as well.

This approach may be more difficult than it looks using shell script.

Lonnie

On Jan 19, 2009, at 6:28 AM, Arno van Amersfoort wrote:

> Yep, but you can limit the hosts the NAT rules should match for by  
> adding it in front of the port number.... Please check the manual/ 
> config comment on this. This will probably give you what you  
> want.... If it doesn't we should probably create a plugin for  
> this.....
>
> a.
>
> Lonnie Abelbeck wrote:
>> The HOST_OPEN_TCP in my example allows a HTTPS connection to the  
>> box running the arno firewall, via the external interface.
>>
>> --- snip ---
>> Chain EXT_INPUT_CHAIN
>> pkts bytes target prot opt in out source destination
>> 1 64 ACCEPT tcp -- + * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443
>> --- snip ---
>>
>> NAT_FORWARD_TCP="25>192.168.1.5,1:65535>192.168.1.2"
>>
>> supersedes the
>>
>> HOST_OPEN_TCP="0/0~443"
>>
>> So the HTTPS connection no longer works.
>>
>> Lonnie
>>
>>
>> On Jan 15, 2009, at 4:44 AM, Arno van Amersfoort wrote:
>>
>>> I don't reallt understand this HOST_OPEN_TCP thing you're  
>>> referring too. Ignoring this and using the previous example it  
>>> could be as simple as:
>>>
>>> NAT_FORWARD_TCP="25>192.168.1.5,1:65535>192.168.1.2"
>>>
>>> a.
>>>
>>> Philip A. Prindeville wrote:
>>>> I don't think you would use HOST_OPEN_XXX, because the firewall  
>>>> would be operating in "bridge" mode (of sorts) in this case.
>>>> It would have an internal IP address on the NAT subnet, and it  
>>>> would "pluck out" the traffic coming in on the public address to  
>>>> the reserved ports, and pass the rest in to either the "default  
>>>> target" host if a new or stateless flow, or else to the other  
>>>> side of the NAT association on an established flow.
>>>> That is, the externally visible IP address wouldn't correspond to  
>>>> an interface on any given machine... not the "default target" (of  
>>>> course), and not on the firewall either.
>>>> -Philip
>>>> Lonnie Abelbeck wrote:
>>>>> Arno,
>>>>>
>>>>> Can you give a simple example how a plugin would handle the  
>>>>> ordering in this case?
>>>>>
>>>>> Given...
>>>>> # Local box
>>>>> HOST_OPEN_TCP="0/0~443"
>>>>>
>>>>> # LAN host
>>>>> NAT_FORWARD_TCP="25>192.168.1.5"
>>>>>
>>>>> Then the plugin would...
>>>>> Forward everything else to 192.168.1.2 instead of being dropped.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Lonnie
>>>>>
>>>>>
>>>>> On Jan 14, 2009, at 12:50 PM, Arno van Amersfoort wrote:
>>>>>
>>>>>> First of all: you can implement about *anything* with plugins.  
>>>>>> They are loaded before *almost* everything in the main script.  
>>>>>> I even implemented these POST_xxx-chains for allow plugins to  
>>>>>> add stuff *after* the main script has loaded its rules. If  
>>>>>> there isn't something that can't be done with plugins, contact  
>>>>>> me and I'll take care of it in the main script.
>>>>>>
>>>>>> About the DMZ-idea: it is indeed interesting. I see 2 possible  
>>>>>> options:
>>>>>> - Use the NAT_FORWARD_xxx variables, as already suggested,  
>>>>>> though quick 'n dirty;
>>>>>> - Write a plugin which nicely implements this.
>>>>>>
>>>>>> a.
>>>>>>
>>>>>> Lonnie Abelbeck wrote:
>>>>>>> On Jan 14, 2009, at 11:48 AM, Darrick Hartman wrote:
>>>>>>>> I'm trying to figure out a way to implement the following  
>>>>>>>> 'feature'. I don't think it's possible as a plugin because it  
>>>>>>>> would likely need to be applied before many of the rules in  
>>>>>>>> the main script.
>>>>>>>>
>>>>>>>> The feature follows:
>>>>>>>>
>>>>>>>> Many firewall 'appliances' allow a so-called DMZ where all  
>>>>>>>> unassigned inbound traffic is directed to a specific IP  
>>>>>>>> address on the lan. I need to duplicate this behavior and  
>>>>>>>> hope we can find a way to do this cleanly with the Arno's  
>>>>>>>> script.
>>>>>>>>
>>>>>>>> So as an example:
>>>>>>>>
>>>>>>>> TCP 80 -> NAT 192.168.1.1:80
>>>>>>>> TCP 25 -> NAT 192.168.1.15:25
>>>>>>>>
>>>>>>>> ALL other inbound traffic -> NAT 192.168.1.2
>>>>>>>>
>>>>>>>> I suppose that NAT_TCP_FORWARD, NAT_UDP_FORWARD could be used  
>>>>>>>> with some very wide ranges with the specified ports listed  
>>>>>>>> before the wide range, but I was hoping for something cleaner  
>>>>>>>> that would ensure that DMZ-IP forwards would happen at the  
>>>>>>>> right time without having to ensure they were listed last in  
>>>>>>>> these other fields.
>>>>>>>>
>>>>>>>> Darrick
>>>>>>> Interesting idea...
>>>>>>> This would allow multiple firewalls to be easily placed back- 
>>>>>>> to-back, the first firewall handles what it chooses and then  
>>>>>>> forwards everything else to another firewall downstream.
>>>>>>> Possibly Arno could add something like:
>>>>>>> FORWARD_DENYED="192.168.1.2"
>>>>>>> before his DENY's, to forward traffic to a particular IP  
>>>>>>> address immediately before they would normally be blocked.
>>>>>>> Lonnie
>>>> _______________________________________________
>>>> Firewall mailing list
>>>> Firewall at rocky.eld.leidenuniv.nl
>>>> http://rocky.eld.leidenuniv.nl/mailman/listinfo/firewall
>>>> Arno's (Linux IPTABLES Firewall) Homepage:
>>>> http://rocky.eld.leidenuniv.nl
>>>
>>> -- 
>>> Arno van Amersfoort
>>> E-mail : arnova at rocky.eld.leidenuniv.nl
>>> Donations are welcome through Paypal!
>>> ---------------------------------------------------------------------------
>>> Arno's (Linux IPTABLES Firewall) Homepage:
>>> http://rocky.eld.leidenuniv.nl
>>> _______________________________________________
>>> Firewall mailing list
>>> Firewall at rocky.eld.leidenuniv.nl
>>> http://rocky.eld.leidenuniv.nl/mailman/listinfo/firewall
>>> Arno's (Linux IPTABLES Firewall) Homepage:
>>> http://rocky.eld.leidenuniv.nl
>>>
>>>
>>
>> _______________________________________________
>> Firewall mailing list
>> Firewall at rocky.eld.leidenuniv.nl
>> http://rocky.eld.leidenuniv.nl/mailman/listinfo/firewall
>> Arno's (Linux IPTABLES Firewall) Homepage:
>> http://rocky.eld.leidenuniv.nl
>>
> _______________________________________________
> Firewall mailing list
> Firewall at rocky.eld.leidenuniv.nl
> http://rocky.eld.leidenuniv.nl/mailman/listinfo/firewall
> Arno's (Linux IPTABLES Firewall) Homepage:
> http://rocky.eld.leidenuniv.nl
>
>



More information about the Firewall mailing list