Stay Ahead With Linux Security Features
threat detection scalability Building a SIEM is easier than scaling one. Most open-source deployments start as a simple "all-in-one" server. It is easy to set up, but that design rarely survives the transition from a lab to a production workload. . A SIEM watching 20 endpoints is not doing the same job as one watching 500. More endpoints mean more logs; more logs require more storage; more storage makes search heavier. Eventually, the very architecture that made your lab easy to deploy becomes the reason your production...
Jun 04, 2026
security advisory apache A newly disclosed attack technique called HTTP/2 Bomb is drawing attention because it targets the software that sits at the front of much of the Linux internet. Apache HTTP Server, NGINX, Envoy, and the ingress layers that many Kubernetes environments depend on can be forced into consuming disproportionate amounts of memory using relatively small amounts of attacker traffic. . For Linux administrators, the concern is not the HTTP/2 protocol itself. It is the possibility that a single...
Jun 04, 2026
security advisory important The compromise of Nx Console shows how much infrastructure now sits behind a single developer account. GitHub repositories, CI/CD pipelines, container build systems, Terraform projects, Kubernetes deployments. None of those systems was the initial target. The workstation was. . Attackers did not need a Linux privilege escalation bug or a remote code execution chain. They needed developers to trust a tool they were already using. For many organizations, that was enough. What Happened? Federal...
Jun 03, 2026
security advisory open-source You remove the malware. You rotate the compromised credentials. You patch the original vulnerability and close the ticket. Two weeks later, the attacker is back. . What happened? You didn't lose the battle at the exploit; you lost it at the cleanup. In many modern Linux intrusions, the malware you found wasn't the main problem—it was the fallback mechanisms left behind. These hooks quietly restore attacker access the moment you look away. If you clean a host but miss these persistence layers,...
Jun 02, 2026
security advisory Red Hat Researchers investigating a campaign now tracked as Miasma found that more than 30 packages in Red Hat's @redhat-cloud-services npm namespace had been altered to deliver credential-stealing malware. . The packages weren't being used to deploy ransomware or sabotage systems. From what has been reported so far, the objective appears to have been much simpler: collect credentials from developer environments and use that access elsewhere. GitHub tokens, cloud credentials, SSH keys, and other...
Jun 02, 2026
Refine features
X Clear Filters
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
What got you started with Linux?
Loading...
Explore Latest Linux Security features
We found -2 articles for you...
102
system configurationservice managementsecurity optimizationExploring Linux Runlevels and Services for Enhanced Security
While the Firewall may be configured to block the ports utilized by the various Linux services, it is also a good practice to stop any unnecessary services on the Linux system. Not only does this increase Linux security, but it also prevents unneeded programs from running and using system resources. . Before delving deeper into Linux services, it is necessary to first grasp Runlevels. A standard Linux system may be set to boot into one of five distinct runlevels. During boot, the init process searches the /etc/inittab file for the default runlevel. After determining the runlevel, it proceeds to execute the necessary startup scripts to start the system's services. The good news is that both the runlevel and the services that are launched may be customized. What Are Runlevels? Consider Linux runlevels to be distinct "modes" in which the operating system operates. Each of these modes, or runlevels, has its own set of processes and services that may be enabled or disabled. Linux is always in some runlevel from the moment it boots up. This runlevel may change while you use your computer, based on the services that the operating system requires. How Many Runlevels Does Linux Have? In Linux, there are seven distinct runlevels ranging from zero to six. Because different distributions use the seven runlevels in different ways, compiling a clear list of what the runlevels perform is difficult. Instead, you should investigate how the runlevels function on the distribution that you are using. The list below, for the most part, depicts how Linux distributions typically configure runlevels: Runlevel 0 terminates the system. Runlevel 1 is a single-user mode for maintenance and administrative duties. This mode may alternatively be referred to as runlevel S. The second runlevel is a multi-user mode. This runlevel employs no networking services. Runlevel 3 is a networking-enabled multi-user mode. If you use a system that does not boot into a GUI, this is the standard runlevel. Runlevel 4 isnot employed. The user can modify this runlevel to suit their needs. Runlevel 5 is identical to Runlevel 3, except it additionally launches a display manager. If you have a system that boots into a GUI, this is the runlevel you are using. Runlevel 6 causes the machine to reboot. What Is My Current Runlevel? (SysV) If you want to know your current runlevel, run the command below: # runlevel Alternatively, you can also run the command: # who -r For systemd linux distributions, the setup is a little bit different. This is a list of how runlevels in sysv now compare to systemd: Run level 0 is matched by poweroff.target (and runlevel0.target is a symbolic link to poweroff.target ). Run level 1 is matched by rescue.target (and runlevel1.target is a symbolic link to rescue.target ). Run level 3 is emulated by multi-user.target (and runlevel3.target is a symbolic link to multi-user.target ). Run level 5 is emulated by graphical.target (and runlevel5.target is a symbolic link to graphical.target ). Run level 6 is emulated by reboot.target (and runlevel6.target is a symbolic link to reboot.target ). Emergency is matched by emergency.target . To check your current run level, run the command: # systemctl get-default How To Change Runlevel? (Sysv) Run levels can be changed easily. To change run level root privilege is required. Run the command below to change to runlevel 3: # init 3 The command above would change the run level to runlevel 3. Alternatively, you can also run the command using sudo if you are not a root user. In systemd, you would run the command below to change to the default runlevel 3: # systemctl isolate multi-user.target How To Change the Default Runlevel? To change default run level in sysv, run the command below: # vi /etc/inittab In a systemd distribution, the command would be a little different. You can run the command below (keeping the list from above in mind): # systemctl set-default multi-user.target Security Vulnerabilities with Linux Runlevels As stated earlier in this article, the goal of Linux runlevels is to provide an administrator with control over which services run in specific conditions. This degree of granular control over your system helps security by ensuring that no superfluous services are running. When an administrator is unaware of which services are running, he or she may fail to protect those attack surfaces. The methods described in this article can be used to set your default runlevel and control which apps run. These solutions will not only free up system resources, but they will also make your server more secure. Remember to only use the runlevels that you need.For example, beginning runlevel 5 makes little sense if you simply want to utilize the terminal. Changing runlevels may bring in a slew of new services, some of which may run fully in the background and you may forget to secure them. What Are Services? A service in Linux is a program or application that runs or intends to operate in the background. That is, it runs without requiring the user to be aware of it at all times. In general, a Linux service has no graphical interface, which means that users cannot interact with them via an interface, and the services are initiated by the system. Third-party services like MySQL can be set to start or stop alongside the system. They run in the background and wait for a signal to begin a certain activity. What Do You Need to Know about Services? As a system administrator, you must know how to query the status of services, stop and restart them, and customize them to fit the needs of your firm. If you're operating a DNS server, for example, you'll need to specify the DNS zones that you wish to serve. In general, any unique security and backup standards shouldbe applied to all of your services. The configuration files for the installed services are found in the /etc directory on Linux. While some products may have graphical configuration editors, you will almost always need to change the configuration files on linux. It is important to keep in mind what services are running as well as their configuration files so that you can appropriately set them up. How To Configure Services Without having to go into the depths of your Linux system, there are a variety of ways to manage what services start using both command line and graphical tools. Run the command(s) below to start and stop services on systemd: $ sudo systemctl start application.service $ sudo systemctl stop application.service To restart or reload services, you can run the following commands below: $ sudo systemctl restart application.service You may use the restart command to restart a running service as shown above. If the program in question can reload its configuration files without restarting, you can start the process with the reload command as shown below: $ sudo systemctl reload application.service The command below, iff available, will reload the settings in-place. Otherwise, it will restart the service to take up the updated configuration: $ sudo systemctl reload-or-restart application.service Below are the commands to disable and enable different services: $ sudo systemctl enable application.service $ sudo systemctl disable application.service To check any active, running services, you can run the command below as well: systemctl list-units To completely deny a service from running, lets say mandb in this instance, you can use the mask command as shown below: sudo systemctl mask mandb.service Why Should YouConfigure Services? Services do tasks without involving the user, which means they either perform a job at a predetermined frequency or when a specific software with a user front-end requests something from the service. The user is not participating in the call process and is not interested in or needs to know what the service is doing in the background. For these reasons comes the importance of configuring your services. Having your services properly running and configured so you do not run into issues later on down the road is essential to a fully functioning and secure linux system. Final Thoughts Hopefully, this tutorial helped you understand the Linux runlevels and services. To review, A run level is a state of init and the whole system that defines what system services are operating while Services are essential processes that usually run in the background, rather than being under the direct control of an interactive user, waiting for requests from other software programs, or to carry out essential tasks at the appropriate time. Knowing what these two things are, how they work, and how you can configure them properly is essential to keeping your system more secure. We hope you stick around for more upcoming articles! . Grasping the concept of Windows boot modes is crucial for optimizing applications and improving network resilience efficiently.. Linux Services, Runlevels Management, Service Configuration, Linux Optimization. . Brian Gomez
Sep 05, 2022
•
102
network securityopen source softwareconfiguration managementExploring SCC: An Exclusive Interview with Siem Korteweg Uncovered
In this interview we learn how the System Configuration Collector (SCC) project began, how the software works, why Siem chose to make it open source, and information on future developments.. Introduction : Have you ever noticed changes on your departmental server, but couldn't quite pinpoint what exactly happened? How many times have staff forgotten to make an entry in the log-book, or the entries made were not detailed enough? Administrators are faced with these problems on a day-by-day basis. The System Configuration Collector (SCC) project attempts to automate this process. Rather than depending on staff to keep accurate records, SCC enables a system to record all changes taking place. Additionally, the software has the functionality to send all configuration data to a central server so that it can be analyzed when needed. System Configuration Collector Project Website: LinuxSecurity.com : Please tell us about the SCC project and how it began. When did it start, and who are some of the key contributors? Siem Korteweg : In 2001 a younger colleague asked whether it was possible to automatically track the changes that were made to the configuration of a system. I told him that was impossible due to variable nature of the output of the commands we have to use to show the configuration of a system. Being a much younger colleague he accepted this answer. But I did not like to say it was "impossible" and it kept nagging me. I thought that when I could split the variable and fixed parts of the output of system commands, I would be able to track changes. I started a small, hobby project by collecting configuration data and preceding each line with "fix:" or "var:". After some time I was able to detect some changes made to configuration. But when a kernel parameter was changed, all I saw was a change from 128 to 256. I had to search in the snapshot to find out what part of theconfiguration had changed. Therefore I extended the fix-var classification with a hierarchy of keywords indicating the nature of the data. The development continued and the customer where I was developing the software, was wondering how to maintain this software without hiring me indefinitely. By that time I realized that this software also could/should be used by others. I talked to the manager of the customer and to the manager of the company I am working for and suggested to make SCC a GPL project. They both agreed and from then on, SCC was an Open Source project. To extend the collection of configuration data I looked at the code of cfg2html and check.sh (HP specific) and the FAQ's of several newsgroups. At the customer site where I started developing SCC, we deployed the software on some 300 systems. This gave us a great opportunity to tune the "fixed" and "variable" parts of the configuration to avoid unnecessary changes. The first versions of the software collected configuration data and converted the data and logbook to HTML on a per system basis. At the customer site, Bram Lous started to collect all snapshots and logbooks on a server and built the first version of the CGI-interface. Later on, Paul te Vaanholt contributed much for the HP OpenView modules. His main contribution is the analysis and conversion to SCC-format of the Operations Center database. A colleague Oscar Meijer wrote the Windows version of the SCC-client, based on WMI and WSH. The configuration of the data we are collecting on Windows systems still needs to be tuned. The software itself is stable, but it detects too many changes. The whole process of tuning what data is "fixed" and what data is "variable" takes quiet some time. LinuxSecurity.com : What is the most important benefit an administrator can get out of SCC? How can this improve the overall security of a network or host? Siem Korteweg : Each administrator should document his/her systems. We all know that, but we all lack time to do this properly. SCC automates the documentation process. For HP-UX systems SCC collects more than 95% of the configuration of the system is covered by SCC. For other system the percentage is somewhat lower at the moment. The logbooks and snapshots can assist administrators in finding the cause of an incident. Configuration changes can have unwanted side-effects (on other systems). By examining the logbooks for the changes during the last days/weeks an administrator might find the cause of an incident easier/faster. Another way of using the SCC-data to find the cause of an incident is to compare (parts of) the configuration of a system with a comparable system that does function correctly. Comparing the configuration of systems can also be used to assure that the systems in a cluster are consistent and identical. Do they run the same (versions of) software? Do they have the same kernel-configuration? It is also possible to check your security policies. Just check the snapshots on the server for the aspects of the policies. By default the server checks and signals accounts without a password. Another use of the SCC-data on the server is to quickly identify systems. After an advisory from Sun, I was able to identify within one minute the 100 systems that needed to be addressed out of a total of 600 systems. Because the selection was automated and because the collection of SCC-data was accurate and outdate, I did not miss a system. This obviously contributes to the safety of the network. LinuxSecurity.com : How difficult is it to get started? How long would it take for an administrator to get the system fully setup? Can you describe at a high level the steps necessary to setup SCC? Siem Korteweg : The easiest way tostart and get the feeling of the software is to install only the client part and keep the data and logbook on the client. Just create a simple cron-job after the installation of the client and you are finished. This way you are able to pilot the software before you deploy it more widely. The setup of the server takes some more steps. First you have to decide how to transport the SCC-data from the clients to the server. Supported mechanisms are email (optionally encrypted, using OpenSSL), scp, rcp and cp. Then setup the webserver to display the data. To achieve this, you have to indicate the path under the document-root and indicate the CGI-script of SCC. Then schedule a cron-job to transfer the SCC-data that is sent by the clients from the transfer-area to the website Finally all cronjobs of the clients have to be extended with the proper options to transfer the SCC-data to the scc-server. For several systems I recorded the entire process of configuring the server in logbooks. These logbooks are present at the website. For our HP-UX 11.i system: LinuxSecurity.com : What improvement would you like to make in the future? What direction is this project heading? Siem Korteweg : When running SCC on a system that uses clustering software, like MC ServiceGuard from HP, switching a "package" from one system to another, results in changes of the SCC-data for both systems involved in switching. We want to make the software cluster-aware by extracting the configuration data for each package and sending it separately to the scc-server. Another future extension is the collection of the configuration of network devices like routers and switches. LinuxSecurity.com : What advantage does SCC have over using a typical pen & paper log book for recording system changes? Siem Korteweg : It is automated, so it does not "forget" to record achange (supposing the changed attribute is part of the SCC-snapshot). It is not lazy (once you run it through cron). - The pen & paper logbook is a physical item that can only be at one place. Each admin of a group of systems can be at a different place, without access to the paper logbook. Suppose 7x24 systems, where the admins "follow the sun". - By consolidating all snapshots on a system with scc-srv, you obtain much data that can be searched automatically. This enables you to quickly identify the systems that need an update or to compare two systems when one of them does not function correctly. This is impossible with pen & paper. LinuxSecurity.com : What operating systems does SCC run on? What type of license is it under? Siem Korteweg : HP-UX, Solaris, AIX, Linux (RedHat, Suse, Gentoo). As the code of SCC only uses "standard" Unix tools, I think it runs on almost all Unix/Linux systems. The coverage of the configuration data depends on the OS. For example the coverage of HP-UX configuration is more than 90%. For other systems this will be less. The license is GPL. LinuxSecurity.com : If an administrator needs assistance setting up or configuring SCC is support available? If so, how can support be obtained? Siem Korteweg : Besides the documentation on our website, SCC comes with documentation and manual pages. We offer an implementation service, where a consultant visits a customer and installs the server and at most 5 clients and introduces the software to the admins of the customer. This is only feasible in the Netherlands. Otherwise, support via email is possible. When the requested support is more than a few simple questions, we have to agree upon payment. LinuxSecurity.com : How does SCC differ from other similar configuration collectors? What are some of the strengths and weaknesses of SCC? SiemKorteweg : SCC collects configuration data without formatting it immediately to HTML. Instead it prefixes each line of configuration data with fix/var and a hierarchical classification. This makes it easy to process the snapshots. The processing consists of comparing consecutive snapshots to generate the logbook, formatting the snapshot to HTML and comparing the snapshots of two systems to determine the differences. The philosophy of SCC is to collect data, not to judge its value or correctness. Stupid configuration errors in Apache/Samba are not detected in scc, this should be done at the server where all snapshots are collected. Some might question the value of all the data in the snapshots. It is true that a considerable part of the snapshots will never change during the lifetime of a system. Nevertheless this data is collected, just in case someone needs it sometimes. One commercial configuration collector works by allowing remote root-access to all clients from their server. This is not very security minded. I had security in mind when coding scc and scc-srv. A weakness of SCC is that I coded the classifications of all collected configuration data. This classification has to be used when an admin wants to view specific information. I decided to store cron configuration data under classification "software:cron:" and swap info under classification "system:swap:". Each user of SCC has to follow my intuition. Another weak point is that the clients are autonomous. The scc-srv can be DOSed by mailing much snapshots from seemingly different systems. Therefore, I suggest to install scc-srv only in a "trusted" network. Finally, scc has to do "reverse engineering" to collect for example the Apache configuration. Apache can be installed and configured in dozens of different locations. We have to determine the correct paths and files from the running processes. LinuxSecurity.com : How can the project benefit from the open source community? Siem Korteweg : The project can benefit from the open source community when admins use it and contribute their extensions. These extensions can be specific applications/hardware/OS they use or new features. At the moment some people already contribute knowledge of specific software. Feedback concerning the strong and weak aspects admins experience while they are using SCC, is also valuable. Area's for future extensions are SAN/NAS and network devices. I am looking for people and organisations that are willing to contribute in any way in these areas. LinuxSecurity.com : I wish to thank Siem, and other contributors to the System Configuration Collector project. We at LinuxSecurity.com would like to wish you the best of luck! . Introduction: Have you ever noticed changes on your departmental server, but couldn't quite pinpoint. interview, learn, system, configuration, collector, (scc), project, began, softw. . Brittany Day
Mar 25, 2004
•
102
security advisoryintrusion detectionsystem configurationSecuring Linux Systems: Hal Burgiss's Quick-Start Guides for New Users
After many months of work, Hal Burgiss has finished the first version of his very thorough Linux Security Quick-Start Guides. LinuxSecurity.com speaks with Hal about his documents and Linux security. . R ecently I had an opportunity to speak with Hal Burgiss, author of the Linux Security Quick-Start HOWTO and the Security Quick-Start HOWTO for Red Hat. Hal announces his documents after spending the last several months writing and researching the information necessary to provide a Linux administrator with the information necessary to secure his Linux box. In his documents, he discusses such topics as how to get started with ipchains and iptables, The Optimum Configuration , Intrusion Detection, configuring network services, and some great general tips. LinuxSecurity.com: Why did you decide to write the Security Guides? Hal Burgiss: Mainly, because I see a certain amount of confusion from new users on a range of issues. And then when I looked at what is in the repository at linuxdoc.org, there was not really an introductory level doc on this subject for inexperienced users. LinuxSecurity.com: Who is your target audience and why? Hal Burgiss: Well, it's an introductory level doc, so anyone new to Linux. It's primarily aimed at home desktop users. While there is a wealth of security related information around, there is not so much addressed to the new user who might be coming from another platform. It's one thing to say 'turn off all unneeded services', but quite another if you don't know what's 'needed' and what's not. Or how to know what services are actually running, and where they are getting started. And then verifying what you are doing has the intended, lasting effect. It's not rocket science, but something new users need to get up to speed on quickly. LinuxSecurity.com: How did you get started with Linux and security? Hal Burgiss: Well, let's see...I guess it goes back to when I switchedfrom a part time dialup connection to full time DSL. I got an instant case of paranoia, and tried to learn as much as I could, as quickly as I could. I wanted to do some of those things that full time connections and Linux are good for -- mail server, etc. And I wanted to make sure I could do this without worrying 24/7. That led to just a general interest in the subject. LinuxSecurity.com: What are some of the common pitfalls that new Linux users face? Hal Burgiss: I would say not knowing what services are running, and which ones of those are really needed for any given situation. How many boxes have been cracked by BIND or portmapper exploits, and the user didn't even know what these were, much less that they were running? And secondly, not knowing how important it is to keep installed packages current. LinuxSecurity.com: What do you feel is the most common Linux system vulnerability? What can be done to prevent this? Hal Burgiss: For the target audience of this HOWTO, I'm not so sure specifically which ones is all that relevant. They should think of them all as having some likelihood of vulnerability. What would really help is for vendors not to start any exposed services in their default installations. Or at least make sure a functional firewall is in place. LinuxSecurity.com: Do you believe the open source nature of Linux provides a superior vehicle to making security vulnerabilities easier to spot and fix? Hal Burgiss: Sure. But getting the fixes to the masses is another hurdle. LinuxSecurity.com: Where do vendors fit in with the process of helping with security? Hal Burgiss: Linux distros always have supplied the tools and the means to maintain secure systems. But often made it just too easy to open up everything under the sun. This seems to be changing for the better here recently. Something I don't think most vendors do well is making it easy to find security related information and updates. This is often buried somewhere. Or at least not so obvious as it could be. For experienced users, this is not a problem. LinuxSecurity.com: What do you see as the biggest threat to Linux users? Hal Burgiss: For home users, it is other Linux users. The ones that weren't aware, got cracked, and now have some rootkit installed that is poking the 'net for weak spots. LinuxSecurity.com: What is the biggest challenge writing this type of documentation? Hal Burgiss: The inconsistencies between various distributions as to where system files are located, and the tools to control system services. I still don't have a handle on this. Every distribution seems to be a variation on a theme in this respect. This makes it impossible to give concrete examples in some cases. Which leads to intentional vagueness. Which is not so good. I really believe examples are the best way to learn something new. LinuxSecurity.com: Why a Red Hat version? Hal Burgiss: First, because Red Hat and the various Red Hat based distributions hold a large chunk of the market. And specifically, a large chunk of the new to Linux market. Secondly, I use Red Hat. Third, I wanted as many concrete examples as possible. This just not work for a generic Linux version due to the idiosyncracies of the various distributions. LinuxSecurity.com: Hal, thanks very much for taking time from your schedule to enlighten our audience. We look forward to seeing your future Linux security information! Are you working on a security project that you'd like to announce to the world? LinuxSecurity.com would love to hear from you .. Dive into Hal Burgiss's Linux Security Quick-Start Guides, a valuable resource designed to empower novices in fortifying their systems efficiently.. Linux Security Guides, Quick Start, System Configuration, Intrusion Detection. . Brittany Day
Nov 14, 2001
•
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
What got you started with Linux?
Search Topics
Powered By
Linux Security - Your source for Top Linux News, Advisories, HOWTOs and Feature Releases
QUICK LINKS
subscribe to newsletters!
Like staying secure? So do we.
Sign up for updates, tips, and alerts!
Discover faster search, smarter navigation, and deeper Linux security insights. Read More