January 2009 - openSUSE Features - openSUSE Mailing Lists

[openFate 305285] dictionary & DoS attack protection based using log scanning and dynamic firewall ban
by fate_noreply＠suse.de 27 Jan '09

27 Jan '09

Feature changed by: Michael Loeffler (sprudel24) Feature #305285, revision 7 Title: dictionary & DoS attack protection based using log scanning and dynamic firewall ban openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Duncan Mac-Vicar (dmacvicar) + Partner organization: openSUSE.org Description: Detailed Description For these attackss, usually the application/service will not allow the attacker to break in, however once a malicious password guess or DoS attack is done, baning the connection for some minutes and then an unban time of several minutes is usually enough to stop a network connection being flooded, as well as reducing the likelihood of a successful dictionary attack. The situation goes this way: - attacker starts a password guess - the system detects Y continuous failed attempts to login in the log file of the service - the system issues an iptables action to block the ip for X minutes. - after X minutes, the ip is allowed again - attacker starts a DoS attack - the system detects Y continuous connections without login - the system issues an iptables action to block the ip for X minutes. - after X minutes, the ip is allowed again Scope To provide an extra option in the firewall which allows to select which services to monitor (usually by looking at patterns in the log file ) and block the ip for a configurable interval once a dictionary attack or DoS is suspected. The option could be as well in the service module (or in both) or even in the specific service configuration module. Usually parameters to configure are the patterns and the actions. Also, YaST should tell the user to install the required packages if this option is enabled. To be defined in the scope is how much configurability is needed. If known services will be protected, or if a generic way to define protection for an arbitrary service is desired. Possible Implementation Fail2Ban provices right now most of the functionality. Provides a service that allows to define jails, a jail is a pattern and an action. A service can have more than one jail. For example the patterns for an ssh DoS attack is different than a dictionary attack on the same service, and the ban times may be different. Fail2Ban provides generic functionality not tied to any specific service and comes with predefined patterns and actions for various popular services as sshd, apache2 http authentication and others. http://en.wikipedia.org/wiki/Fail2ban http://www.fail2ban.org YaST would need to write the configuration about which patterns to use depending on the service to protect, or optionally define patterns for unknown services, same with actions, and start or stop the service depending on this functionality being enabled or not. Test Plan Doing serveral failed attempts on the ssh server should block the user for 3 minutes. Simple testcase. User Experience The functionality should be availabe in a clever location (which can be more than one, for example, firewall, services or the specific module), allowing to turn it on with sane defaults (hopefully provide the defaults fail2ban provides). The user can see the blocked attempts in the logs. Dependencies Using the fail2ban approach would require the fail2ban package, which in turns requires python, available in the openSUSE build service from a community user home project. (home:leonardocf) Contingency Plan None, as the functionality was not available before. Relations: - Preventing Brute Force Attacks With Fail2ban On OpenSUSE 10.3 (url: http://www.howtoforge.com/fail2ban_opensuse10.3) Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-26 20:50:52) I don't know about the enteprise angle (I need to think), but for the community distro it seems quite a cool feature. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305285

1 0

[openFate 305546] Support for NTLM authentication (proxy) in YaST and libzypp
by fate_noreply＠suse.de 27 Jan '09

27 Jan '09

Feature changed by: Federico Lucifredi (flucifredi) Feature #305546, revision 5 Title: Support for NTLM authentication (proxy) in YaST and libzypp - openSUSE-11.2: New + openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Katarina Machalkova (kmachalkova) Partner organization: openSUSE.org Description: YaST and libzypp should work in an environment with proxy server requiring NTLM authentication. The feature consists of two parts: 1) YaST proxy module has to provide UI to let user choose NTLM and write configuration file (/root/.curlrc) accordingly 2) libzypp media backend needs to be adapted to read and understand such configuration( that is, accept also --proxy-ntlm option instead of bare --proxy only) References: https://bugzilla.novell.com/show_bug.cgi?id=440296 https://bugzilla.novell.com/show_bug.cgi?id=412137 + Business case (Partner benefit): + openSUSE.org: Significant for adoption in mixed datacenters where the + proxy infrastruture is on MSFT assets. + Discussion: + #1: Federico Lucifredi (flucifredi) (2009-01-26 20:57:23) + Sadly, there is a realistic business case for this in mixed + datacenters. Some odd people like to use NTLM proxies, I will never + understand why. + this will be a headache to do :-/ -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305546

1 0

[openFate 305147] Wizard mode for Network Card configuration (in YaST)
by fate_noreply＠suse.de 27 Jan '09

