jbrave wrote:
>  >Think about it.  Is there *ever* a need for a database
>>server that powers a website to be accessible from the public Internet?
>>Probably not.
>
>Hello, here is a case: a web server accesses in-house SQL server that
>contains proprietary code and hardware too sensitive
>to be left sitting in a cage in some colo. NAT / Firewall
>(hope I'm using the terminology correctly here)
>has port forwarded to database server, with access allowed only from 
>webserver's ip.
>
>I'm reading this thread because I want to know what the dangers are 
>with NAT etc.
>The conversation is interesting, but I would like a more in-depth 
>explanation of
>why some are saying that NAT is not a good way to protect a network,

Well it's not really a question of NAT not being a good tool to 
protect a network, but that NAT is a bad thing to have on a network. 
My take is that it break the most fundamental rules of IP :
a) all devices have a globally unique address
b) all addresses are routable from all other addresses*
* with the modern qualifier that there may be 'administrative 
restrictions' such as firewall in the way

Many protocols use the IP address of one or more devices in the 
packets - FTP being the most common. To deal with this, just about 
every NAT gateway has to inspect packets for certain protocols and 
modify the contents of the packet to 'fix' the fact that the address 
isn't real. The tools that do this are usually known as Application 
Level Gateways.
SIP (used in VoIP) is particularly bad since two devices may talk to 
different registrars (for control) and be told to deal directly 
between the end devices for their data stream. Since there is no 
preconfigurable link between the SIP session and the ports used for 
the RTP data stream then it gets 'interesting' to make it work at all 
- to the extent that the variety of NAT employed by Zyxel makes SIP 
unusable* in my experience.

* It can be made to work, but needs an external proxy that will 
ignore what's in the SIP exchange and work out where the RTP packets 
are ACTUALLY coming from rather than where they SHOULD be coming from 
!

>  and it would
>be good to know how a NAT firewall could be hacked, if Shorewall is 
>secure enough
>to be used in the above scenario, what configuration mistakes to 
>look out for with
>Shorewall,

The main positive feature for NAT is that even if you accidentally 
change your default policy to allow, then no inbound traffic happens 
without there being a predefined mapping (aka port forwarding) or a 
matching outbound connection to create a dynamic mapping. If doing 
normal routing, then such a mistake would allow inbound traffic since 
there is no requirement for there to be a NAT mapping for the 
firewall to know where to send the packets.


Ultimately, the ONLY reason NAT was invented was to work around the 
problem of IP address depletion. The downside is that it breaks all 
sorts of things (hence the creation of yet more protocols such as 
uPNP and STUN to try and work around the problems caused by the 
workaround to the first problem). And also, IMHO, by it's very 
existence it has removed the pressure to fix the real problem and so 
after many many years there still is no real sign of IP6 being 
supported by the mainstream internet**

** As in most ISPs don't support IP6, most consumer grade equipment 
doesn't do IP6, I've yet to come across any VoIP equipment that does 
IP6, and so on.


>  and especially, in much more detail, the answers to this question:
>
>>  What's the difference, security wise between :
>>  DNAT  net   loc:a.b.c.d
>>  and
>>  ALLOW net   loc:a.b.c.d
>>  assuming you have a default policy net->loc of drop ?

IMHO there is no difference. If you have NAT then a DNAT rule will 
mangle the destination address appropriately and forward the packet. 
If you don't have NAT then an ALLOW rule will forward the packet. As 
long as your default policy is drop (or deny) then other inbound 
traffic will be blocked. BTW the syntax of the above lines may not be 
correct - it's just 'off the top of my head'.


>(Tried to make this more readable for you by putting carriage 
>returns after each line, hope that doesn't make it worse)

It's not been a problem for me, but I'd advise a shorter line length 
so when it gets quoted it doesn't get word wrapped to have a single 
word on every other line.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Reply via email to