JC hiep@ee.ucr.edu wrote:
I have this problem that I'm not sure what's the best solution for it. I need your input & help...
The best solution is to address this with DNS and, possibly, a set of HTTP (Apcche httpd.conf) rules. But I think DNS would only be required.
I have an internal network behind a hardware firewall. All traffics go thru. the firewall.
I assume you mean all non-local subnet traffic. ;->
One of the firewall's rules is that it doesn't allow internal network accesses internal resources that travels outside then come back.
And that should _never_ be something you want to do. If the traffic is between 2 internal systems, then it should _never_ leave the local layer-2 network (or internal layer-3 subnets).
I.e.,
Internal systems should address other internal systems differently than any "pin-holed"/DNAT Internet services -- including DNS and any service rules to support it (including TCP Wrappers). Even for DMZ servers (unless the DMZ is a public subnet, and not DNAT'd), you should address systems differently from internal and external.
In fact, I recommend highly against "pin-hole"/DNAT'ing servers on your private LAN, and setting up a segmented DMZ. But that too is another story (although IPCop makes it cake).
In the other words, it drops all packets originate from inside the network that travels outside and then come back to access internal resources.
As well it should. To do otherwise is to put a huge loophole in your network.
For example: I have web server (used internal ip 10.1.1.10) behind the firewall, internal network can access this web server with http://10.1.1.10, but they can't access http://www.mydomain.com. Assume that I have static IP (xxx.xxx.xxx.xxx) maps to 10.1.1.10 and dns record www.mydomain.com points to xxx.xxx.xxx.xxx What I want is to allow users inside the network be able to access http://www.mydomain.com instead of http://10.1.1.10
You need to setup a good, internal DNS combined with external DNS strategy.
Here is my question: should I change the rule of the firewall?
In my famous southern slang ... "HELL NO!" ;->
If so, is there a security risk?
BIG TIME! ;-> It's very complex to break it all down (although I'm more than willing to discuss it -- in-person on a whiteboard or on the phone is a lot easier and "less legally questionable" ;-).
In a nutshell, _never_ route layer-3 packets and layer-4 datagrams/segments outside of your network -- and definitely _never_ as layer-2 frames on a public network, which is what outside of your firewall is.
Is there any other solution for this? By the way, I don't have an internal DNS,
You just answered your own question. ;->
Seriously now, the basic services of IPCop can provide an internal DNS without much configuration -- basically turning an /etc/host into a simple forward DNS zone.
Furthermore, IPCop could setup a DMZ for you so you can put your server in a more "isolated" area. That gets a tad more complicated, but
I use my ISP DNS service.
For your _public_ DNS. The question is, what are you using for _private_ DNS? (I hope a lightbulb went on ;-)
Thank you so much for your help,
In a nutshell, whenever I setup any company, I use the following DNS strategy.
Public DNS -- 2 forward zones - public.company.com. - company.com.
Private DNS -- 2+ forward zones (for each location) - (location).company.com. - company.com.
All of your publicly addressable servers go in the public.company.com. Then in the public DNS version of company.com., you CNAME any servers (typically all).
Now for the private DNS, you setup all your internal systems for each location in (location).company.com. Then you also setup a private DNS version of company.com for the location. For those public servers that also have private IPs at the local location, you put direct IN A records of the private IP. For those that aren't at the local location, then you CNAME to the public.company.com. address.
HERE'S AN EXAMPLE -- 1 site
A company called "bs.com" (named after me ;-) has 1 location in Oviedo. It has a mail and web server on the private subnet DNAT'd to the public IP, and a LAN server on the private subnet. Public DNS is hosted by the ISP, although it should have 2 forward zones.
Oviedo Network -- private subnet: 172.28.2.0/24 LAN server: 172.28.2.8 Mail server: 172.28.2.12 Web server: 172.28.2.15 public IP: 66.33.48.10
[ NOTE: A DMZ will complicate this a little further, although not much. In a nutshell, you'd have 3 zones -- a new "oviedo_dmz.bs.com." so DMZ systems can talk to each other on their private DMZ subnet without knowing about the "oviedo.bs.com." zone -- which is a good security measure (long story). ]
Public DNS zone: public.bs.com. (hosted by ISP) IN CNAME www IN NS 66.33.48.10 IN MX 10 mail mail IN A 66.33.48.10 www IN A 66.33.48.10
Public DNS zone: bs.com. (hosted by ISP) IN CNAME www.public.bs.com. IN NS 63.33.48.10 IN MX 10 mail.public.bs.com. mail IN CNAME mail.public.bs.com. www IN CNAME www.public.bs.com.
Oviedo DNS zone: oviedo.bs.com. (hosted internally) IN CNAME www IN NS lsrv IN MX 10 mail lsrv IN A 172.28.2.8 mail IN A 172.28.2.12 www IN A 172.28.2.15
Oviedo DNS zone: bs.com. (hosted internally) IN CNAME www.oviedo.bs.com. IN NS lsrv.oviedo.bs.com. IN MX 10 mail.oviedo.bs.com. mail IN CNAME mail.oviedo.bs.com. lsrv IN CNAME lsrv.oviedo.bs.com. www IN CNAME www.oviedo.bs.com.
When internal (to the Oviedo LAN), the bs.com. domain is a bunch of CNAME records to oviedo.bs.com. zone. That way www becomes a private IP.
When external (Internet or DMZ), the bs.com. domain is a bunch of CNAME records to the public.bs.com. zone. That way www becomes a public IP. And you're only maintaining 1 set of DNS for private and public.
This approach is expandable to more sites. E.g., lets say we added a new site, Lake Mary (lakemary.bs.com.) and we moved the mail server to it. Now the oviedo IN CNAME for mail would change to public, instead of oviedo (because it's only accessable over the Internet), while the lakemary IN CNAME would be lakemary (because it's internal).
*UNLESS*, of course, you have a VPN between Oviedo and Lake Mary. Then you'd use oviedo and lakemary directly, so CNAME to mail.lakemary.bs.com. in Oviedo, www.oviedo.bs.com. in Lake Mary. You'd also set up the Lake Mary internal DNS for the oviedo zone to be a secondary to the Oviedo internal DNS and vice-versa so they would receive zone updates for each's respective, internal networks -- while only having to modify 1.
But in all cases, the "bs.com." zone is specific to each site, including the public DNS. That way IPs can differ from the aspect of the Internet, the Oviedo network and any additional networks -- each maintains its own set of CNAMEs for "bs.com."
I know it seems confusing at first, but it is straight-forward after you've done it once or twice. But you can't escape the reality that you _have_to_ maintain _internal_ DNS.