27 Jan '09

Feature changed by: Federico Lucifredi (flucifredi) Feature #305147, revision 7 Title: Wizard mode for Network Card configuration (in YaST) openSUSE-11.2: Evaluation Priority Requester: Neutral - Info Provider: o jaeger (meissner) Requested by: Michal Zugec (mzugec) Partner organization: openSUSE.org Description: (based on "Internet/Intranet with external Router" in suse-beta-e) It seems some users don't know how to setup the SuSEfirewall correctly. Especially, they don't know if they should setup a network card as internal or external device. If a network card is found, YaST should ask for its usage (local network or directly connected to the internet?) - every user should know. With this information the firewall setup can be done in a useful way. See bugzilla https://bugzilla.novell.com/show_bug.cgi?id=67415 Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-26 20:34:01) sounds reasonable. But how many multihomed systems do we find where the user "does not know" ? Besides, the security team's policy seems to be "lock everything, ask questions later", so I am not sure they are willing to mollify the firewall rules (for instance, open up Avahi by default, or other default daemons) on a "local" interface. Asking Marcus for insight. I am not sure on this one. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305147

1 0

[openFate 305147] Wizard mode for Network Card configuration (in YaST)
by fate_noreply＠suse.de 27 Jan '09

27 Jan '09

Feature changed by: Federico Lucifredi (flucifredi) Feature #305147, revision 6 Title: Wizard mode for Network Card configuration (in YaST) - openSUSE-11.2: New + openSUSE-11.2: Evaluation Priority Requester: Neutral + Info Provider: o jaeger (meissner) Requested by: Michal Zugec (mzugec) Partner organization: openSUSE.org Description: (based on "Internet/Intranet with external Router" in suse-beta-e) It seems some users don't know how to setup the SuSEfirewall correctly. Especially, they don't know if they should setup a network card as internal or external device. If a network card is found, YaST should ask for its usage (local network or directly connected to the internet?) - every user should know. With this information the firewall setup can be done in a useful way. See bugzilla https://bugzilla.novell.com/show_bug.cgi?id=67415 + Discussion: + #1: Federico Lucifredi (flucifredi) (2009-01-26 20:34:01) + sounds reasonable. But how many multihomed systems do we find where the + user "does not know" ? + Besides, the security team's policy seems to be "lock everything, ask + questions later", so I am not sure they are willing to mollify the + firewall rules (for instance, open up Avahi by default, or other + default daemons) on a "local" interface. + Asking Marcus for insight. I am not sure on this one. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305147

1 0

[openFate 303736] yast and libzypp should respect the disk space reserved for root
by fate_noreply＠suse.de 27 Jan '09

27 Jan '09

Feature changed by: Federico Lucifredi (flucifredi) Feature #303736, revision 7 Title: yast and libzypp should respect the disk space reserved for root openSUSE-11.1: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2008-07-08 12:18:47 reject reason: Postponing. This is nice to have. Priority Requester: Desirable - openSUSE-11.2: New + openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Ladislav Slezak (lslezak) Partner organization: openSUSE.org Description: If e.g. root partition has 70MB free user space and 500MB free space reserved for root user yast reports 570MB total free space. But installation of a package which is greater than 70MB fails: installing package kdelibs3-devel-doc-3.5.5-45 needs 335MB on the / filesystem Yast should display the non-root free space (70MB in this case). It seems that it is valid only for ext2/ext3 filesystems (XFS and ReiserFS seem to not support root space). Default reserved space for ext2/ext3 is 5%. References: https://bugzilla.novell.com/show_bug.cgi?id=237309 -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=303736

1 0

[openFate 305682] Implement the possibility to allow Add-on source from remote "Plain RPM directory"
by fate_noreply＠suse.de 27 Jan '09

27 Jan '09

Feature changed by: Federico Lucifredi (flucifredi) Feature #305682, revision 3 Title: Implement the possibility to allow Add-on source from remote "Plain RPM directory" openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Stefan Assmann (assmannst) Partner organization: openSUSE.org Description: During installation when configuring an add-on product there is an option called "Local Directory". If you choose that the next window will have a checkbox "Plain RPM Directory" which allows to add a directory that only contains RPMs as an add-on source. Unfortunately this seems not to be available if you try to configure an add-on product that is not stored locally. Neither FTP, HTTP, SMB, NFS etc... have an option to add a "Plain RPM Directory". This is really useful for exchanging single or multiple RPMs during development without the need to wait for the next development snapshot to verify changes made to the RPMs install fine. Support for this should be implemented into autoyast as well. Gives the opportunity to automatically configure a plain rpm update add-on source for easy exchange of RPMs. Business case (Partner benefit): openSUSE.org: Improves development process because developers can test the influence of their changes to RPMs during installation without having to wait for the next development snapshot. + Discussion: + #1: Federico Lucifredi (flucifredi) (2009-01-26 19:43:30) + This is nice candy for developers. Good idea. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305682

