Tag Info

Hot answers tagged

25

There's nothing wrong with creating access mechanisms for hosts in the DMZ to access hosts in the protected network when this is necessary to accomplish your intended result. It's, perhaps, not preferable to do so, but sometimes it's the only way to get the job done. The key things to consider are: Limit the access to the most specific firewall rule you ...


10

No. Typically you don't want your servers where they trust any other systems because that means they could compromise the DMZ server and tunnel using that trusted relationship. That means no domains, etc. Therefore, NetBIOS is not exactly useful since there are no trusts. Also, by the very nature of a system being in a DMZ the recommendation is: Uninstall ...


10

To allow connections from the DMZ to the internal LAN is breaking with the concept of a DMZ. Binding MySQL to localhost is going to be no less secure than placing MySQL elsewhere. If data theft is your concern, you should assume that were the two machines split apart and the Apache portion was compromised, then MySQL connection details stored on the ...


9

Proper network security states that DMZ servers shouldn't have any access into the 'Trusted' network. The Trusted network can get to the DMZ, but not the other way around. For DB backed web-servers like yours this can be a problem, which is why database servers end up in DMZs. Just because it is in a DMZ doesn't mean it HAS to have public access, your ...


9

A proper DMZ will isolate hosts on the DMZ from each-other in addition to managing access between the hosts and the internet / internal network. The DMZ environment provides for a single choke-point to enforce security and access policies, and provides one single point to monitor traffic into, out of, and within the DMZ. A DMZ isn't just a network that ...


9

I'm sorry, but you can't. There's no sane mechanism of virtualising on top of OSX. There's VMware Fusion, but that's not designed for running servers, not in production use, well, I certainly wouldn't. I wish you'd asked this question before buying hardware. If I were designing this network layout, I'd do the following: Internets x + ...


8

Not knowing your policies or regulatory requirements, we can't tell you what's "enough." A properly firewalled and monitored subnet generally suffices, as long as you know what you're allowing document it ensure that this matches any security policies you have and can justify it to your boss, his boss, the government, or a PCI auditor or whatever applies ...


7

This is entirely dependent on the "experimental system" in question -- Security is not something that comes in a box: it needs to be custom-tailored to every specific site, scenario, and application. If you're talking about stuff written by students (who are pretty well notorious for having ZERO practical grasp of IT security), I would say that each project ...


7

There are reasons to go in either direction that you and others have mentioned. Having a layer (kind of a pun) of abstraction in the form of static 1:1 NAT is kind of nice as you likely will not have to renumber internal hosts if your WAN IP block changes. However, the complexities and nuances that NAT introduces to packet flow through an ASA can be ...


6

Run nmap from the outside against all your address space? Examine the rule set on your firewall/border device to see what is permitted. Monitor traffic on your firewall/border device for a while and see what is being accessed? You should probably do all of the above, and once you find the results, add it to your documentation, that will be maintained. ...


6

That's a bit of an apples and oranges comparison. A DMZ is a separate network segment for systems with a greater risk of compromise; a vlan is a mechanism for achieving logical separation between different logical networks on the same physical network. The comparison you probably want to make instead is this one: Should I implement my DMZ through physical ...


6

There are obviously some dangers, but you can do it. Basically you're opening a pinhole that someone could get in through, so make it tiny. Limit it to only the servers on either end, and allow only data on the chosen ports. Its not a bad idea to use port address translation to just use bizarre ports. Still, security by obscurity is no security at all. Make ...


5

A server placed in a DMZ can't open connection to your network because there is a firewall in the middle (by the very definition of DMZ), so your network will be protected from it, should it ever be compromised by an attacker: in this scenario, the compromised server could not be used as a starting point to launch new attacks against the rest of your ...


5

I'm not completely in agreement with the DMZ descriptions described above. The security professionals who operate the DMZ probably have "paranoid" in their job descriptions and the DMZ is a "production" space, so see it from their point. Many of the vulnerabilities cited occur due to flaws in packet dissectors, which are only used during the interactive ...


5

You can't completely stop client computers from attempting to communicate with them "ever", but by placing them into a separate AD site (assuming they're in a different subnet than the "production" DCs), you'll prevent client computers from attempting to access them so long as at least one of the "production" DCs remains up at all times. If all the ...


5

