We've just learnt about firewalls and DMZ and I'm struggling to understand how are these actually implemented ? The architecture we've learned was something like this:
Let's say that we have a shopping website that allows users to register an account in order to make online purchases and also participate in the website's forum.
In terms of security, what assets should be placed in the DMZ and what assets should be placed in the internal network ?
This is going to vary depending on your specific situation, policies you are trying to enforce, and regulatory compliance requirements.
Generally, a web-app has a front-end and a back end. The front-end is responsible for handling user traffic, display/presentation of data, and authentication. The back-end is usually a database of some sort that handles the persistence of the application. You may also have other integration points (say calling out to a shipping API or something like that).
Please have a look at this link for more info on a generic public web-server pattern. Ideally, unauthenticated traffic is handled as close to the network perimeter as possible. External traffic should never travel past the "DMZ" without being handled by a filtering proxy or web-front end. Thus, your solution should have a component like that in the DMZ. You may also want to create another zone, one that only contains the database server. It would then have to pass through yet another firewall to get to the corporate network. This way, if the database were to be compromised, it would not compromise other systems in the corporate network.
Please understand that these are just generalizations, and depending on the technology stack present the solution may change.
I'm going to answer your question below but to put it into context read the following first:
The diagram you are using is a very 1990's pattern. What may be much easier and more secure is to simply use a firewall with 3 or more interfaces. This also includes setting up firewall rules and filtering of traffic between any two interfaces. One important point here is no traffic for any segment runs through any other segment:
3 interfaces:
+----DMZ
|
Internet---+ Firewall
|
+---- Intranet
A slightly more complex version of this may look like the following:
4 interfaces:
+---- Intranet
|
Internet---+ Firewall+--- PCI Zone (Secured Subnet)
|
+---- DMZ
This said, the reason people used to use that design was because the original firewalls were very expensive and many only came with two interfaces. It also was a design built on top of bridging technology and old proxies from a very long time ago where people simply were used to only having two interfaces to work with. A lot of these went into old IBM networks and in some cases were also used as a bridge between Token-Ring, or FDDI, and Ethernet at the same time. Since then Firewalls have evolved a lot.
Now that you have an idea of what a firewall with multiple secured zones looks like if you were to think about being limited by hardware that only supported two physical Ethernet interfaces (this is before a standard for VLANS existed so those were still unheard of at the time) you may understand why people built the design you were seeing in your class. Simply put it was really the only option at the time given the hardware restrictions. Note: This is not to say the design isn't still used it is but most of the industry has moved on to more segmented designs which make use of more physical and virtual interfaces. One additional bit of information that may be helpful, if you have a redundant pair architecture you will need matching redundant interfaces across both firewalls into each secured zone (2 firewalls with 4 ports each kind of thing).
In the traditional design you have the servers in the DMZ are ones which would accept connections from the Internet (outside world). The LAN traditionally could send packets to the outside world and recieve the responses to those requests but no incoming request from the outside world could be initiated to enter the LAN. Part of that was also dealing with a design issue that existed before we had what became known as "stateful" packet inspection.
Quick explanation of Stateful vs. Stateless firewalling:
Stateless: Basically only blocked TCP packets with the ACK=0 packet (This is the very first packet sent in a normal TCP sequence). Originally this kind of worked because the servers behind the firewall couldn't assemble a set of packets and would close the connection once it timed out.
Stateful: Stateful had to be created because some smart attackers learned that they could perform Denial of Service attacks on the systems behind the Stateless firewalls by filling up their memory until they crashed. Later people realized they could fragment attacks across multiple packets and the firewall inspection rules would not be triggered. Likewise, there was also an issue due to what's known as single-packet attacks but that came much later.
The trick with Stateful is the Firewall now has to have more RAM but it can now hold the packets until enough were together and could be analyzed (to catch the fragmented stuff) and also remove the single packet attack problem off the server. Basically, the Firewall now stops everything, gathers and analyzes the state of the connection of all packets, inspects ALL packets and by doing this provides additional protection for the server.
Later we got into application proxying, the web application firewalls, and database firewalls.
Note: There are other types of fragment attacks than what I've mentioned and this is a really light explaination of all the technologies I just mentioned but it will hopefully be enough to put your question in perspective so that it makes more sense.
Finally, as CtrlDot mentioned a lot of the answer depends on your specific scenario and usage. These are really high-level general answers.
