Bug 472055 - do NOT blindly force off iptables
Summary: do NOT blindly force off iptables
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Hardware Certification Program
Classification: Retired
Component: Test Suite (harness)
Version: 5
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Greg Nichols
QA Contact: Lawrence Lim
URL:
Whiteboard:
Depends On:
Blocks: 494834
TreeView+ depends on / blocked
 
Reported: 2008-11-18 14:31 UTC by Patrick C. F. Ernzer
Modified: 2014-03-26 00:55 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-02-27 18:10:08 UTC
Embargoed:


Attachments (Terms of Use)
hts.spec.patch to remove %post that shuts down iptables (230 bytes, patch)
2008-11-18 15:02 UTC, Greg Nichols
no flags Details | Diff

Description Patrick C. F. Ernzer 2008-11-18 14:31:14 UTC
Description of problem:
had a very nasty surprise when updating hts today. latest version just decides on it's own that I do not need a firewall. Errm, surely you jest sir and this is just an omission from testing.

Version-Release number of selected component (if applicable):
hts-5.2-20.el4

How reproducible:
always

Steps to Reproduce:
1. have a system that does HTS amongst other things (servers are not growing on trees, so a dedicated box is not an option here)
2. have a NIC in that system where certs are run against, that NIC has a -j ACCEPT iptables rule (as per the hts docs)
3. have another NIC for other functions where I most certainly want and need iptables
4. up2date system
  
Actual results:
[...]
  13:hts                    ########################################### [100%]
Flushing firewall rules: [  OK  ]
Setting chains to policy ACCEPT: filter [  OK  ]
Unloading iptables modules: [  OK  ]
[...]

Loud swearing from me. Very very glad I did not trigger the update via RHN or I would not have been able to pull my firewall back up within 30 seconds. 

# rpm -q --scripts hts
preinstall program: /bin/sh
postinstall scriptlet (using /bin/sh):
service iptables stop
chkconfig iptables off

disbelief and very very unhappy that you are now forcing me to do a full analysis of this system because you tore the firewall down. So now I have to check that indeed nothing happened in that time window.

Expected results:
Do not blindly disable a firewall. if the user has one enabled he probably knows what he is doing. s1-hts-important-notes.html is very clear for the user who does not know what he is doing.

Additional info:

Comment 1 Greg Nichols 2008-11-18 15:02:25 UTC
Created attachment 323909 [details]
hts.spec.patch to remove %post that shuts down iptables

Comment 2 Rob Landry 2008-11-18 19:15:15 UTC
While I was never (and remain not) a fan of this brute force solution; have we verified that simply accepting whatever the state of the firewall is (more specifically the default install firewall configuration) works?  I want to say the reason that the firewall was disabled is because one or more of the services used by the network test are blocked by default.  If it works out of the box great, if not can we check the firewall and then request the user to provide a solution when we discover blocked ports/services which are required?


Note You need to log in before you can comment on or make changes to this bug.