Hot answers tagged

38

It's like, "Put the jewelry box outside the house so that robbers won't bother getting in for the TV?" Yes, it is exactly like that. If you don't care about the value of the database, relatively speaking, then sure it makes sense to leave it outside - if the assumption is that the application is horridly insecure, but you need to put it up anyway for ...


31

SANS' "Making Your Network Safe for Databases" (http://www.sans.org/reading-room/whitepapers/application/making-network-safe-databases-24) reads a little dated in some sections, but provides a decent "for dummies" level of guidance in the direction you're after. You could also exhaust yourself poking through the US NIST's resource centre (http://csrc.nist....


17

If the database holds card details, it can be very easily argued that you aren't fulfilling the PCI DSS requirement on appropriate protection. It also fails the sanity checks on single points of failure, and protecting your core assets. If the data is worth billions, why would you not spend a few thousand more to add layers of protection? Industry good ...


14

If you router offers a real DMZ then the rest of the network would be safe even if your Windows PC is compromised. A real DMZ is a separate network which has no or only very restricted access to the internal network. But, what most SoHo routers call DMZ is actually an exposed host, i.e. traffic from outside is forwarded to a single host inside the internal ...


11

If you are suggesting that the database server gets moved from being in the same security zone as the web server to being in the same security zone as some internal systems, then one could reasonably conclude that you are reducing security. If status quo is that web server and database server are both in the DMZ, and no connections are permitted from DMZ to ...


11

"from a LAN device (raspberry pi) located inside my company" Depending on how strict your company or any company is, LAN connections to the Companies infrastructure should not be that easy. Some companies automatically block ports on employees desks, only when needed then its opened by the sysadmins. "using OpenVPN to connect my Raspberry Pi ...


7

Simply, a DMZ is portion of your network carved off and isolated from the rest of your network. A firewall is the appliance that creates that isolation, by restricting traffic both between the intranet and the DMZ and the DMZ and other networks it's exposed to.


5

The Guidance column of PCI DSS 1.3.3 (v3) states: Examination of all inbound and outbound connections allows for inspection and restriction of traffic based on the source and/or destination address, as well as inspection and blocking of unwanted content, thus preventing unfiltered access between untrusted and trusted environments. This helps ...


5

The same vulnerabilities that exist between two internal workstations on the same network. Things such as: NetBIOS access Accessing admin shares (C$) or any shares for that matter Brute forcing DMZ accounts over the network Remote registry access RDP access That's just for starters. It's bad practice to allow unrestricted access from internal resources ...


5

The vSECR Team has been actively investigating CVE-2014-6271 aka “Shell Shock” and its impact on their products. Currently VMware has determined that ESXi is not affected and neither are Windows based products including vCenter for Windows. Investigation into other products is ongoing. For now you are probably safe, but stay tuned! Check http://www.vmware....


5

AvID has already covered the main question, but coming at this from a slightly different angle most firewalls will support multiple interfaces and can provide control of traffic between the interfaces. Configuring the multiple interfaces to host each of the aspects of the solution (frontend, middleware, backend) would reduce the risk of onward compromise of ...


5

Forwarding port 80 is no more insecure than any other port. In fact, port forwarding itself is not inherently insecure. The security concern is that it allows services that are normally protected behind some kind of firewall to be accessible publicly. If the exposed service has any vulnerabilities or misconfigurations, it can and and often will be quickly ...


4

Assuming you are attempting to persuade them to do it rather than (necessarily) convince them it is correct: Explain that when their large customers and prospects come to do a security audit they will fail. If the obstacle is the business then that will be the only sufficient, and only necessary, reason.


4

RODCs really are all about physcial security, and not at all about network security. They're an upgrade of ye olde Backup Domain Controllers, that had a nasty tendency to get stolen (and the database along with it). RODCs come with a unique kbtgt account, so they can't intrude on Active Directory, or decipher kerberos tickets on behalf of WDCs, in case of a ...


4

You are not adding much security doing it this way alone: if an attacker can find a fault in your web app, using a reverse proxy alone will not prevent anything. However, the fact that your reverse proxy is the place where the SSL connection is terminated allow you to add other security systems in between the final app and the user: it could be a WAF, an ...