1 0

[openFate 305641] Bring Puppet to fully supportable status
by fate_noreply＠suse.de 27 Jan '09

27 Jan '09

Feature changed by: Federico Lucifredi (flucifredi) Feature #305641, revision 8 Title: Bring Puppet to fully supportable status openSUSE-11.2: Evaluation Priority Requester: Mandatory Requested by: Federico Lucifredi (flucifredi) Partner organization: openSUSE.org Description: Dedicate a developer for the duration of the 11.2 cycle to shaking out Puppet on openSUSE, contribute patches upstream correcting integration with our base system, and analyzing what future integration areas (particularly with YaST, but not limited) appear promising. The objective is to walk through the Puppet documentation (http://reductivelabs.com/trac/puppet/wiki/DocumentationStart) Turnbull's book (ISBN 159059978), and test out that things work as they should, patching and sending upstream when they do not. Finally, contribute a small "Puppet on SUSE" document to the community detailing any platform- specific factors (you will see there are a number for other distors already). + Additional notes: The plan is to _INSTALL_ the Puppet infrastructure + by default. No default-running is planned - I thought it was important + to clarify this. Addtionally, Facter needs to be packaged and + supportable alongside Puppet. Cft should be packaged, but not default + installed, and not the target of this focused infrastructure work in + this cycle (i.e. Best effort). Relations: - Feature for 11 GA tech Preview (feature/id: 303687) Business case (Partner benefit): openSUSE.org: The ultimate intent is to integrate a policy management framework into the platform and have it available as default infrastructure. This has a number of consequencies: for one, the ability of third parties, both internal and external, to leverage the policy language for platform management. Secondly, I want to support the Puppet objective of being a pervasive policy language for *NIX, which may or may not be achievable. This combines with the set of enabling management technologies we want to have on the platform as blocks to build on: integrated libraries (libzypp, libstorage, ..), management instrumentation (SFCB, management profiles exposing the libraries wherever possible), Stateless YaST interface (to enable access to configuration facilities), and support instrumentation (the Novell Support Link, formerly known as Aurora and Onstar). Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-08 16:25:48) . #2: Federico Lucifredi (flucifredi) (2009-01-26 18:49:40) As per for phone conversation, this requirement is not only about technology ("Policy framework"), but also about the political decision of what solution to adopt - in which context the technology is not an Engineering decision, but a Business one. I am chosing Puppet on the theory that we will do our bit to help the rise of a cross-*NIX management tool by making it available and supported. If the interest in Puppet contines at this pace, and other things go the right way, we will consider further investment. For now, we just make Puppet (and Facter with it) L3 supported. If the market keeps moving in this direction, then good, we will integrate beyond the "managing by configuration file" scheme, and look at what YaST integration we can do. If it does not, we just keep the L3 package and move3 on. Think of it as Perl - it is on Every *NIX, and if you use it is good if not, it does not hurt. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305641

1 0

[openFate 305641] Bring Puppet to fully supportable status
by fate_noreply＠suse.de 26 Jan '09

26 Jan '09

