Newbie question about IPtables script

j118 · 01-14-2013, 11:10 AM

Thanks I'll try that...

Well, I did a reinstall of policycoreutils by doing:

Code:

yum install policycoreutils

I did not try to uninstall first (too scary)

Everything seems to still be working (though I did not reboot he server, so hopefully it won't be non-functional next time it starts).

However,

there is still no restorecon. It appears it was not part of that package.

Any more ideas??

j118 · 01-14-2013, 11:26 AM

After looking around a bit, I see that I have the following in my /sbin:

Code:

iptables-restore -> iptables-multi
iptables-save -> iptables-multi
restorecon -> setfiles

After reading others post right here on these forums who are having the exact same problems with CentOS, it appears this behavior is the default one.

In some of their cases they were able to get the restorecon working after uninstalling and reinstalling policycoreutils, but that didn't work for me (EDIT: Yes it did. It installed the needed link to "setfiles") (at least not with the way I did it--without uninstalling first, and with no reboot--which I can't do without getting locked out).

So what do these links mean above?

I'm wondering if this is the setup used because this is a virtual server running in a Parallels Virtuozzo container?? Do they change how this is set up when it's running virtualized?

j118 · 01-14-2013, 11:42 AM

Well, I just tried saving iptables again after noticing that the "restorecon -> setfiles" link had a date and time of today at the same time I installed policycoreutils again (and thus I thought it might be worth trying to save my script again), and it worked!!

Code:

# service iptables save
iptables: Saving firewall rules to /etc/sysconfig/iptables:[  OK  ]

So never mind about the above posts, I guess I don't need restorecon itself, only the link "restorecon -> setfiles" to be present.

I was just typing: "locate restorecon". But that is actually irrelevant.

Thanks for your help again! I can save the rules now!

LeoPap · 01-14-2013, 11:44 AM

Great! I told you that reinstalling the policycoreutils, would solve your problems!
I am very that i helped you!

Have a nice day!

Cheers,
Leo

j118 · 01-14-2013, 11:52 AM

So now, I have another question:

Is this new rule set safe and permanent? Or can/will it be overwritten by the system on reboot?

I just want to make sure nothing resets my changes back to the way they were.

LeoPap · 01-14-2013, 11:56 AM

No you are not going to have any problem at all. You didn't run any command that need to be saved somewhere, you just install a new package, so nothing to do further.

j118 · 01-14-2013, 12:16 PM

Oh, sorry, let me clarify:

I'm asking if the iptables rules I saved by typing "service iptables save" are permanent and won't be overwritten on reboot or by the system. (Not whether the newly reinstalled policycoreutils package is permanent--though that's good to know also).

Thanks again!

LeoPap · 01-14-2013, 12:27 PM

Yes it should be fine.
If you want re-run service iptables save just to be sure!

j118 · 01-14-2013, 01:24 PM

Great, thanks!

So now I'm looking at the mangle section in my original iptable:

Code:

*mangle
:PREROUTING ACCEPT [434:24948]
:INPUT ACCEPT [434:24948]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [7:8609]
:POSTROUTING ACCEPT [7:8609]

What is this doing, and do I need to keep it?

I noticed that most of your examples do not even have anything in the mangle section. I read in some of the hoto's that "mangle" is rarely needed or used.

Also, why do the numbers in brackets (e.g. [434:24948]) change every time I save my rules? (when I open up the saved file in a text editor to see what it saved)

Is this some type of counter?

j118 · 01-14-2013, 08:07 PM

Also, In some of your examples unSpawn, you are using:

RH-Firewall-1-INPUT

Is there some benefit to using this over not using it?

I've been reading and reading all the links you guys posted, and learning a lot, but I'm unclear on "RH-Firewall-1-INPUT".

bijo505 · 01-15-2013, 01:16 AM

Quote:

Originally Posted by j118

Also, In some of your examples unSpawn, you are using:

RH-Firewall-1-INPUT

Is there some benefit to using this over not using it?

I've been reading and reading all the links you guys posted, and learning a lot, but I'm unclear on "RH-Firewall-1-INPUT".

Hi,

Code:

:INPUT ACCEPT [434:24948]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [7:8609]

These are the packet counter details (Packets and bytes) and RH-firewall-1-INPUT is the user defined chain in the filter table provided by Redhat. Mangle table is using to modify the TCP packet quality of service bits before routing occurs.

j118 · 01-15-2013, 09:36 AM

Ah, I understand. Thanks bijo505. That clarifies things nicely.

I just finished reading every word of the different references you guys all posted. I'm really starting understand this stuff much better now.

UnSpawn, I've used the rules you posted, with some modifications. The generated logfile has been extremely helpful.

In case anyone finds it helpful, this is what I ended up using (so far):

Code:

*mangle
:PREROUTING ACCEPT [84532:4867976]
:INPUT ACCEPT [84532:4867976]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [90211:23224227]
:POSTROUTING ACCEPT [90211:23224227]
COMMIT
# Completed on Mon Jan 14 22:59:17 2013
# Generated by iptables-save v1.4.7 on Mon Jan 14 22:59:17 2013
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [5:596]
-A INPUT -i lo -j ACCEPT 
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A INPUT -m state --state INVALID -j DROP 
-A INPUT -p tcp -m state --state NEW -m tcp -m multiport --dports 20:22,53,80,110,143,443,989,990,993,995,8443 -j ACCEPT 
-A INPUT -m state --state NEW -m limit --limit 1/sec -j LOG --log-prefix "IN_denied " 
-A INPUT -m state --state NEW -j REJECT --reject-with icmp-host-prohibited 
COMMIT

If you guys aren't tired of answering my questions, I do have a few more that I'm not sure of the answer to:

#1 Do I need: "-A INPUT -p icmp --icmp-type any -j ACCEPT" in my rules? Some examples had that, and some didn't.

#2 Now that I'm using the above rules, and looking at the logfiles, I'm seeing hundreds of entries like this (note: possibly sensitive numbers masked to protect the innocent):

Code:

Jan 14 23:40:42 ip-xxx-xxx-xxx-xxx kernel: IN_denied IN=eth0 OUT= PHYSIN=bond0.809 PHYSOUT=vethxxxxxxxx.0 MAC=00:xx:xx:xx:xx:xx:xx:xx:xx:de:03:xx:xx:00 SRC=xx.xx.xx.xx DST=xxx.xxx.xxx.xxx LEN=48 TOS=0x00 PREC=0x00 TTL=109 ID=xxxxx DF PROTO=TCP SPT=2958 DPT=25 WINDOW=65535 RES=0x00 SYN URGP=0

In the case of a dedicated virtual server, is "eth0" an interface that is leading to the Internet side? (the IPs I masked-out above are indeed from Internet located machines) Do I need to unblock something? Or are these denials alright? (I can already browse to my website just fine)

#3 My server is running a DNS server on port 53. Does that need to be open to the Internet (I opened it above, for now. Though only on TCP, not UDP), or is it just needing localhost (which is already open in my rules). The server is only providing DNS for it's own domain names for it's own website right now, but I may resell webspace at some point (If I become knowledgeable enough to admin a server for others). Will that make it necessary to have it open externally to the Internet?

#4 What's the best way to re-map a port like the SSH port 22? Is there anything I need to be aware of? (Perhaps I should open another thread for asking that. Is there already a good thread about that? I've been looking.)

Thanks again. Sincerely.

unSpawn · 01-15-2013, 01:04 PM

Quote:

Originally Posted by j118

I'm really starting understand this stuff much better now.

Do keep reading though.

Quote:

Originally Posted by j118

In case anyone finds it helpful, this is what I ended up using (so far):

Code:

*mangle
:PREROUTING ACCEPT [84532:4867976]
:INPUT ACCEPT [84532:4867976]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [90211:23224227]
:POSTROUTING ACCEPT [90211:23224227]
COMMIT
# Completed on Mon Jan 14 22:59:17 2013
# Generated by iptables-save v1.4.7 on Mon Jan 14 22:59:17 2013

Hmm. You could leave the above out. It's only counters and no rules.

Quote:

Originally Posted by j118

Do I need: "-A INPUT -p icmp --icmp-type any -j ACCEPT" in my rules?

There's certain types of messages you shouldn't answer to but generally speaking think of ICMP as an "error message protocol", it provides diagnostics.

Quote:

Originally Posted by j118

Now that I'm using the above rules, and looking at the logfiles, I'm seeing hundreds of entries like this (note: possibly sensitive numbers masked to protect the innocent):

Code:

IN_denied IN=eth0 OUT= PHYSIN=bond0.809 PHYSOUT=vethxxxxxxxx.0 SRC=xx.xx.xx.xx DST=xxx.xxx.xxx.xxx PROTO=TCP SPT=2958 DPT=25 SYN

In the case of a dedicated virtual server, is "eth0" an interface that is leading to the Internet side? (the IPs I masked-out above are indeed from Internet located machines) Do I need to unblock something? Or are these denials alright? (I can already browse to my website just fine)

The log entry shows somebody trying to connect to your mail server. IN=eth0 is your network-facing ethernet device, how traffic routing and naming works depends on what virtual ethernet devices dom0 provides. If you don't want people to spam your mail server then keep the port shielded. As precaution maybe make it listen on localhost only and implement an anti-spam filter?

Quote:

Originally Posted by j118

My server is running a DNS server on port 53. Does that need to be open to the Internet

If you run an authoritative Name Server (remote domain name lookups not ending up at your providers but at your machines) then you should have UDP/53 (majority of traffic) and TCP/53 open. Be aware that if you run an authoritative NS you also need a backup NS in a different network and you need to tune its configuration.

Quote:

Originally Posted by j118

What's the best way to re-map a port like the SSH port 22?

You shouldn't need to:
- deny root access to any login over the 'net (that's the default for OpenSSH BTW),
- always use pubkey auth,
- maybe constrain access to "trusted" accounts ('man sshd_config': AllowUsers / AllowGroups), and
- do use fail2ban or an equivalent (but not DenyHosts set to /etc/hosts.{allow,deny}).