4

Port 80 is not more insecure by itself than any other port. Simply it is the common HTTP port so it has very high risks of being scanned, and applications behind it are expected to be web applications. That is were security admins begin to see red flashing lights. It is possible to make secure web apps, but that is a real work, that commonly involves ...


4

The main aspects to consider in this case are defense-in-depth and security by design. As you rightly point out, adding layers after layers of firewalls and port forwards does increase complexity but does not defend against attacks on its own. A successful attack is a function of time and effort, therefore anything can be compromised. Having this in mind ...


3

Using a reverse proxy can thwart some exploits targeting the webserver. Reverse proxies are usually simpler than webservers, so they are (in theory!) less likely to have vulnerabilities. If the proxy is exploited, this does not yet give the attacker access to any data on the webserver or other systems behind the DMZ Note that this only applies to low-level ...


3

The theory is that traffic to the DMZ must be inbound. In that case, should something bad happen to the the DMZ host, the attack is contained within the DMZ. This means that the connections from your LAN must be initiated in the LAN, which usually means some kind of push (to the DMZ) or pull (from the DMZ) operations. This is doable for mail but sometimes ...


3

"Proxy server" is an imprecise term. You have to think about what the proxy server is protecting to determine where it fits on the network. For example, web proxy servers used to channel outbound web surfing are often placed on internal networks rather than DMZs - their connections are outbound and they pose no additional "threat" to the internal network - ...


3

I believe that there are security benefits to deploying an RODC in a DMZ, namely because you can control what AD information is replicated. You can therefore selectively choose what information must be replicated (account attributes / passwords / etc) all while avoiding exposing a writable DC. Microsoft released an article about putting domain controllers ...


3

For a reasonable level of security, the answer is really neither. The database should be housed in it's own zone, not the DMZ with the web server, or in the internal network zone. This allows additional levels of protection both against intrusion from the public Internet should the web server or web application be compromised, and against attacks from the ...


3

Your architecture looks fine. Use of Reverse Proxy also depends on below factors: No. of Web Servers, you are planning to host No. of Public IP Addresses you have Do you want a layer of abstraction between your LAN and Web? In terms of additional security, I believe a vulnerable application running anywhere will remain vulnerable, unless you are using WAF (...


3

There are situations where an external-facing database is used to store temporary information which is "pulled" not "pushed" through a one-way firewall connection into a larger internal database then that data is deleted from the external-facing one. The purpose for this is to reduce the number of records which can be stolen at any given time yet allowing ...


3

Web Proxy vs Port Forwarding: Proxy is easier to hijack and reconfigure (it's an application) then kernel routing tables etc. Additionally web proxy will create more load then kernel TCP/IP stack. So proxy i worse from security and machine load point of view. Architecture Problem: Every configuration where you allow connections from DMZ to internal ...


3

That plan should work, yes. For git, at least, you have a number of other options afforded by its distributed nature. External collaborators can work on their own forks (in fact, they must, given how git works), and someone who has access to the internal server can then pull in their changes to the internal canonical server. Git was built with the core idea ...


3

Your reasoning is exactly right. Your DMZ servers being joined to your internal domain is a risk that should be avoided. Usually a separated Active Directory domain for your DMZ, or running each server standalone is the best option. A small environment might be fine with standalone, but beyond a dozen or so servers, or with a larger team of staff, a ...


3

The way you are thinking about the problem is running you into trouble. It is not the DMZ or the tiers that improve security; it's the separation of the access and the data. A DMZ is one way to separate access and data at the network level 3-tier architecture is one way to separate access and data at the application level So, thinking about it this way, ...


2

One good argument is that the bar really isn't that high to separate the web servers and database servers into separate DMZ's. Use a real router/firewall, and put the web servers and database servers on separate VLANs, both of them outside the internal secure LAN, with firewall rules controlling access to the bare minimum required ports from the Internet to ...


2

The DMZ should generally be the only network publicly accessible; versus the private network ("Production net"?), where no ports should be 'directly' publicly accessible. Connections between the two segments are largely dependent upon your application's requirements. The key is that the private segment is not directly accessibly, so one (or more) devices ...


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