Bug 931152

Summary: During Default Installation Suse Firewall does NOT Assign any ZONE to the Network Interface Card
Product: [openSUSE] openSUSE Distribution Reporter: Forgotten User SxCIMBZqeN <forgotten_SxCIMBZqeN>
Component: SecurityAssignee: Security Team bot <security-team>
Status: RESOLVED INVALID QA Contact: E-mail List <qa-bugs>
Severity: Major    
Priority: P5 - None CC: ab, aburgemeister, astieger, forgotten_SxCIMBZqeN, jo4su
Version: 13.2   
Target Milestone: 13.2   
Hardware: x86-64   
OS: openSUSE 13.2   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Forgotten User SxCIMBZqeN 2015-05-17 01:05:56 UTC
I’ve have 4 x 12.3 Default Installations. 3 KDE 1 Gnome
On inspection each and every PC showed the NIC as not being assigned to be in ANY Zone of the Suse2Firewall.
You can easily identify this by watching the boot log from ESC during Start-up and you find that Suseefirewall doesn’t even start as such.

In the unlikely event you cant validate this I'll do a fresh install for you and send you logs but sending you Yast Logs for any installation that is moths old, may yield little practice help due size and other extraneous issues.

O.T Thanks for bashing out the Bug fixes and wow thanks for putting the graphical Bug numbers back on screen. A development project without public access to numbers as it has been for a few years when it disappeared off our screens....well I wont say the obvious but Hey, unreal work being done to fix bugs if the daily updates are any example
Comment 1 Andreas Stieger 2015-05-18 07:47:15 UTC
(In reply to Scott Couston from comment #0)
> I’ve have 4 x 12.3 Default Installations. 3 KDE 1 Gnome
> On inspection each and every PC showed the NIC as not being assigned to be
> in ANY Zone of the Suse2Firewall.
> You can easily identify this by watching the boot log from ESC during
> Start-up and you find that Suseefirewall doesn’t even start as such.
> 
> In the unlikely event you cant validate this I'll do a fresh install for you
> and send you logs but sending you Yast Logs for any installation that is
> moths old, may yield little practice help due size and other extraneous
> issues.

Hello Scott, thanks for reporting. However we are not accepting security issue reports against 12.3 anymore as it has reached it's end of life:
http://lists.opensuse.org/opensuse-security-announce/2015-02/msg00003.html

Please check if the problem still persists on 13.1, 13.2 or Tumbleweed. If so, please re-open this issue, updating the relevant product/version fields and adding any updated information. Thanks!
Comment 2 Forgotten User SxCIMBZqeN 2015-05-22 01:33:01 UTC
Apologies for version error. My earlier statement that susefirewall not being present as started and running in start-up log is incorrect but definately a default install assigns NO zone to the NIC
Comment 3 Forgotten User SxCIMBZqeN 2015-05-22 01:34:22 UTC
Version number in text should read 13.2 not 12.3...apologies
Comment 4 Andreas Stieger 2015-05-26 09:56:25 UTC
Please outline what you think is the security impact of not having a zone assigned?
"Interfaces not explicitly configured as int, ext or dmz will be considered external."
The secure default behaves as if the ext zone was assigned, applying all default rules. You can verify this by looking the configured iptables rules in such a system.
Comment 5 Forgotten User SxCIMBZqeN 2015-06-30 04:48:56 UTC
Sure I can see now that the absence of a zone has no impact on the previous default since 9.0 of assigning the default interface to the external zone. It is difficult sometimes to test the efficacy of the firewall for example an NFS client can be configured via the interface whether or not the 'open firewall' is ticked or not. 

Thanks
Comment 6 Andreas Stieger 2015-08-12 11:25:19 UTC
Closing.. no zone implies external interface. Thanks for your concern.
Comment 7 Joachim Wagner 2016-07-15 10:50:26 UTC
Posts 2 and 9 of https://forums.opensuse.org/showthread.php/518486-In-Yast-no-zone-assigned-to-interface-in-firewall-which-firewall-rules-apply

show that some users wrongly assume that the "No zone" is always closed, allowing only outgoing connections.

If this zone is then used for the public network and the external zone for a more secure but still not fully trusted network, this opens up security issues.

However, I don't think this is a big enough issue to change the software. Therefore, I submitted a documentation request as bug #989145 .