JC <hiep@xxxxxxxxxx> 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.
--
Bryan J. Smith | Sent from Yahoo Mail
mailto:b.j.smith@xxxxxxxx | (please excuse any
http://thebs413.blogspot.com/ | missing headers)