Feature changed by: Federico Lucifredi (flucifredi) Feature #305641, revision 7 Title: Bring Puppet to fully supportable status openSUSE-11.2: Evaluation Priority Requester: Mandatory Requested by: Federico Lucifredi (flucifredi) Partner organization: openSUSE.org Description: Dedicate a developer for the duration of the 11.2 cycle to shaking out Puppet on openSUSE, contribute patches upstream correcting integration with our base system, and analyzing what future integration areas (particularly with YaST, but not limited) appear promising. The objective is to walk through the Puppet documentation (http://reductivelabs.com/trac/puppet/wiki/DocumentationStart) Turnbull's book (ISBN 159059978), and test out that things work as they should, patching and sending upstream when they do not. Finally, contribute a small "Puppet on SUSE" document to the community detailing any platform- specific factors (you will see there are a number for other distors already). + Relations: + - Feature for 11 GA tech Preview (feature/id: 303687) Business case (Partner benefit): openSUSE.org: The ultimate intent is to integrate a policy management framework into the platform and have it available as default infrastructure. This has a number of consequencies: for one, the ability of third parties, both internal and external, to leverage the policy language for platform management. Secondly, I want to support the Puppet objective of being a pervasive policy language for *NIX, which may or may not be achievable. This combines with the set of enabling management technologies we want to have on the platform as blocks to build on: integrated libraries (libzypp, libstorage, ..), management instrumentation (SFCB, management profiles exposing the libraries wherever possible), Stateless YaST interface (to enable access to configuration facilities), and support instrumentation (the Novell Support Link, formerly known as Aurora and Onstar). Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-08 16:25:48) . #2: Federico Lucifredi (flucifredi) (2009-01-26 18:49:40) As per for phone conversation, this requirement is not only about technology ("Policy framework"), but also about the political decision of what solution to adopt - in which context the technology is not an Engineering decision, but a Business one. I am chosing Puppet on the theory that we will do our bit to help the rise of a cross-*NIX management tool by making it available and supported. If the interest in Puppet contines at this pace, and other things go the right way, we will consider further investment. For now, we just make Puppet (and Facter with it) L3 supported. If the market keeps moving in this direction, then good, we will integrate beyond the "managing by configuration file" scheme, and look at what YaST integration we can do. If it does not, we just keep the L3 package and move3 on. Think of it as Perl - it is on Every *NIX, and if you use it is good if not, it does not hurt. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305641

1 0

[openFate 305641] Bring Puppet to fully supportable status
by fate_noreply＠suse.de 26 Jan '09

26 Jan '09

Feature changed by: Federico Lucifredi (flucifredi) Feature #305641, revision 6 Title: Bring Puppet to fully supportable status openSUSE-11.2: Evaluation Priority Requester: Mandatory Requested by: Federico Lucifredi (flucifredi) Partner organization: openSUSE.org Description: Dedicate a developer for the duration of the 11.2 cycle to shaking out Puppet on openSUSE, contribute patches upstream correcting integration with our base system, and analyzing what future integration areas (particularly with YaST, but not limited) appear promising. The objective is to walk through the Puppet documentation (http://reductivelabs.com/trac/puppet/wiki/DocumentationStart) Turnbull's book (ISBN 159059978), and test out that things work as they should, patching and sending upstream when they do not. Finally, contribute a small "Puppet on SUSE" document to the community detailing any platform- specific factors (you will see there are a number for other distors already). + Business case (Partner benefit): + openSUSE.org: The ultimate intent is to integrate a policy management + framework into the platform and have it available as default + infrastructure. This has a number of consequencies: for one, the + ability of third parties, both internal and external, to leverage the + policy language for platform management. Secondly, I want to support + the Puppet objective of being a pervasive policy language for *NIX, + which may or may not be achievable. This combines with the set of + enabling management technologies we want to have on the platform as + blocks to build on: integrated libraries (libzypp, libstorage, ..), + management instrumentation (SFCB, management profiles exposing the + libraries wherever possible), Stateless YaST interface (to enable + access to configuration facilities), and support instrumentation (the + Novell Support Link, formerly known as Aurora and Onstar). Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-08 16:25:48) . + #2: Federico Lucifredi (flucifredi) (2009-01-26 18:49:40) + As per for phone conversation, this requirement is not only about + technology ("Policy framework"), but also about the political decision + of what solution to adopt - in which context the technology is not an + Engineering decision, but a Business one. I am chosing Puppet on the + theory that we will do our bit to help the rise of a cross-*NIX + management tool by making it available and supported. If the interest + in Puppet contines at this pace, and other things go the right way, we + will consider further investment. For now, we just make Puppet (and + Facter with it) L3 supported. If the market keeps moving in this + direction, then good, we will integrate beyond the "managing by + configuration file" scheme, and look at what YaST integration we can + do. If it does not, we just keep the L3 package and move3 on. Think of + it as Perl - it is on Every *NIX, and if you use it is good if not, it + does not hurt. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305641

1 0

[openFate 305313] creating nonexistent directories with Autoyast
by fate_noreply＠suse.de 26 Jan '09

26 Jan '09

Feature changed by: Michael Loeffler (sprudel24) Feature #305313, revision 6 Title: creating nonexistent directories with Autoyast openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Uwe Gansert (ug) + Partner organization: openSUSE.org Description: from bug #429491 It should be possible to create directories just like files with its permissions and ownership. Today it is impossible (using just "files") to put for example /root/.ssh/authorized_keys. To anticipate possible comments, the "file_script" is not IMHO the right way to deal with the problem since it is invoked after writing the file to a filesystem. Yet it may be considered a workaround as of today. Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-23 14:19:55) up for Engineering's comment. Is workaround adequate ? -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305313

1 0