Bug 717152

Summary:	Re Evaluate the Effectiveness of Yast Firewall Front End and its Application
Product:	[openSUSE] openSUSE 12.1	Reporter:	Scott Couston <scott>
Component:	Security	Assignee:	Security Team bot <security-team>
Status:	RESOLVED FEATURE	QA Contact:	E-mail List <qa-bugs>
Severity:	Enhancement
Priority:	P5 - None	CC:	jeffm, scott
Version:	Factory
Target Milestone:	---
Hardware:	All
OS:	openSUSE 11.3
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Scott Couston 2011-09-11 01:35:35 UTC

User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1

In planning for 12.1 I would like to see a huge focus devoted to PC security.

The methodology of having an External and Internal Zone needs to stop!

The current Firewall offers a simple SPI interface from the IP tables in the kernel. For any real protection from our Firewall we really need to have a comms input into a PC and designated as the External Zone and then the comms emerge from the same PC in the internal zone.

In ALL my years onside observing what is being put inplace, NO one but No one wants to waste the resources of a PC to implement the external input to the Internal output. If a site has their own web server this convention is used but no one really wants to host their own domain - It is all to easy to have and external company host both the DNS and Content of their site - Its far far far cheaper to do this that go it alone.

The only valid way I can think of to have an External/Internal zone would be to maintain the External inpout of TCP-IP but with the output being IPX/SPX and or other protocol Stacks. This would require a large amount of processing to convent the protocols but the only real application of Eternal/Internal Zones, in my opinion.

This External/Internal Model *we* have been using for years, in reflection, was a very bad Model and is being dumped as we speak. We also need to provide more Firewall Security as well as not requiring and internal/external zone.

In Australia even moderate size LANS use 1 or 2 IP's inbound then NAT'd to perhaps up to 50-75 PC's. Its just the way we do it. Home users, who are a huge target for the open product will always use the same NAT'd IP for 2 or 4 PC's in the home. It is rare to find ANYONE that uses public IP's let alone External/Internal zone Models.

The role of SPI just inures than all invited inbound traffic == the same outbound traffic. The biggest problem which makes SPI useless is that most all threats are invited inbound by any number of means.

If threats are not invited inbound then yes, SPI is perfectly good at its job.
Ontop of an SPI filter I think we must add an ALG Inspection engine for the TCP component, or the data component, and srtip the data payload then and there.

ALG filters, obviously can only inspect the TCP data payload and therefore do not impinge on HTTPS or other encrypted traffic. ALF Filtering is effective against the data payload of the most common forms of traffic.

HTTP/FTP/VOIP/.......

We can give the user the ability to whitlist a file on permitted file types and/or URL and deny blacklisted file contents on the same.

URL and MAC Filtering are probably the easiest part of TCP/IP filter to be disabled from an external intruder.

The ALG can then offer, within the data payload, the ability to inhibit active X, cookies and so forth for other control functions in the data payload that we can examine..The same whitelist and blacklist files should also be able to permit/deny active X, cookies...even down to virus signatures. For that matter we can even test for attack type intruder methods.

TCP/IP was never designed to be safe anbd it will never be safe in its current V4/6 EVER as long it maintains the default trust offered to any device on the net. Its not the job of the internet to secure the protocol, unless you thing it will be completely dumped and replaced

The reason why we can accomplish this is we have the processing performance and memory addressing that makes Windoze pail into its primate constraints that still exist in W7.

We can achieve the above without any or appreciably slowing down on nominal performance. Together with the sister bug I wrote on AppArmour I think we can do this, provide real time and serious security at the desktop because Linux can

I have classified this a a bug as we currently have a serious failing on how we try to provide modernistic security. - Discussion is fruitful and expected well before 12.1..Please add your thought idead the lost - We have a problem that we need to fix...Its not an Enhancement its a current failing of us and every other platform I would suggest.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1 Ludwig Nussel 2011-09-15 09:41:44 UTC

Well, unless you can come up with a concrete bug report bugzilla is the wrong forum for your thoughts. Please consider discussing the matter on the mailinglists instead and work with the community to formulate a feature request.

Comment 2 Scott Couston 2011-09-16 01:09:21 UTC

I would suggest you read the dependency...The bugs are so serious with Apparmour and the Suse Firewall and with Apparmour they need fixing NOW. The problem with Apparmour is that to correct this a total rewrite of the Yast front end is indicated. - In the grant scheme of both Apparmour I have supplied detailed faults, offered a quick fix and offered the best fix for both here in this bug report. Given the desire to fix both for good I have set a target on 12.1 otherwise close ALL of them as WONTFIX

