• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 918
  • Last Modified:

How to enable inbound POP and SMTP to Redhat Server

This question is concerning an Intel server running Redhat 9 and Plesk.

When Redhat was installed, the default "medium" firewall option was taken.

Now that plesk has been installed (to allow website hosting) - the server rejects connections for POP and SMTP - preventing people from checking mail (which resides on the server).

Just as an experiment, I stopped the iptables service. That allowed me to log in and get mail.

I do not want to completely do away with the protection of the firewall. Thus I only need to add allowance of inbound traffinc on the POP and SMTP related ports. I have read through the redhat manuals and am in way over my head at this point.

Can anyone provide advice on how to do this?

Thanks,
Eric
0
epaschal
Asked:
epaschal
  • 4
  • 3
  • 2
  • +2
3 Solutions
 
epaschalAuthor Commented:
Just as additional info - here is the existing IPTABLES setup (assuming this is even relevant)...

[root@ps2 root]# iptables --list
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
RH-Lokkit-0-50-INPUT  all  --  anywhere             anywhere

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
RH-Lokkit-0-50-INPUT  all  --  anywhere             anywhere

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain RH-Lokkit-0-50-INPUT (2 references)
target     prot opt source               destination
ACCEPT     tcp  --  anywhere             anywhere           tcp dpt:ssh flags:SYN,RST,ACK/SYN
ACCEPT     tcp  --  anywhere             anywhere           tcp dpt:telnet flags:SYN,RST,ACK/SYN
ACCEPT     tcp  --  anywhere             anywhere           tcp dpt:smtp flags:SYN,RST,ACK/SYN
ACCEPT     tcp  --  anywhere             anywhere           tcp dpt:http flags:SYN,RST,ACK/SYN
ACCEPT     tcp  --  anywhere             anywhere           tcp dpt:ftp flags:SYN,RST,ACK/SYN
ACCEPT     all  --  anywhere             anywhere
REJECT     tcp  --  anywhere             anywhere           tcp dpts:0:1023 flags:SYN,RST,ACK/SYN reject-with icmp-port-unreachable
REJECT     tcp  --  anywhere             anywhere           tcp dpt:nfs flags:SYN,RST,ACK/SYN reject-with icmp-port-unreachable
REJECT     udp  --  anywhere             anywhere           udp dpts:0:1023 reject-with icmp-port-unreachable
REJECT     udp  --  anywhere             anywhere           udp dpt:nfs reject-with icmp-port-unreachable
REJECT     tcp  --  anywhere             anywhere           tcp dpts:x11:6009 flags:SYN,RST,ACK/SYN reject-with icmp-port-unreachable
REJECT     tcp  --  anywhere             anywhere           tcp dpt:xfs flags:SYN,RST,ACK/SYN reject-with icmp-port-unreachable
0
 
jlevieCommented:
As root execute lokkit. Select Customize and check "Mail (SMTP)" and also in "Other Ports" enter "pop:tcp". That should (if your RH 9 system is up to date w/respect to the RedHat errata) adjust the firewall rules. I'm not sure if it will work on an out of the box RH 9 install and seem to remember some problems with the version from the CD's. Since this system has Internet exposure you really want the updates in place for security reasons. Those updates are available from http://www.fedoralegacy.org now that Redhat no longer supports that version.
0
 
epaschalAuthor Commented:
Thanks jlevie,

Unfortunately, I had also attemped that earier, to no avail... :(

That's why I was specifically targeting the iptables, or whatever the actual source of the problem is.
0
 [eBook] Windows Nano Server

Download this FREE eBook and learn all you need to get started with Windows Nano Server, including deployment options, remote management
and troubleshooting tips and tricks

 
jlevieCommented:
If memory serves, I seem to remember a bug in lokit in the distreibution of RH 9 that prevented it from actually changing the firewall. That was fixed by one of the errata updates and if you haven't applied all of the errata updates it may be the problem.
0
 
epaschalAuthor Commented:
Do you know how to fix the problem, without using the RedHat tool? I have applied all of the updates.
0
 
jlevieCommented:
I haven't had much success in manually modifying the lokit generated rules. But if you want to try see my comment in http://www.experts-exchange.com/Networking/Linux_Networking/Q_21199052.html

Alternatively you can scrap the lokit generated rules and base a firewall on what I use. You can get it from http://www.entrophy-free.net/tools/iptables-gw
0
 
wesly_chenCommented:
Hi,

   How about /usr/bin/redhat-config-securitylevel (or /usr/bin/firewall on older RedHat version)?
It's the interface of iptables in GUI.

Wesly
0
 
epaschalAuthor Commented:
Hi Wesley,

I don't have that program in bin, don't know why (using Redhat 9, latest kernel). Here's what I did have prefixed with "redhat":

redhat-config-mouse          redhat-config-network-druid
redhat-config-network        redhat-config-network-tui
redhat-config-network-cmd

Also no luck with the /usr/bin/firewall directory.
0
 
wesly_chenCommented:
Hi,
   Download from the following URL and usr "rpm -ivh redhat-config-securitylevel-1.1.1-3.noarch.rpm"
http://download.fedoralegacy.org/redhat/9/os/i386/redhat-config-securitylevel-1.1.1-3.noarch.rpm

   You can find the file in your RedHat 9 CDs.

Wesly
0
 
cyb3rj0hnCommented:
Add this to your firewall or run from command line to test:

# SMTP and POP3
iptables -A INPUT -i eth0 -p tcp --d port 25 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --d port 110 -j ACCEPT

Hope this helps.

Cheers,
John
0
 
de2ZotjesCommented:
In general on a rh9 box you can manually alter the iptables rules ( - as cyb3r.. suggests - ). And after that you can run ( as root):

service iptables save

This will write out the active ruleset to /etc/sysconfig/iptables. After a reboot (or similar event) your rules will not be lost :)
I can't think of anything more that an interface tool would do for you...

0

Featured Post

 The Evil-ution of Network Security Threats

What are the hacks that forever changed the security industry? To answer that question, we created an exciting new eBook that takes you on a trip through hacking history. It explores the top hacks from the 80s to 2010s, why they mattered, and how the security industry responded.

  • 4
  • 3
  • 2
  • +2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now