There is a recent case whereby it was reported that one of the production servers was hacked on port 1521. However, I am not sure how this was possible, as I checked that the OS firewall (iptables) is on :
[root@fmsproddb satellite]# /etc/init.d/iptables status
Table: nat
Chain PREROUTING (policy ACCEPT)
num target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
num target prot opt source destination
Chain OUTPUT (policy ACCEPT)
num target prot opt source destination
Table: filter
Chain INPUT (policy ACCEPT)
num target prot opt source destination
Chain FORWARD (policy ACCEPT)
num target prot opt source destination
Chain OUTPUT (policy ACCEPT)
num target prot opt source destination
Port 1521 not open :
[root@fmsproddb satellite]# cat /etc/sysconfig/iptables
# Firewall configuration written by system-config-firewall
# Manual customization of this file is not recommended.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW --dport 23 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT
[root@fmsproddb satellite]#
I assume it is listening because the application is turned on, and thus the service related to port 1521 turned on and that is why it is listening on this port?
Even if the network firewall (physical) is open, if the iptables is running in the server, it should not allow port 1521 to be open/listening?
I can't think of any other way how people can hack the server on port 1521. Please help clear my doubt.
If i remember correctly 1521 is one of the standard ports for the Oracle listener, so i suppose you have an Oracle database running there. That the listener listens is quite as it should be, no?
What makes you think the server "was hacked"?
I mean, iptables is just a packet filter and as such it cannot discern between legitimate content and an illegitimate one. It filters packets based on IP address (layer 3) and port (layer 4), nothing more, nothing less. Obviously you need to allow traffic to the configured port of the listener otherwise the database would not be usable. So either you allow this port or you disable it (eventually restricting to a certain range of IP addresses), but what content goes over this port (i.e. legitimate database queries vs. malicious content) the packet filter is the wrong tool to assess. For that you will need a "stateful inspection" type of firewall which iptables is not.
Also be aware that the concept of "host based firewalls" is a flawed one per design. A hosts role is either providing a service (that is: some application) OR providing firewall services, but not both! The reason is you don't want the host you want to protect run the firewall itself, beause in this scenario the malicious packages already have reached the interface they are trying to attack. You want the firewall in front of (and separated from) the host you try to protect so that the malicious content doesn't even reach the interface you want to protect.