The Session Scheduler for SUSECon2015—in Amsterdam on November 2-6—is now available. To make sure you can get your top choices, schedule the sessions you want to attend now. From this page you can register for the conference and access the Sessions Catalog to select the sessions you want. The Session Scheduler is available from the Sessions Catalog.
NOTE: Register now. The early bird special pricing for the conference ends September 20.
The basic philosophy behind system hardening is quite simple: reducing a system’s attack surface. That's where the old Linux and UNIX dogma "Keep it simple" (KIS!) plays a crucial role: an administrator can reduce dangers to his or her system by simply installing less—only the absolutely necessary software—and uninstalling all redundant and superfluous packages. Apart from that, starting only the services that are really needed and controlling their ports and connections is a must. But the admin also has to prepare for a catastrophe and estimate the impact of a possible security breach and assess an aftermath.
The idea behind KIS! is obvious. If there are fewer packages installed, a critical vulnerability affecting the system is less probable. Needless to say, this is also true for special software features that should be disabled when they are not needed. Sometimes the default configuration offers a broad set of functionality with the aim to be most compatible—thereby opening doors or even backdoors for hackers. Reducing the attack surface always proves to be a balance between security and functionality.
A good starting point for hardening your systems is the SUSE® Linux Enterprise Server Security and Hardening Guide In its 75 pages you can find advice for making decisions and guidance on all security-related areas. This guide, however, does not yet cover the following tips and tricks to tweak the systems security, but they will be in future versions.
It has proven to be good practice to hide information that a possible attacker could use to compromise a system even further than he or she already has. A regular chroot process, for example, is still able to view the complete process list, which makes it possible for an attacker to gain inside information on running services, making them potential new targets for the next attack.
Next comes hidepid. This feature is an easy way to raise the bar of the proc filesystem. With hidepid only root and specially allowed non-root users or processes can view the process list outside their user id. Other (untrusted) users and processes will only see their own processes.
Switching on hidepid is a simple task. You can test it by simply remounting the /proc filesystem with the following option:
#> mount -o remount,hidepid=2 /proc
If you want to make this option permanent, even after a reboot, add the following line to /etc/fstab.
"none /proc proc hidepid=2 0 0"
A full description of available options can be found inside the Documentation/filesystems/proc.txt file from the kernel-source package.
A possible way for hardening remote access is two factor authentication.
The openssh version that is shipped with SUSE Linux Enterprise Server 12 allows public key authentication in combination with a regular user password, thereby making it hard for an attacker to test passwords for an account because the password prompt is shown only after the public key authentication has been accepted.
Consequently, even if someone got hold of your server password, that person would still be unable to log in. All that is needed is the following line inside /etc/ssh/sshd_config:
The cloud service provider side has been taking off like crazy. SUSE has a mature cloud service provider program with more than 40 cloud service partners around the world. Some of them are global providers; others are regional providers. Some are general purpose in scope, and some are very focused on a particular approach such as infrastructure as a service. As a result of all of this, our ecosystem of partners is expanding continuously.
More details on the AuthenticationMethods option can be found inside the sshd_config(5) manual page.
Hardening and securing sometimes touch areas where users rarely would expect it, such as using the right set of tools. Most system administrators and Linux engineers are using the traditional UNIX standard tools to check the systems network state. This includes tools such as ifconfig, route, arp and netstat as part of the net-tools package.
While this package is still maintained and receives security updates and bug fixes, most of the tools are deprecated by the iproute2 utils collection.
Figure 2: List of old and new tools*
So why is this important? The problem with the traditional command line tools is that they do not show all network information that is available. This is simply because the development of the Linux kernel network stack overran the capabilities of those tools, and it was easier to start a new tool set instead of updating the old one.
A simple example is the source-based routing capabilities of the kernel. It is possible to define not only routing entries for network and host targets, but also rules, depending on the source address. This can be handy especially on virtualization hosts with many guest machines. In this case the good old “route” tool is simply not smart enough to show those entries, because it cannot access the needed information. This led to iproute2 and its variety of tools such as ip (Figure 2).
Although choosing the right tool is not really part of hardening a system, it is part of understanding the system’s behavior. The network stack is a crucial layer of the system security and, therefore, the capability to extract as much relevant information as possible might become a security issue.
Transparency and knowledge are the crucial factors for hardening a system, also on an organizational layer. Knowing which services are running where and which update needs to be installed immediately on which system gives you a huge advantage, enabling you to react fast to newly disclosed vulnerabilities.
SUSE Manager can be a great tool for managing Linux in your organization. Let’s take a look at ways to troubleshoot and some important tips that will help you make the most of your installation.
Most SUSE Manager administrators experiencing trouble wrestle with three important functions: channel syncing with Customer Center, the centralized scheduler on the SUSE Manager server and client system registration/communication.
Until this process is completed for a channel, your managed clients will not be able to properly use them. For example, if a sync is still in progress, you might find that a package appears in the web interface but does not seem to be available on your client—even if it is registered to use that channel. A quick way to check is on the summary of the channel in the web UI.
You can see if any sync processes are running by searching the processes as follows:
ps aux | grep repo-sync
Then follow the log file for that channel to see its progress:
Internet speed is helpful, but is not the only variable. Much metadata has to be processed, requiring multiple database operations that take time to complete.
You can temporarily force the channel to use pre-downloaded yum repos from the Subscription Management Tool (SMT) or other locations if needed.
spacewalk-repo-sync -c res6-x86_64 -u file:///location/of/smtrepo
Refer to the documentation on how to perform broader offline synchronizations. Expect errors in initial channel sync—NCC/SCC issues and metadata change might occur, especially when the task takes hours to complete, as might be the case.
“No more mirrors to try”
“Errata skipped because of missing package”
Schedule a sync again until everything is clean. Be patient, and drink coffee as needed.
Log files from many SUSE Manager operations
Where the client repository information is stored
Many important settings for server operation
Web server data for bootstrap, bootstrap repositories, GPG keys
Where your downloaded/synched rpm files are located
There are MANY other files on the SUSE Manager system—but do not change them unless you are SURE.
The file /etc/rhn/rhn.conf has the option to add memory to the taskomatic daemon. The 1GB default allocation is an absolute minimum. If you are using repositories for Red Hat-based systems, they will grow to be very large and overrun the taskomatic daemon if you do not reserve 3-4 GB or more. You can start/stop the taskomatic service independently of the rest of the SUSE Manager services by using the service command as follows:
service taskomatic stop/start/restart/status
Then add this to the bottom of the /etc/rhn/rhn.conf file:
# Set max taskomatic mem
Restart the taskomatic service, and the memory will now be there for the scheduler.
The scheduler is responsible for launching:
If something is not occurring when it should, chances are taskomatic is having issues. Make sure the service is running, then check the log:
In order for clients to properly register with SUSE Manager, keep in mind that these things must be in place. The errors you might encounter during registration can most often be avoided by making sure you have the following:
If the bootstrap script does not finish, review the client registration requirements above.
Uninstalled packages warnings usually mean you do not have either a populated bootstrap repository and/or access to base media.
Make sure all relevant GPG keys are referenced in the bootstrap script for Red Hat-based distributions in comma-delimited form and copied to /srv/www/htdocs/pub. This is not needed for SUSE clients, since the GPG keys are installed by default with rpm’s. If the system registers, but you see no base channel, ensure that your bootstrap script/activation key matches the distribution and architecture of your client system.
‘zypper up’from the server command line. Many issues are resolved by the updates, so check often.
/var/spacewalk;since rpm downloads are stored there, it will expand to be quite large. This is especially true as you expand the number of distributions and architectures that you manage.
To learn more, attend SUSE Manager sessions at SUSECon 2015 in Amsterdam, November 2-6.
openSUSE is an independent open source project. We’re a separate organization, with our own governance organization, but we are primarily sponsored by SUSE. SUSE contributes extensive financial as well as logistical support. Most of the hardware infrastructure is hosted by SUSE. And many code contributions come from SUSE employees acting as volunteers.
This relationship is collaborative and unique. With Fedora and Red Hat, or with Ubuntu and Canonical, the corporate backer has significant levels of control over the activities of their project—whereas SUSE definitely embraces the true open source model. SUSE doesn’t directly control what we develop. And the community is always free to embrace, extend or adapt what SUSE volunteers contribute.
openSUSE functions on pure, open source, meritocratic principles—with self-organized teams around whatever contributors are doing. There’s no hierarchy. The only formal governance body is the board, which has five members plus the chairman. The chairman, who is appointed by SUSE, is the only officially imposed SUSE employee on the project. The rest of the board is elected by a group of people recognized as long-term contributors. However, no organization can employ more than half the board members, not even SUSE.
The board’s purpose is to act as a central point of contact, a conflict resolution body and a decision maker of last resort. For example, often for significant technical changes, some contributors want to take one action and other contributors a different action. The role of the board is to hash things out and come up with a resolution. The board doesn’t take a leadership role in telling people what to do.
My main purpose as chairman is to be part of the board, to keep everything running smoothly, and everyone talking to each other, and to make the decisions that we need to make. The chairman is also responsible for representing the community’s interests to SUSE. Whenever there are discussions within SUSE where the community’s perspective is needed, I get asked to chime in and also vice versa. I’m the conduit from SUSE to openSUSE to explain what’s going on at SUSE: such as the merger with Micro Focus or the development of SUSE Linux Enterprise 12: what does it mean, why SUSE is doing it, what the benefits are.
The official stated purpose of the project for the last 10 years has been to promote the use of Linux. However, we realized that we were trying to focus on everyone everywhere, which made it hard for us to establish an identity. We wanted to have greater market appeal to become the first choice of open source community participants. So the board recently identified our project strengths—where openSUSE’s appeal lies. We realized that one of our strengths is that we have lots of tools for developers and packages for system admins that are integrated into our distributions, so we offer a huge selection of choices. So our goal is to be the maker’s choice—the Linux distribution that really appeals to developers, system administrators and typical users who aspire to be sys admins. We give them everything they need to use Linux in a productive way, develop on it—and have fun.
I’m a Quality Assurance (QA) Engineer. I mainly work on SUSE Linux Enterprise, heavily using Open QA, an automated testing tool that was built originally as an openSUSE project for testing Tumbleweed. We can test all of the time, so we’re much more aware of the quality of the service pack. That’s my day job. Then as chairman of openSUSE appointed by SUSE, I also have a number of hours allocated a week for openSUSE work. SUSE makes it easy for me.
I’ve always worked in IT since university. My first interest in open source was casual: a SUSE precursor called “Slackware.” When Novell purchased SUSE in 2003, I purchased SUSE Linux 9.2. I got more serious about Linux. At that time it was hard to contribute, for example, bug fixes to it. Then in 2005, openSUSE was created to make contributing easy. That’s when I really started actively contributing, making bug fixes. Over time, I did advocacy work at events, helped with packaging the GNOME desktop and—as I still do today—maintained the branding package, the one with all the wallpaper, color choices, etc.
I started working for SUSE in September 2013. I was a customer before then. At the time, I was already an elected openSUSE board member, but I was hired purely as a QA engineer. Six months after I started, the current chairman stepped down and SUSE picked me. It was very nice of them.
Because SUSE is so open, we’re ideally positioned to partner with a wide range of different companies. Our goal is to give our customers enterprise-grade platforms such as our Linux distribution, our OpenStack distribution or our Ceph-based storage solution, and partner with major hardware and software vendors to provide a breadth of choice as well as best-of-breed selection of technologies.
From May 19, 2015 to July 31, 2015, SUSE published Yes Certification bulletins for 369 hardware devices, including servers, workstations and SAN devices. These products come from a variety of high-tech companies worldwide, including Acer, Cisco, Dell computing, Ericsson, Fujitsu, H3C Technologies, Hewlett-Packard, Hitachi, Huaweii Technologies, IBM, Intel, Lenovo, Oracle, SGI, Sugon/Dawining Information Industries, Positivo Informatica, Wincor Nixdorf and Unisys.
To research certified systems, go to the Certified Hardware Partners' Product Catalog, search the system name and type and click on the bulletin number to see the exact configuration that has been certified.
Among YES Certifications completed in the period mentioned above, the newest releases—SUSE Linux Server 12, SUSE Linux Enterprise Desktop 12 and SUSE Linux Enterprise Server 11 Service Pack 4 (SP4)—are definitely in the majority. However, there is still interest in previous releases from SUSE Linux Enterprise Server SP3 and going back to SUSE Linux Enterprise Server 10 SP4 for a few SAN devices.
Do you know that there is a series of blogs on SUSE Conversions to help you understand what the various categories in each YES bulletin mean? Here’s a list, from the first to the most recent:
SUSE is expanding its business and strategic technical relations with ISVs to support SUSE market in order to give our customers a choice of best-of-breed solutions to meet a wide range of IT and business needs. To research software certified to run on SUSE products, visit the Partner Software Catalog.
The following applications from key SUSE partners, recently certified as interoperable with SUSE Linux Enterprise Server 12. They provide capabilities essential to a wide range of businesses and are enhanced to deal with modern computing trends, including software-defined storage, cloud computing and big data.