I would say the main risk would be any exploit that allows someone to break out of the VM and attack the host. This has happened with VMWare before. So this would put your LAN at a higher risk from the DMZ than totally isolated machines, but I wouldn't say its stupid either. Just depends on how secure it really has to be... Also take into account this ...


5

If you're going to use two firewall layers, then best security practice dictates that you use two different vendors, with the theory being that vulnerability in one will not be in the other (in my experience this is true in practice). If you haven't already purchased the two ASAs and your budget allows, I'd recommend using a different solution for one of the ...


5

Use RSync over SSH, or another appropriate and secure method of file transfer, to get the files from the production DMZ machine to your internal network. Then back that up. Depending on your security stance, you'll need to determine if you can open up the port(s) for the transfer in both directions. If it's only one, your security stance will determine ...


4

Compartmentalization all the way. Create a new DMZ for it that is treated as an external network by all other networks, DMZs, etc. In a University environment, there are lots of areas where research and testing can end up being higher priorities than full security. Treating those circumstances as random Internet hosts is probably the best you can do for ...


4

Typically, the configuration is like this: Internet facing servers connected to Firewall's DMZ Port Trusted servers (SQL, AD, etc) connected to Firewall's Trusted/LAN Port Internet connected to Firewall's WAN port Then, the Firewall is configured to route between those subnets, and allow access according to the ACLs you define.


4

Are the security benefits really sufficient to warrant two networks and dual homed hosts in the DMZ for a smaller 12-server configuration? The application is a mission critical web app. Absolutely. Publically facing services should be isolated in a DMZ. Period. Anything that the big bad Internet can reach should be separated from your internal network ...


4

As with all security related questions, the answer is "it depends". It depends on the type of company you are, the type of services you run, how hardened your Internet facing services are, the data you are in custody of, what legislation you have to adhere to, Etc., Etc. Short answer - minimise the "attack surface" by limiting the addresses/ports between ...


4

I would put the DB in the internal network (behind a second firewall). This vastly reduces the attack surface of the DB because you set the firewall rules for the second firewall (DMZ to Internal) to ONLY allow connections on port XXXX (the DB port) from the webserver. So even if your DMZ is compromized there is still protection for your DB.


4

There is no realistic measurement in which I would consider not using a DMZ. With security, every extra bit you can get helps. The idea is, to limit the amount of attacks possible attacks. As admins, we often have to fight for the security we are allowed to implement, so take whatever you can get. Even if you have to completely open a host in your lan to ...


4

I'm with your networking guys, in theory. Any other arrangement means that when somebody compromises the web server they have a door into your LAN. Of course, reality has to play a part - if you need live data accessible from both the DMZ and the LAN then you really have few options. I'd probably suggest that a good compromise would be a "dirty" internal ...


4

It doesn't sound too complicated to me and although I don't do much work with virtualization, I suspect that your plan is a fairly common scenario for companies that host IT infrastucture for independent, disparate customers. I would recommend using VLAN's on a single switch instead of using dedicated switches in order to reduce your infrastructure costs.


4

Exchange It depends on what Exchange version you're using. If you have Exchange 2007 or 2010, there is a role custom made for living in a DMZ: the Edge Server. Put that server in your DMZ and configure correct ports between that server and your private-network Exchange Hub-Transport servers. If you have Exchange 2000/2003, there is no good solution as far ...


4

From a generalist perspective, it looks like you've done due diligence on your overall network design. Here are some things I'd recommend you keep in mind: Hone your firewall rules down very carefully. As you already stated, your DMZ2 is not accessible from the public network or private. That's great! You also stated that only certain servers can access ...


3

A good rule of thumb is to consider the damage that could potentially be done if the server were to be compromised via the service that you've opened. You'll want to consider two factors for each device: the risk level ("How likely is this to get compromised?" - this measure should go way up as soon as a service is internet-exposed) and the sensitivity ...


3

It looks like Microsoft has "officially" announced support of of TMG on Hyper-V - http://www.microsoft.com/forefront/threat-management-gateway/en/us/default.aspx As Tatas stated. Just because TMG is on the hypervisor, there is no technical requirement for the hypervisor itself to be exposed. The virtual-to-physical NIC assignments under the hypervisor is ...



Only top voted, non community-wiki answers of a minimum length are eligible