Comment 3 Sascha Peilicke 2011-09-16 07:25:58 UTC

Please consider discussing this on a mailinglist first (like opensuse-packaging or opensuse-factory). Bugzilla isn't the right place for that. Either way, it helps to provide specific points to address/fix, as your proposal is rather broad in scope. If this is a call to rewrite SuSEFirewall2, you'll likely get a 'sure, go ahead', but if it's about fixing a _particular_ bug, people will be more willing to listen / consider it a bug. So, as long as this "bug" does not contain a particular issue, it's a WONTFIX, please leave it like that and use a more appropriate place. Thank you!

Comment 4 Scott Couston 2011-09-16 21:59:21 UTC

I cant get more precise about the bug profile of functionality with Apparmour that does not function. If you want to close this as wontfix - You must close all dependency with the same reason.

Jiri can you sort this out please and as a degree of logic here !
How much more precise do your need from me?
To quote the dependant bug
--- Comment #5 from Scott Couston <scott@aphofis.com> 2011-09-08 07:25:21 UTC ---
In all seriousness I think the whole Yast Module front end to Apparmour needs a
TOTAL rewrite after much reflection.

The module has no real thought progression form in its current useless state
1 Turning it on with options to add new learned profiles
2 Notification types and severity's on each profile 
3 Changing it with options to email notifications (POP) VIA TLS/SSL + sendmail
4 Demand Reporting options to screen or printer 

Comprehensive help screen within yast help + add every apparmour event to audit
logs for applications the centrally view, read and act on hundreds of PC's -
Complex Event Processing Application - already exist The only trouble with
apparmour as it is now, the user has no idea if its working or doing anything.

Its not a big ask to expect final QA certification of the state of the original
and current module +Actually working and the GUI interface actually doing
something -Sorry guys we dont need to be wise in hindsight to expect this basic
level of quality

Comment 5 Scott Couston 2011-09-16 22:04:19 UTC

CC: Jeff

Comment 6 Scott Couston 2011-10-04 22:14:18 UTC

My Apologies - The faults described here were taken fro RC 11.3 - its the same as in 11.1 but for clarity I have corrected the version the bugs came from. Given that we dont know if Apparmour does anything at all, and only has questionable notifications if system mail is both set and configured, and the Global movement to far greater security; 12.1 was selected for hopeful fix.

The dependency bug indicates the failings of the current firewall in respect to functionality and usability and again notification of events is poorly dealt with.

If we are to commit man hours to correct Apparmour then I think it would be equally as both are complementary and both can use the same code written as far as the notification mechanism at the very least. important to re-evaluate Suse Firewall.

In both these bugs I am qualified to discuss highly technical aspects of functionality, admittedly I cant write the Yast front end code - I am happy to discuss and talk in highly technical security terms for both Apparmour and the SPI of Suse Firewall

Comment 7 Jiri Srain 2011-10-05 06:47:46 UTC

Scott, I guess this comment did not belong to this bug as the same also appeared in another bug. In any case, I cannot do anything about this bug.

Comment 8 Scott Couston 2011-10-05 21:16:35 UTC

No Problem Jiri...Had a lot of trouble with bug status - see history - I just wanted you to sort it out and reassign to the correct person...thanks...Yes Its complementary to 'security in total' which includes apparmour - This bug is all about Suse Firewall but much of the improvements to the way notification can be done would be common to Apparmour.

No sense fixing Apparmour when we still allow anyone to come in our front door with only token resistance

Comment 9 Scott Couston 2011-11-30 21:58:04 UTC

At the very least can we just add syslog traffic from the firewalls logs to outbound traffic on UDP514, and use the default categories for syslog severity and include the log text in the rest of the traffic.

At least that way people who run a syslog server can see the log messages dynamically as they occur. Its usual human thought that if you cant see what the logs of DROP or CLOSE  or anything else, they think it does not do anything.

Can we also add functionality to send out POP/IMAP email to be configurable to the default defined syslog priorities and be able to end out an email if 'error level' is selected by the user. We would need all email fields - my suggestion that yast has one and one only place to configure to send out all POP/IMAP emails for all Yast applications were not deemed useful

Comment 10 Tomáš Chvátal 2017-08-11 19:04:32 UTC

12.1 is out of support scope as openSUSE Leap and Tumbleweed are supported only today.

This is not explicit bugreport but rather wish list of changes to various yast modules. As such it should've been filed as feature requests against the respective packages.