So I use Samba on my home network. I open the samba ports in the GUI tool for CentOS 4. Here is the problem. Every time I reboot I'm forced to run system-config-securitylevel to get firewall ports open again. So like if I reboot samba won't work. I go into that tool either via command line or via the GUI and I simply click "ok" and samba is suddenly open.
Does anyone know what is happening? I've tried iptables -save or whatever. Nothing seems to work in getting these ports to be open on reboot.
Preston
On Mon, 26 Mar 2007, Preston Crawford wrote:
So I use Samba on my home network. I open the samba ports in the GUI tool for CentOS 4. Here is the problem. Every time I reboot I'm forced to run system-config-securitylevel to get firewall ports open again. So like if I reboot samba won't work. I go into that tool either via command line or via the GUI and I simply click "ok" and samba is suddenly open.
Does anyone know what is happening? I've tried iptables -save or whatever. Nothing seems to work in getting these ports to be open on reboot.
Preston
Look into file /etc/sysconfig/iptables - this is where system-config-securitylevel is supposed to place iptable rules definitions; Are samba ports open in that file?
If so, what iptables -L -v -n reports after system is started and after service iptables restart?
Any messages regarding iptables in dmesg or /var/log/messages?
Wojtek
Does anyone know what is happening? I've tried iptables -save or whatever. Nothing seems to work in getting these ports to be open on reboot.
service iptables save
I did that and it doesn't help. Do you think it has to do with the order in which things happen? i.e. smb starting up after iptables? It would seem other people would have that problem, though, wouldn't they?
Preston
Preston Crawford wrote:
Does anyone know what is happening? I've tried iptables -save or whatever. Nothing seems to work in getting these ports to be open on reboot.
service iptables save
I did that and it doesn't help.
ahuh? try
# iptables-save > /etc/sysconfig/iptables
in case the init.d script is broken.
make sure you are not using a non standard iptables script (otherwise, you'll nedd to see where the script gets stores/reads its config).
Do you think it has to do with the order in which things happen? i.e. smb starting up after iptables? It would seem other people would have that problem, though, wouldn't they?
Preston Crawford wrote:
Does anyone know what is happening? I've tried iptables -save or whatever. Nothing seems to work in getting these ports to be open on reboot.
service iptables save
I did that and it doesn't help. Do you think it has to do with the order in which things happen? i.e. smb starting up after iptables? It would seem other people would have that problem, though, wouldn't they?
Could you post the contents of /etc/sysconfig/iptables after a service iptables save?
On Tue, 2007-03-27 at 08:22 +0800, Feizhou wrote:
Preston Crawford wrote:
Does anyone know what is happening? I've tried iptables -save or whatever. Nothing seems to work in getting these ports to be open on reboot.
service iptables save
I did that and it doesn't help. Do you think it has to do with the order in which things happen? i.e. smb starting up after iptables? It would seem other people would have that problem, though, wouldn't they?
Could you post the contents of /etc/sysconfig/iptables after a service iptables save?
If guess if you are thinking that the order of starting up could be the cause of it, the it might be easier if you do a simple hack as follows - its not the safest way, but heck, I'm hoping it will work for you :)
# iptables -F # iptables -Z # service iptables save # chkconfig iptables on
Put all your iptables rules into a script file # vi /root/myfirewall.sh #!/bin/bash IPTABLES=/sbin/iptables $IPTABLES -F $IPTABLES -Z $IPTABLES -A INPUT -s 192.168.1.1 -j ACCEPT <or whatever needs to be done> <save and exit> # chmod 700 /root/myfirewall.sh
Add the script file into rc.local # echo "/root/myfirewall.sh" >> /etc/rc.d/rc.local
Every time upon reboot, the rc.local file gets called right at the last and in that sequence your /root/myfirewall.sh gets called just before the system is ready to accept logins. All other services should have been up and running long before the /root/myfirewall.sh gets called.
Roy Ong wrote:
On Tue, 2007-03-27 at 08:22 +0800, Feizhou wrote:
Preston Crawford wrote:
Does anyone know what is happening? I've tried iptables -save or whatever. Nothing seems to work in getting these ports to be open on reboot.
service iptables save
I did that and it doesn't help. Do you think it has to do with the order in which things happen? i.e. smb starting up after iptables? It would seem other people would have that problem, though, wouldn't they?
Could you post the contents of /etc/sysconfig/iptables after a service iptables save?
If guess if you are thinking that the order of starting up could be the cause of it, the it might be easier if you do a simple hack as follows - its not the safest way, but heck, I'm hoping it will work for you :)
Order of starting up has nothing do with it. I save my rules in exactly the same way and my boxes come up with a set of rules just like what was saved when i ran 'service iptables save'.
# iptables -F # iptables -Z # service iptables save # chkconfig iptables on
Put all your iptables rules into a script file # vi /root/myfirewall.sh #!/bin/bash IPTABLES=/sbin/iptables $IPTABLES -F $IPTABLES -Z $IPTABLES -A INPUT -s 192.168.1.1 -j ACCEPT <or whatever needs to be done> <save and exit> # chmod 700 /root/myfirewall.sh
Add the script file into rc.local # echo "/root/myfirewall.sh" >> /etc/rc.d/rc.local
Every time upon reboot, the rc.local file gets called right at the last and in that sequence your /root/myfirewall.sh gets called just before the system is ready to accept logins. All other services should have been up and running long before the /root/myfirewall.sh gets called.
Ooh, wonderful. Feel free to move the turning on of firewall rules from BEFORE the network is setup to WAY AFTER the network is setup. I, for one, will do no such thing.
well if you followed the thread you will realize that the original poster said that he did indeed do an iptables save but that didn't help in his case. furthermore i did clarify to say that
"its not the safest way, but heck, I'm hoping it will work for you"
i definitely AGREE that running the firewall rules till AFTER the system + services are up and running could be a potential hazard with a small period of vulnerability (few seconds) but having no other choice, a quick script to turn on the firewall rules at the very last is better than running nothing at all ... well, there are 2 sides to a coin and i definitely understand your concern, hence my little disclaimer within my original reply.
On Tue, 2007-03-27 at 13:24 +0800, Feizhou wrote:
Roy Ong wrote:
On Tue, 2007-03-27 at 08:22 +0800, Feizhou wrote:
Preston Crawford wrote:
Does anyone know what is happening? I've tried iptables -save or whatever. Nothing seems to work in getting these ports to be open on reboot.
service iptables save
I did that and it doesn't help. Do you think it has to do with the order in which things happen? i.e. smb starting up after iptables? It would seem other people would have that problem, though, wouldn't they?
Could you post the contents of /etc/sysconfig/iptables after a service iptables save?
If guess if you are thinking that the order of starting up could be the cause of it, the it might be easier if you do a simple hack as follows - its not the safest way, but heck, I'm hoping it will work for you :)
Order of starting up has nothing do with it. I save my rules in exactly the same way and my boxes come up with a set of rules just like what was saved when i ran 'service iptables save'.
# iptables -F # iptables -Z # service iptables save # chkconfig iptables on
Put all your iptables rules into a script file # vi /root/myfirewall.sh #!/bin/bash IPTABLES=/sbin/iptables $IPTABLES -F $IPTABLES -Z $IPTABLES -A INPUT -s 192.168.1.1 -j ACCEPT <or whatever needs to be done> <save and exit> # chmod 700 /root/myfirewall.sh
Add the script file into rc.local # echo "/root/myfirewall.sh" >> /etc/rc.d/rc.local
Every time upon reboot, the rc.local file gets called right at the last and in that sequence your /root/myfirewall.sh gets called just before the system is ready to accept logins. All other services should have been up and running long before the /root/myfirewall.sh gets called.
Ooh, wonderful. Feel free to move the turning on of firewall rules from BEFORE the network is setup to WAY AFTER the network is setup. I, for one, will do no such thing. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Roy Ong wrote:
well if you followed the thread you will realize that the original poster said that he did indeed do an iptables save but that didn't help in his case. furthermore i did clarify to say that
The thing to do then is find out why he has a problem and not come up with a less than optimal work around.
"its not the safest way, but heck, I'm hoping it will work for you"
i definitely AGREE that running the firewall rules till AFTER the system
- services are up and running could be a potential hazard with a small
period of vulnerability (few seconds) but having no other choice, a quick script to turn on the firewall rules at the very last is better than running nothing at all ... well, there are 2 sides to a coin and i definitely understand your concern, hence my little disclaimer within my original reply.
His problem is that the firewall is still locking him down. How can you say then that he is running nothing at all?
On Tue, 2007-03-27 at 08:22 +0800, Feizhou wrote: Every time upon reboot, the rc.local file gets called right at the last and in that sequence your /root/myfirewall.sh gets called just before the system is ready to accept logins. All other services should have been up and running long before the /root/myfirewall.sh gets called.
That occurred to me. But it just seems to me that if the "upstream provider" offers this GUI that manages the firewall, then the settings should stick after you reboot. That's why I'm nonplussed about this whole thing. Unless it has something to do with this being an original CentOS 4.0 install and something went amiss during updates, I'm not sure what it is. So here is the output Feizhou asked for.
It's not very fancy. I just use the GUI tool to open port 80, the ssh port and then the samba ports (137-139 and 445).
[root@myhost ~]# cat /etc/sysconfig/iptables # Firewall configuration written by system-config-securitylevel # Manual customization of this file is not recommended. *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :RH-Firewall-1-INPUT - [0:0] -A INPUT -j RH-Firewall-1-INPUT -A FORWARD -j RH-Firewall-1-INPUT -A RH-Firewall-1-INPUT -i lo -j ACCEPT -A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT -A RH-Firewall-1-INPUT -p 50 -j ACCEPT -A RH-Firewall-1-INPUT -p 51 -j ACCEPT -A RH-Firewall-1-INPUT -p udp --dport 5353 -d 224.0.0.251 -j ACCEPT -A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 137 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 137 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 138 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 138 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 139 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 139 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 445 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 445 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT -A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited COMMIT
Ugh...so that is where RH-Firewall-1-INPUT comes from...I thought it was FW-Builder or something that creates this crap.
It's not very fancy. I just use the GUI tool to open port 80, the ssh port and then the samba ports (137-139 and 445).
Hmm, no port 80 rule below but whatever...
After a reboot or perhaps just a 'service iptables restart', does 'iptables -L -n' list the rules you have below that are stored in /etc/sysconfig/iptables?
[root@myhost ~]# cat /etc/sysconfig/iptables # Firewall configuration written by system-config-securitylevel # Manual customization of this file is not recommended. *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :RH-Firewall-1-INPUT - [0:0] -A INPUT -j RH-Firewall-1-INPUT -A FORWARD -j RH-Firewall-1-INPUT -A RH-Firewall-1-INPUT -i lo -j ACCEPT -A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT -A RH-Firewall-1-INPUT -p 50 -j ACCEPT -A RH-Firewall-1-INPUT -p 51 -j ACCEPT -A RH-Firewall-1-INPUT -p udp --dport 5353 -d 224.0.0.251 -j ACCEPT -A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 137 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 137 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 138 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 138 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 139 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 139 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 445 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 445 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT -A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited COMMIT
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
There is an iptables command option that will save the current config. I can't recall if it's -s, -S or a service iptables save.
sorry no access to a linux box right now to be exact.
----- Original Message ----- From: "Feizhou" feizhou@graffiti.net To: "CentOS mailing list" centos@centos.org Sent: Tuesday, March 27, 2007 11:30:42 AM (GMT-0500) Auto-Detected Subject: Re: [CentOS] Question about rebooting and iptables rules persisting
Ugh...so that is where RH-Firewall-1-INPUT comes from...I thought it was FW-Builder or something that creates this crap.
It's not very fancy. I just use the GUI tool to open port 80, the ssh port and then the samba ports (137-139 and 445).
Hmm, no port 80 rule below but whatever...
After a reboot or perhaps just a 'service iptables restart', does 'iptables -L -n' list the rules you have below that are stored in /etc/sysconfig/iptables?
[root@myhost ~]# cat /etc/sysconfig/iptables # Firewall configuration written by system-config-securitylevel # Manual customization of this file is not recommended. *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :RH-Firewall-1-INPUT - [0:0] -A INPUT -j RH-Firewall-1-INPUT -A FORWARD -j RH-Firewall-1-INPUT -A RH-Firewall-1-INPUT -i lo -j ACCEPT -A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT -A RH-Firewall-1-INPUT -p 50 -j ACCEPT -A RH-Firewall-1-INPUT -p 51 -j ACCEPT -A RH-Firewall-1-INPUT -p udp --dport 5353 -d 224.0.0.251 -j ACCEPT -A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 137 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 137 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 138 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 138 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 139 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 139 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 445 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 445 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT -A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited COMMIT
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
_______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
James Marcinek wrote:
There is an iptables command option that will save the current config. I can't recall if it's -s, -S or a service iptables save.
Yes, yes. This has been used and proven to work. Thank you.
sorry no access to a linux box right now to be exact.
Even if you did have access it would be no use because service iptables save or whatever appears to be working properly for Preston.
The problem now is why it appears that Preston's box does not load the saved rules.
Ugh...so that is where RH-Firewall-1-INPUT comes from...I thought it was FW-Builder or something that creates this crap.
Yeah.
It's not very fancy. I just use the GUI tool to open port 80, the ssh port and then the samba ports (137-139 and 445).
Hmm, no port 80 rule below but whatever...
I misspoke. I don't allow port 80, but do allow port 443.
After a reboot or perhaps just a 'service iptables restart', does 'iptables -L -n' list the rules you have below that are stored in /etc/sysconfig/iptables?
I'll try that when I get home.
Preston
That occurred to me. But it just seems to me that if the "upstream provider" offers this GUI that manages the firewall, then the settings should stick after you reboot. That's why I'm nonplussed about this whole thing. Unless it has something to do with this being an original CentOS 4.0 install and something went amiss during updates, I'm not sure what it is. So here is the output Feizhou asked for.
ERm...with Roy's suggestion about rc.local...do you have anything in rc.local to messes around with iptables? You could be loading from /etc/sysconfig/iptables only to have them all flushed away and replaced with something else.
'grep -r iptables /etc' should show up the culprit if there is one.
That occurred to me. But it just seems to me that if the "upstream provider" offers this GUI that manages the firewall, then the settings should stick after you reboot. That's why I'm nonplussed about this whole thing. Unless it has something to do with this being an original CentOS 4.0 install and something went amiss during updates, I'm not sure what it is. So here is the output Feizhou asked for.
ERm...with Roy's suggestion about rc.local...do you have anything in rc.local to messes around with iptables? You could be loading from /etc/sysconfig/iptables only to have them all flushed away and replaced with something else.
That's one of many reasons I didn't go this route when I initially thought of it way back when (I've been living with this for months since reboots are so infrequent).
Preston
-
Feizhou -
James Marcinek -
mouss -
Preston Crawford -
Roy Ong -
Wojtek.Pilorz