The point of a DMZ is to establish a security perimeter through which only known, desired traffic is permitted to flow. This can be done with a hardware firewall device (a Cisco ASA, etc) or with a software firewall (Linux iptables, OpenBSD pfsense, etc). The point is to have a mechanism to arbitrate traffic and make decisions about what flows are appropriate.
Physically, the interconnection of a DMZ to your Internet connection might look something like:
{ the internet }----[ Firewall Device ]-----{ LAN }
|
|
{ DMZ }
Typically one physical network interface card on the firewall device is dedicated to connection to each of these segments (Internet, DMZ, and LAN). It can be done with VLANs to use fewer physical NICs but then you're starting to mix differing security concerns within the same physical medium (and that's generally to be avoided unless you're gaining some specific advantage by doing that).
Assuming that the users of the application would access the Apache webserver on TCP port 80 of the "second server" (which I'm going to call the "web server") to use the application I would see the web server computer sitting in a DMZ segment with access controlled by the firewall device creating the DMZ to:
- Allow requests from arbitrary source IPs and ports on the Internet to the web server (TCP port 80)
- Allow requests from arbitrary TCP ports on the web server to the Oracle database server on the Oracle TNS port (typically TCP port 1521)
- Allow requests from arbitrary source IPs and ports on the LAN to the SSH port on the web server (for administration)
(Assuming you're using a stateful firewall device to arbitrate access to the DMZ you wouldn't specifically need to create rules for responses to the requests above.)
This is a very simplistic view, but it communicates the idea. You'll probably want the let the web server make DNS requests and you may want to allow it to access an HTTP or HTTPS server from which to download OS updates. I'd strongly recommend against allowing the web server arbitrary outbound access to the Internet (because many exploits rely on the computer being exploited being able to download a "second stage" payload). If you don't need anyone on the Internet to administer the web server don't allow inbound SSH from the Internet. (If you do need to administer it from off-site better to connect to a VPN in the LAN segment and access the web server from the LAN.)