a project leader is proposing to represent all our _internal_ servers in our internal network on the outside of our internal firewall in our dmz each with an unique officially obtained _public_ ip-address. The obtained subnet will not be routed over the internet. His main argument is that we are dealing on the other side of the dmz with a company that manages our office network that maintains it's own ip-address policy and that we must be able to switch to another office IT provider without changing ip-addresses.
Besides that it will be difficult to obtain /22 public ip- addresses (we're talking about +- 500 servers), my opinion is that you don't do this, just because it's against common practice, which, as an argument, does not make an impression, as you can imagine and that this will not be inherently safe (failing of the acl on the outside firewall exposes the internal network).
What other arguments are there against this proposal?
What solutions are there that with a minimum of public addresses in the dmz, you can make 100-ths of internal servers available?
I'm not exactly following your question or diagram... I gather you drew a logical diagram and not a physical diagram (you don't really have 3 firewalls, do you?)
a service provider is going to "represent" your internal servers? I don't follow here... I gather they are going to replace your internal servers with different ones outside of your trusted network? e.g. bye bye all internal servers, they all moved to the dmz?
Also, why are they all getting registered IP addresses if they don't need to route over the internet... seems like a waste of "500" usable IP addresses... Which leads to my next question... how big is your company that you need 500 IP addresses? Not saying you don't need them, but it seems like an awful lot... I would think a more efficient plan of your services may be able to shave that number down in most cases...
So, in short, is this what you want to accomplish:
all users now access trusted servers inside your network and it works..
future plan is to move all of those servers (services) outside to the DMZ for your internal users to access... but NOBODY will need to access these services from the Internet...
You also lost me on the safety concern w/ ACLs at then end of your last statement... All access to ANY service outside of your firewall can be risky... this is why you have a qaulity firewall and you employ someone who knows what they are doing to set it up. (even after that is done, you can't assume your network is bullet proof)...
- the two books this person needs to at least scan are
Building Internet Firewalls, 2nd Edition Jun 2000 US$49.95 i-56592-871-7 890 pages Zwicky, Cooper and Chapman
Practical Unix & Internet Security, 3rd Edition Feb 2003 US$54.95 0-596-00323-4 984 pages Garfinkel, Spafford, and Schwartz
The later one is more helpful here, even if the project leader only uses windoze. Next, the project leader has to justify to management why these hosts have to be outside the firewall. In reality, if these are internal servers, there has NEVER BEEN ANY REASON to locate internal systems in an external location, EVEN IF IT'S IN A DMZ. If the idiot wants to do this so that customers can access certain files, put those files in a proxy server. If the customers are limited, have them access these files using secure protocols ONLY. IF the files are to be accessed by the general public, then the files should be served from a proxy server ONLY. Be sure to inform the project leader that systems in the DMZ should NEVER be able to access the internal net (all internal to DMZ access should be initiated from designated internal hosts, and that access should be restricted by the internal firewall), and access from the DMZ to the world should be limited to serving files outbound ONLY.
Next, clueless leader needs to consult with a real live security guru. Your headers say Debian, and .nl. While a bit dated see the Consultants-HOWTO that is now found at
formatting link
formatting link
and many other mirrors, as the 'Linux Consultants Guide'. It lists 51 reputable companies in the Netherlands, another 41 in Belgium, 3 in Luxembourg, and 105 in Germany.
Internal servers should NEVER be accessible from the world, and thus can use RFC1918 addresses. RFC1918 has 18.94 million addresses in the equivalent of 289 different /16 networks.
Getting 500 addresses (a /23 gives you 510 usable) isn't all that hard. There are literally dozens of companies that would be falling all over each other to provide that. The bigger problem would be investigating each company and their proposed IP space to see that it's not blacklisted sixteen ways to Sunday because of spam support. Also check rfc-ignorant.org to see that they are not so incompetent as to have proper required role account addresses (like 'postmaster@').
Sounds like someone has already made up their mind, and no amount of blindingly OBVIOUS facts will be considered.
See the books noted above.
The first question to be asked is why some idiot thinks that the internal hosts have to serve the data to the world. The second question is why these hosts have to be in the DMZ. Then, look into the concept of virtual servers.
That's not entirely true. In particular, DMZ mail servers often need to deliver mail to the internal mail servers. You can poll for messages from the inside, but SMTP isn't really designed for that, and it leaves your mail sitting outside the firewall longer than necessary.
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.