LeoPap · 01-15-2013, 01:27 PM

Quote:

Originally Posted by unSpawn

You shouldn't need to:
- deny root access to any login over the 'net (that's the default for OpenSSH BTW),
- always use pubkey auth,
- maybe constrain access to "trusted" accounts ('man sshd_config': AllowUsers / AllowGroups), and
- do use fail2ban or an equivalent (but not DenyHosts set to /etc/hosts.{allow,deny}).

What unSpawn said above is a must-do in order to secure your system.
Do you have a hardware firewall in your network? If yes, then it would be easy to use mapped ports.

j118 · 01-17-2013, 01:46 PM

To unSpawn:

- Yes, I'll definitely keep reading! Thanks. I know I'm only starting to grasp these things.

- Regarding ICMP, you said "There's certain types of messages you shouldn't answer..." What kinds? I'm trying to research this, but if you want to, an example that lets only good ICMP messages through would be most welcome. If not, no problem.

- "The log entry shows somebody trying to connect to your mail server" Oops! My email accounts are using unsecure port 25 for outgoing SMTP! (*slaps forehead*) They couldn't send email out (hence the log entries). So it's good this was clarified. I have temporarily opened port 25, and will get them set up using port 456 and SSL and close port 25 again pronto! (The log file shows its worth once again!)

- "If you run an authoritative Name Server then you should have UDP/53 and TCP/53 open" I do indeed use my own server as the authoritative DNS (as far as I can tell). So I've added the following to my rules (right after the line opening the TCP ports): "-A INPUT -m state --state NEW -m udp -p udp --dport 53 -j ACCEPT". Does that look sane and acceptable?

- In regard to SSH: I'm setting it up with pubkey auth and fail2ban immediately.

To LeoPap:

No hardware firewall, though I could pay extra to have one. Right now I'm not thinking I really need one too bad. But perhaps I'm wrong?

Thanks again everyone!