Stay Ahead With Linux Security Features
security advisory attack A Linux server gets cleaned up after an intrusion. The suspicious process is terminated, credentials are rotated, and the system is rebooted during maintenance. Everything seems secure. A few hours later, the same outbound connection appears again. . Situations like that point to persistence . The attacker no longer needs the original exploit because something on the host continues restoring access behind the scenes. Finding that mechanism is often more important than understanding how the...
Jun 08, 2026
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
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 1 articles for you...
102
data protectionencryption practicesdisk encryptionDisk Encryption: An Authoritative Guide for Linux Users
A lost Linux laptop or a recycled server drive can leak everything on it — from system files to sensitive data. Disk encryption changes that. It locks the entire drive, and nothing can be read until the right key is supplied. In this guide, we’ll look at what disk encryption does, how it works on Linux, where it helps most, and the options that are still worth using in 2025. . What Is Disk Encryption and Why Does It Matter Disk encryption turns the contents of a drive into unreadable code. Without the key, nothing on the disk can be accessed. Full disk encryption is the strongest form — see our sysadmin-focused guide for the deep dive. On Linux, the process is transparent once you log in. The operating system handles decryption automatically, so files open and save as they normally would. File encryption works differently. It lets you choose what to secure. Disk encryption takes the broader approach: it covers everything, including the operating system, swap space, and temporary files that users don’t usually see. Why does this matter? Because unprotected storage leaks data in ways people often overlook. A laptop left in an airport, a drive sent back for warranty service, or a retired server put into recycling can all expose sensitive information. With disk encryption, the hardware is locked. Without the key, it’s useless. Regulators recognize this. Frameworks like HIPAA and GDPR treat encryption as the standard for protecting data at rest, and fines often follow when it isn’t in place. How Disk Encryption Works in Linux Linux disk encryption protects everything written to the drive. Data is encrypted before storage and unlocked only after the correct passphrase is provided. To the user, the process is invisible. The system boots, the password is entered, and files open as if nothing special is happening. Underneath, everything on disk stays locked. Most modern distributions — Ubuntu, Fedora, Debian — rely on the same two components: Dm-crypt :handles encryption and decryption at the block level. LUKS2 : manages passphrases, recovery keys, and metadata to keep the setup consistent across systems. That pairing is now the baseline for linux disk encryption. It’s what makes the process seamless, whether you’re encrypting a laptop, a server, or even a removable drive. Performance used to be the trade-off. On older hardware, encryption could slow down disk operations noticeably. With today’s CPUs, AES instructions offload much of the work. In practice, the slowdown is small enough that most users never see it — but the protection it provides is significant. Disk Encryption Security Concerns Disk encryption keeps data safe on a powered-off or lost device, but it doesn’t block every type of attack. Once the system is unlocked, other risks come into play. Weak passphrases can be guessed or brute-forced. For example, a short password like “1234” can be cracked in seconds, even if the underlying encryption is strong. Standards bodies stress that a strong key matters as much as the cipher itself. Malware or keyloggers can steal the passphrase at the moment it’s typed in. Even with disk encryption in place, if malware is running on the system, it can capture the passphrase as you type. Phishing and supply chain exploits remain a real threat. Incidents like the supply chain attack targeting Telegram bots showed that attackers don’t need to break encryption if they can trick users or compromise the software supply chain. Unpatched operating systems open another door. Once the machine is running, exploits against an outdated kernel or library make the encryption irrelevant. Disk encryption stops data leaks from stolen hardware, but keeping a system secure also requires updates, monitoring, and careful handling of credentials. That’s why pairing disk encryption with strong passwords and regular updates is considered baseline security. Benefits of Disk Encryption for Linux Systems Thereal strengths of disk encryption show up in ordinary situations — the kind that don’t make headlines but still cause real damage when they go wrong. Lost or stolen devices . A laptop forgotten at airport security, or an external drive slipped into the wrong bag, won’t leak a thing without the passphrase. To whoever finds it, the hardware might as well be blank. Compliance . Regulators don’t care whether a breach happened by accident or through theft. Under HIPAA, GDPR, and CCPA, unencrypted data at rest is a violation. With disk encryption in place, the same lost laptop doesn’t trigger fines. End-of-life protection . Old servers and workstations often carry sensitive data long after they’re powered down. Destroying the encryption keys — a crypto-erase — wipes that data permanently. The drive can be resold or recycled without risk. Disk encryption doesn’t make a system bulletproof, but it takes some of the most common and costly risks off the table. Limitations of Disk Encryption While disk encryption is powerful, it’s not a cure-all. Users need to understand its trade-offs to use it effectively. Performance Impact of Disk Encryption on Linux : Disk encryption puts extra work on the system, and the impact shows up differently depending on the hardware. On an older desktop, copying a big folder can feel sluggish. On newer machines, the difference is usually small enough that most people won’t notice. Key Management Risks in Disk Encryption : If disk encryption keys are lost, the data is permanently inaccessible. Weak passphrases or missing backups create the biggest risks. Secure backups and multiple recovery keys are essential so one mistake doesn’t lock out an entire system. Why Disk Encryption Does Not Protect Data in Transit : Disk encryption protects data at rest but not in transit. Once the system is unlocked, files and memory are just as exposed as on an unencrypted machine. Malware and exploits can still steal information or move laterallythrough the network. Disk encryption won’t stop an attacker who steals data after you’ve logged in. Disk encryption does one job well: it protects the files on a drive if the hardware goes missing. Once the system is open and running, though, other risks take over. The risks and downsides of enabling full disk encryption It’s one of the strongest ways to keep data safe at rest — but it’s not without costs. Lose the keys, lose the data. A forgotten passphrase or a damaged LUKS header usually means the drive is gone. Backups are the only safety net. Performance isn’t free. Modern CPUs handle it well. On older hardware or in heavy I/O jobs, you’ll feel the drag. Recovery gets harder. Swapping disks, migrating, or fixing corruption takes more planning when everything is locked. Boot isn’t bulletproof. A misconfigured initramfs or an unsigned bootloader can give an attacker with hands on the machine a way in. Memory can leak. Cold-boot and side-channel attacks are still possible if a device is left sleeping instead of shut down. And once it’s open, it’s open. Malware, phishing, and remote exploits work the same on an encrypted system as they do on any other. Best practice: Back up keys and headers in safe places, use strong passphrases, lock down boot, and shut the machine off when you walk away. Encryption protects the drive itself — the rest still depends on you. Linux Disk Encryption Options in 2025 Linux offers a handful of disk encryption tools, but only a few are still worth using in practice. Tool/Method Best Use Case Pros Cons Status dm-crypt with LUKS2 Default on most distros Strong, well-maintained Some setup knowledge Recommended VeraCrypt Removable or cross-platform media Free, portable Not kernel-native Recommended Enterprise solutions Hybrid cloud / large fleets Centralized key management Cost, added complexity Recommended eCryptfs / loop-AES Legacy systems only Still found in old setups Weak defaults, outdated Avoid For most Linux users, disk encryption through dm-crypt and LUKS2 is the default. It’s built into Ubuntu, Fedora, and Debian installers and works reliably across laptops and servers. VeraCryp t still has a place when drives need to be moved between operating systems. Older tools like eCryptfs or loop-AES are mostly historical; they’re better replaced than deployed. Best Practices for Deploying Disk Encryption Getting the most out of disk encryption depends on how it’s set up and maintained. A few practical steps go a long way. Enable at OS install for a clean deployment. Back up recovery keys securely. Test recovery and crypto-erase before production. Use strong, unique passphrases. Don’t rely solely on FDE — combine with secure boot, patches, and backups. Handled this way, disk encryption stays reliable not just for lost devices, but across the full life of the system. FAQ: Disk Encryption on Linux Does disk encryption slow Linux? On a modern laptop, barely. Most CPUs have built-in instructions that take the load off, so you won’t notice it when browsing or editing documents. Copy a huge folder on older hardware, though, and the slowdown becomes obvious. Do I really need it on a personal machine? Yes. A laptop left in a coffee shop or an external drive forgotten at the office can expose everything on it. Disk encryption makes the device look like random noise until the right key is entered. How is file encryption different from disk encryption? File encryption is pick-and-choose. You decide which documents or folders to lock. Disk encryption covers the whole drive — even swap space and temporary files you never think about. That’s why it’s the standardchoice for Linux systems now. Conclusion: Why Disk Encryption Should Be Your Baseline The case for disk encryption is clear. It keeps stolen laptops from leaking data, meets compliance requirements under HIPAA and GDPR, and makes device retirement safe with crypto-erase. In 2025, linux full disk encryption is no longer optional — it’s expected. Most distributions include it by default, and it’s one of the simplest ways to keep your data safe. . What Is Disk Encryption and Why Does It Matter Disk encryption turns the contents of a drive into un. linux, laptop, recycled, server, drive, everything, system, files. . MaK Ulac
Sep 23, 2025
•
102
security techniquessystem securitykernel hardeningA Master's Guide to Kernel Hardening with GrSecurity and RBAC
Our resident Master's student Gian Spicuzza chimes in this month with a great feature HowTo on Kernel Hardening! There are a number of ways to lock down a system, and RBAC (role based access control) is one of them. Read on to learn more about what makes RBAC so useful, and to read one of the best overviews on Low/Medium/High Security... The combination of the Linux kernel and GNU packages has always been regarded as a secure operating system, but can it be more secure? Kernel hardening is the answer to tightening up the Linux backbone. GrSecurity, a kernel patch for Linux, is one of the more popular approaches... One of the most significant feature is the addition of a role-based access control system (RBAC) that monitors what each user can execute based on their role and denies execution if they overstep their pre-defined rules. . A Quick and Dirty Guide To Kernel Hardening with GrSecurity By: Gian G. Spicuzza ; The combination of the Linux kernel and GNU packages has always been regarded as a secure operating system, but can it be more secure? Kernel hardening is the answer to tightening up the Linux backbone. GrSecurity, a kernel patch for Linux, is one of the more popular approaches. After applying this patch and compiling a fresh kernel, your system will have a plethora of new security features. The most significant feature is the addition of a role-based access control system (RBAC) that monitors what each user can execute based on their role and denies execution if they overstep their pre-defined rules. Other useful features include ip-based rules, extensive chroot restrictions, address space modification restrictions (PaX), auditing/logging features and /proc and dmesg anti-leak features. A full feature list can be found at the Grsecurity homepage. Installing Grsecurity: First we need to download the Linux kernel and Grsec patch. $ wget $ wget For your convenience, the PGP keys are located at: https://grsecurity.net/spender-gpg-key.asc .sign Move the kernel and patch into the /usr/src directory. $ su -c The link for this article located at is no longer available. . Delve into robust strategies for kernel hardening through GrSecurity to elevate system defenses and implement role-centric access management.. Kernel Hardening, GrSecurity, Role Based Access Control, Security Techniques, System Security. . Brittany Day
Dec 20, 2007
•
102
network protectionsystem securityphysical securitySecuring LAMP Stack and Linux Systems: Essential Hardening Techniques
The first installation of a 3 part article covering everything from physical security and service security to LAMP security (Linux Apache MySQL PHP). . Nothing is perfectly secure in this world.But all that one could do is reduce the degree of intrusions by intruders and thereby minimising the security risks . In this article we shall discuss how to secure 'LAMP' LAMP stands for "Linux Apache MySQL PHP" This article is very much useful for those who are interested in developing some web based aplications using PHP as frontend and MySQL as backend with Apache web server On Linux OS. Security in itself is a vast field which is not possible to illustrate in depth here. But here in this article i have made an attempt to cover the basic level of security which must be implemented by one who is keen in security aspects First of all let us know how to secure Linux(here i have considered Red Hat) This involves securing the various servers like FTP,default services like telnet,ftp. BIOS Security Remember always to set a password on BIOS to disallow booting from floppy by changing the BIOS settings. This will block undesired people from trying to boot your Linux system with a special boot disk and will protect you from people trying to change BIOS feature like allowing boot from floppy drive or booting the server without password prompt. All default users and group accounts that you don't use on your system like lp, sync, shutdown, halt, news, uucp, operator, games, gopher etc must be deleted using the command userdel and groupdel : To delete a user account : [root@aquarius /# userdel lp To delete a group: [root@aquarius /# groupdel lp Remember that the minimum length of password by default when you install your Linux system is 5. Its better to have at least 8 characters. You can set this by editing the configuration file for the login program called login.defs. It is located in /etc: /etc/login.defs: PASS_MIN_LEN 8 Enabling shadow password feature is very important. You can use the "/usr/sbin/authconfig" utility to enable the shadow password feature on your system. If you want to convert the existing passwords and group on your system to shadow passwords and groups then you can use the commands pwconv, grpconv respectively. The "root" account is the most privileged account on a Unix system. When the administrator forgets to logout from the system root prompt before leaving the system, then the system should automatically logout from the shell. To do that, you must set the special variable named "TMOUT" to the time in seconds. Edit your profile file "vi /etc/profile" and add the following line somewhere after the line that to read: /etc/profile: TMOUT=3600 The value we enter for the variable "TMOUT=" is in second and represent 1 hours (60 * 60 = 3600 seconds). If you put this line in your "/etc/profile" file, then the automatic logout after one hour of inactivity will apply for all users on the system. You can set this variable in user's individual ".bashrc " file to automatically logout them after a certain time. After this parameter has been set on your system, you must logout and login again (as root) for the change to take effect. You should disable all console-equivalent access to programs like shutdown, reboot, and halt for regular users on your server. To do this, run the following command: [root@aquarius /# rm -f /etc/security/console.apps/ Where is the name of the program to which you wish to disable console-equivalent access. Securing Services Internet and network services are among the most vulnerable parts of your system. Whether you're planning a new installation or reviewing security on an existing system, your file servers, e-mail services, Web servers, FTP, and other network services should be among the first things you check forsecurity holes. Some services will obey the /etc/hosts.accept and /etc/hosts.deny configurations if they've been compiled with the TCP Wrapper library, but not all will. Use the firewall code along with the TCP Wrapper configurations to secure your services. You should disable and uninstall all services that you do not use so that you have one less thing to worry about. Look at your "/etc/inetd.conf" file and disable what you do not need by commenting them out (by adding a # at the beginning of the line), and then sending your inetd process a SIGHUP command to update it to the current "inetd.conf" file. To do this: Change the permissions on "/etc/inetd.conf" file to 600, so that only root can read or write to it. [root@aquarius /# chmod 600 /etc/inetd.conf ENSURE that the owner of the file "/etc/inetd.conf" is root. Edit the inetd.conf file (vi /etc/inetd.conf) and disable the services like: ftp, telnet, shell, login, exec, talk, ntalk, imap, pop-2, pop-3, finger, auth, etc unless you plan to use it. If it's turned off it's much less of a risk. Send a HUP signal to your inetd process [root@aquarius /# killall -HUP inetd Set "/etc/inetd.conf" file immutable, using the chattr command so that nobody can modify that file To set the file immutable simply, execute the following command: [root@aquarius /# chattr +i /etc/inetd.conf This will prevent any changes (accidental or otherwise) to the "inetd.conf" file. The only person that can set or clear this attribute is the super-user root. To modify the inetd.conf file you will need to unset the immutable flag: To unset the immutable simply, execute the following command: [root@aquarius /# chattr -i /etc/inetd.conf or You can type the command linuxconf at the prompt and then select system services which will list all the services running and u canselect the required ones and deselect the unnecessary services. Set up your basic security mechanisms to deny everything unless you explicitly configure it to be allowed. Set the /etc/hosts.allow file to allow localhost only, and set the /etc/hosts.deny file to deny everything else. With that as a starting point, you can decide who and what will be granted which access, and everything else will be blocked. The default should always be "No!" TCP Wrappers By using TCP_WRAPPERS you can make your server secure against outside intrusion . The best policy is to deny all hosts by putting "ALL: ALL@ALL, PARANOID" in the "/etc/hosts.deny" file and then explicitly list trusted hosts who are allowed to your machine in the "/etc/hosts.allow" file. TCP_WRAPPERS is controlled from two files and the search stops at the first match. The first file it parses is the /etc/hosts.allow file. If it doesn't find a match, then it proceeds to the a /etc/hosts.deny file. Edit the hosts.deny file (vi /etc/hosts.deny) and add the following lines: # Deny access to everyone. ALL: ALL@ALL, PARANOID Which means all services, all locations is blocked, unless they are permitted access by entries in the allow file. Edit the hosts.allow file (vi /etc/hosts.allow) and add for example, the following line: Example: ftp: 202.54.15.99 foo.com For your client machine: 202.54.15.99 is the IP address and foo.com the host name of one of your client allowed using ftp. The tcpdchk program is the tcpd wrapper configuration checker. It examines your tcp wrapper configuration and reports all potential and real problems it can find. After your configuration is done, run the program tcpdchk. [root@aquarius /# tcpdchk Telnet and Finger Running telnet , rlogin , or rsh to access your system remotely is not secure as they allow passwords and userids to be "sniffed." For remote access, use secure shell ( ssh )connections and disable all non-encrypted remote access to the server. The ssh package can be downloaded and installed very easily. ssh isn't available on any Linux distribution originating in the United States due to US export restrictions on cryptography. Some distributions from outside of the US do include cryptography modules and applications such as ssh and PGP in the base distributions and installations. finger is often configured and available on default installations. Unless you have a specific need for this service, disable it or restrict network access to it. finger provides far too much information about your users to would-be intruders. It is also instrumental in certain advanced forms of denial-of-service attacks such as "nisnuke" on large networks. Type the command finger and see the output. Finger command gives info on who is currently logged in at what terminals and the timings of login too which is enough for any intruder to attack. Secure Web services If you're running a Web server, check and recheck your CGI scripts. Do not allow other users to install arbitrary CGI scripts. Do not use unrestricted server-side includes (SSIs). IRC is one common example of a chat system -- many other chat systems also work with Web servers. If you have any kind of chat server running on your system, make sure common users can't insert arbitrary HTML (hostile JavaScript anyone?) into pages where your Web server can serve them up. FTP Security If you're operating an anonymous FTP service, watch your permissions closely! Don't allow any directories to be both readable and writable by anonymous users. If you want to permit anonymous uploads to your system, provide a write-only directory and prohibit directory creation underneath it. If you permit a location to be both readable and writable, you not only allow your system to be a "warez" (pirateware) repository, but you also open up your system to being used for "FTP bounce" attacks against other systems. Ifyou're not running anonymous FTP -- make sure you're not. A lot of distributions enable anonymous FTP by default. Secure file serving If you're exporting any filesystems via NFS, SMB, Samba, or anything else, make sure your access permissions are carefully checked. Never run NFS, SMB, or NIS over the Internet. The risk is just too great. NFS in particular uses UDP and depends on peer addresses for authentication and authorization. But peer addresses are trivial to spoof for UDP! E-mail Security If you're running POP or IMAP for remote downloading of e-mail, switch to an SSL-encrypted version. You can use stunnel or edssl to set up SSL-enabled mail servers. Several e-mail clients support SSL POP and/or SSL IMAP, including Netscape and Microsoft Outlook. SSL-enabled fetchmail is available from the North American Cryptographic Archives. If you aren't intending to run POP or IMAP, make sure you really aren't running them. Some distributions enable these by default. Some of the "bad guys" out on the Net are now engaged in massive parallel-port scanning for IMAP servers. If you leave the backdoor open for one of them to get your number, the next time a major root compromise is discovered in IMAP (for example) he or she could promptly come knocking. If you don't know you're running IMAP, you'll have no reason to know when security patches or updates to it become available. Without these upgrades, an intruder could be root on your system before you know what hit you. Disallow root Login From Different Consoles The "/etc/securetty" file allows you to specify which TTY devices the "root" user is allowed to login . Edit the "/etc/securetty" file to disable any tty that you do not need by commenting them out (# at the beginning of the line). Blocking Anyone To su To root The su (Substitute User) command allows you to become other existing users on the system. If you don't want anyone to su to root or restrict "su" command to certain users then add the following twolines to the top of your "su" configuration file in the "/etc/pam.d/" directory. Edit the su file (vi /etc/pam.d/su) and add the following two lines to the top of the file: auth sufficient /lib/security/pam_rootok.so debug auth required /lib/security/Pam_wheel.so group=wheel Which means only members of the "wheel" group can su to root; it also includes logging. You can add the users to the group wheel so that only those users will be allowed to su as root. Shell Logging The bash shell stores up to 500 old commands in the "~/.bash_history" file (where "~/" is your home directory) to make it easy for you to repeat long commands. Each user that has an account on the system will have this file "bash_history" in their home directory. The bash shell should store less number of commands and delete it on logout of the user. The HISTFILESIZE and HISTSIZE lines in the "/etc/profile" file determine the size of old commands the "bash_history" file for all users on your system can hold. I would highly recommend setting the HISTFILESIZE and HISTSIZE in "/etc/profile" file to a low value such as 30. Edit the profile file (vi /etc/profile) and change the lines to: HISTFILESIZE=30 HISTSIZE=30 Which mean, the "bash_history" file in each users home directory can store 20 old commands and no more. The administrator should also add into the "/etc/skel/bash_logout" file the "rm -f $HOME/.bash_history" line, so that each time a user logs out, its ".bash_history" file will be deleted. Edit the bash_logout file (vi /etc/skel/bash_logout) and add the following line: rm -f $HOME/.bash_history Disable The Control-Alt-Delete Keyboard Shutdown Command To do this comment out the line (with a "#") listed below in your "/etc/inittab" file . To do this, edit the inittab file (vi /etc/inittab) and change the line: ca::ctrlaltdel:/sbin/shutdown -t3 -rnow To read: #ca::ctrlaltdel:/sbin/shutdown -t3 -r now Now, for the change to take effect type in the following at a prompt: [root@aquarius /# /sbin/init q Fix the permissions under "/etc/rc.d/init.d" directory for script files Fix the permissions of the script files that are responsible for starting and stopping all your normal processes that need to run at boot time. To do this: [root@aquarius/# chmod -R 700 /etc/rc.d/init.d/* Which means only root is allowed to Read, Write, and Execute scripts files on this directory. Hide Your System Information By default, when you login to a Linux box, it tells you the Linux distribution name, version, kernel version, and the name of the server. This is sufficient information for a crackers to get information about your server. You should just prompt users with a "Login:" prompt. Don't let system issue file to be displayed You should not display your system issue file when people log in remotely . To do this, you can change the telnet option in your "/etc/inetd.conf". To do this change the line in "/etc/inetd.conf": telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd to look like: telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd -h Adding the "-h" flag on the end will cause the daemon to not display any system information and just hit the user with a login: prompt. I will recommend to use sshd instead. Change the "/etc/host.conf" file. The "/etc/host.conf" file specifies how names are resolved. Edit the host.conf file (vi /etc/host.conf) and add the following lines: # Lookup names via DNS first then fall back to /etc/hosts. order bind,hosts # We have machines with multiple IP addresses. multi on # Check for IP address spoofing. nospoof on The first option is to resolve the host name through DNSfirst and then hosts file.The multi option determines whether a host in the "/etc/hosts" file can have multiple IP addresses (multiple interface ethN). The nospoof option indicates to take care of not permitting spoofing on this machine. Immunize the "/etc/services" file. You must immunize the "/etc/services" file to prevent unauthorized deletion or addition of services. To immunize the "/etc/services" file, use the command: [root@aquarius /# chattr +i /etc/services To do this, Edit the "/etc/rc.d/rc.local" file and Place "#" in front of the following lines as shown: # This will overwrite /etc/issue at every boot. So, make any changes you # want to make to /etc/issue here or you will lose them when you reboot. #echo "" > /etc/issue #echo "$R" > > /etc/issue #echo "Kernel $(uname -r) on $a $(uname -m)" > > /etc/issue # #cp -f /etc/issue /etc/issue.net #echo > > /etc/issue Then, remove the following files: "issue.net" and "issue" under "/etc" directory: [root@aquarius /# rm -f /etc/issue [root@aquarius /# rm -f /etc/issue.net Disable Unused SUID/SGID Programs A regular user will be able to run a program as root if it is set to SUID root. A system administrator should minimize the use of these SUID/GUID programs and disable the programs which are not needed. To find all files with the `s' bits from root-owned programs, use the command: [root@aquarius]# find / -type f \( -perm -04000 -o -perm -02000 \) \-exec ls lg {} \; To disable the suid bits on selected programs above, type the following commands: [root@aquarius /# chmod a-s [program] Roopa Rannorey Roopa has been in the IT field in Karnataka, India for about three plus years. Her interests include Linux Security and Networking and she has been at them for a while.. Minimize security threats byimplementing robust tactics for LAMP stacks and fortifying your Linux environment to improve overall safety.. LAMP Security, Security Measures, Network Hardening. . Brittany Day
Nov 12, 2002
•
102
security advisorysystem securityUNIXImplementing Chroot for Security and Process Isolation Techniques
The chroot() function can be a powerful mechanism to secure your system, but only if used correctly. Anton provides a good foundation for implementing it in your programs and services running on your system. . C hroot command and chroot system call might sound like a good security measure - one command executed and plain old UNIX "cd /" no longer transports you to a root directory of the system. Instead, you are bound to stay in the restricted part of the filesystem, surrounded only by files chosen by a paranoid system administrator. In fact, that is how it should be. Is it possible to break out of chroot solitary confinement? Yes, if certain conditions are met. In this paper we will analyze what chroot is good for and also what chroot is bad for. First, how does it work? When one types /sbin/chroot directory_name on the UNIX system command line one sees that the new root is now 'directory_name' (the /bin/ls / command produces the listing of files from 'directory_name' presuming that you have an 'ls' command located within your new root). Chroot shell command changes the root directory for a process, goes into this directory and then starts a shell or a user-specified command. Chroot command uses a chroot() system call. The command and the system call have an important difference between them: unlike the shell command, chroot() call does not change your working directory to the one inside chrooted jail. The source of chroot.c (shell command, in Linux part of sh-utils) shows the following sequence of system calls: chroot (argv[1]); chdir ("/"); As will be seen further, it will allow for easy chroot jail breaking. Chroot is often used as a security measure. If one has ever used an anonymous ftp server, one has used chroot. Ftp server chroots itself into a special directory upon the anonymous ftp login. DNS (Domain Name System) daemon bind is often chrooted as well. People also suggested chrooting telnet/ssh remote shell users into their corresponding home directories, so theycan only update their web pages. Web servers can be run chrooted too. Smap secure email wrapper from FWTK firewall tool kit runs chrooted to the mail spool directory. When chroot is implemented, programs running inside cannot access any system resources on the outside. Thus all system libraries, configuration files and even devices files should be recreated within the chroot jail. What daemons can be chrooted? If a daemon has to access files that are not easily collectible in one place, chrooting it will be hard. For example, sendmail needs mail spool ( /var/spool/mail ), other files in spool (such as mqueue), user's home directories (to check for .forward files) and system configuration files in /etc . There is no place on the filesystem where sendmail can be effectively confined. Of course, some makeshift solution is possible, but it is not clear that it will add to security, but rather cause it to lax. If sendmail functionality is separated into spool daemon and mail transfer program (like done in FWTK smap and smapd), than chrooting is entirely possible. Chrooting shell users is possible if there is a business need to keep them in some particular directory. However, it might involve copying multiple system libraries, files and other resources such as Linux Pluggable Authentication Modules (PAM) architecture, used by most modern Linux distributions. Anything else such as bind, apache, squid can be chrooted, but sometimes the benefits are unclear, especially for daemons that run as root. This URL ( ) provides a nice list of daemons that its author chrooted successfully. "What daemon should be chrooted?" is an entirely different question from "What daemons can be chrooted?" Before we answer it, lets analyze how attackers break out of chroot. First, the more software is deployed within chroot environment, the more dangerous it becomes, since it is hard to keep track of programs that can be used by the attacker to elevate permission and escape. Second, the number of ways that root user can breakout of chroot is huge. Starting from simple use of a chroot() call with no chdir() [see code below] to esoteric methods as the creation of your own /dev/hda or /dev/kmem devices, injection code into the running kernel ( ), using open directory handles outside chroot or chroot-breaking buffer overflows. While system capabilities can be used to render inoperable many of these methods, new ones will likely be found by smart attackers. Sample code to break out of chroot: #include #include #include #include #include int main(void) { int i; mkdir("breakout", 0700); chroot("breakout"); for (i = 0; i < 100; i++) chdir("..") ; chroot("."); execl("/bin/sh", "/bin/sh",NULL); } compile statically (using "gcc -static") and run within chrooted directory (after doing "chroot ." or similar from shell prompt) to escape. Third, if there is no root user defined within the chroot environment, no SUID binaries, no devices, and the daemon itself dropped root privileges right after calling chroot() call (like in the code below), breaking out of chroot appears to be impossible. In other words, if there is no way to gain root shell or perform actions that only root can usually perform (e.g. create devices, or access raw memory) breaking chroot is not clearly possible. Ideally, if the custom software uses chroot for security the sequence of calls should be: chdir("/home/safedir"); chroot("/home/safedir"); setuid(500); Keep in mind, that after these lines are executed there will be no way for the program to regain root privileges. Fourth, in some cases attackers might not be able to break (i.e. run processes outside of chrooted directory), but instead will be able to somewhat affect such processes. For example, if bind is chrooted, several devices should be created. One of them is /dev/log , necessary for logging bind messages into the regular system logs. By crafting a malicious log message and sending it into /dev/log from within the chrooted directoryattacker will influence the behavior of syslog daemon running outside the chroot. If there is a buffer overflow in syslog (which runs as root), additional privileges can be obtained. What daemons can be chrooted but with no valuable security outcome? In light of the above, chrooting programs that do not drop root privileges while running, or programs that provide root shell access ( sshd , telnet with a root account within chrooted directory) does not provide any extra security. To conclude, chroot() is a good way to increase the security of the software provided that secure programming guidelines are utilized and chroot() system call limitations are taken into account. Chrooting will prevent an attacker from reading files outside the chroot jail and will prevent many local UNIX attacks (such as SUID abuse and /tmp race conditions). References Secure Programming HOWTO -- This book provides a set of design and implementation guidelines for writing secure programs for Linux and Unix systems. Such programs include application programs used as viewers of remote data, web applications (including CGI scripts), network servers, and setuid/setgid programs. Specific guidelines for C, C++, Java, Perl, PHP, Python, TCL, and Ada95 are included. Chroot-BIND HOWTO -- This document describes installing the BIND 8 nameserver to run in a chroot jail and as a non-root user, to provide added security and minimise the potential effects of a security compromise. Linux Security QuickReference Card -- This Quick Reference Guide is intended to provide a starting point for improving the security of your system. Contained within include references to security resources around the net, tips on securing your Linux box, and general security information. Linux Security Documentation -- Linux Security documentation starting point. WWW Security FAQ -- Steps on chrooting the Apache Web server. Securing and Configuring Postfix HOWTO -- General steps on securing thepostfix mail server, including how to configure it to run in a chroot. Debian Security HOWTO -- Debian security checklist including programs to be chrooted. Chrooting All Services in Linux -- Good starting point to explain the basics of using chroot() but be sure to heed the instructions provided in this article before chrooting all services running on your system. About the Author Anton Chuvakin, Ph.D. is a Senior Security Analyst with netForensics, a security information management company that provides real-time network security monitoring solutions. . Chroot command and chroot system call might sound like a good security measure - one command execute. chroot(), function, powerful, mechanism, secure, system, correctly. . Anthony Pell
Feb 10, 2002
•
102
security advisoryintrusion detectionRed HatCylant 0wn This Box Challenge Overview: Unique Security Experiment
Cylant's "0wn this box challenge" is a research effort providing a good challenge to skilled crackers. Dave Wreski and Benjamin Thomas of LinuxSecurity.com interview Cylant Technology, Inc. seeking to find more information regarding the work to create this contest, and the experiences gained from holding it. . The victim system has been setup using a Red Hat 6.2 machine with every possible service and package installed. Unique about this contest is that Cylant is not a security company. They are a behavioral measurement and control company. They believe they have a product that can monitor the behavior of a system, and use this information to counteract the actions of an intruder not determined to be normal behavior. Behavior is monitored using the reports generated by CylantSecure for Linux. The successful cracker will receive the actual victim box which sports a 850 MHz Athlon, 256 MB Ram, 20 GB disk, and ATI Rage 128 video card. Good luck to those who try! LinuxSecurity.com: What is Cylant trying to show by allowing people to attack your server? Cylant: We are demonstrating one of the capabilities presented through execution behavioral measurement and control. Other security systems rely on either specific or general knowledge about attacks, our approach is very different. We calibrate the system for its normal behavior. In the case of victim.cylant.com , the normal behavior of a web server and some standard system administration activity are what constitute normal behavior. The behavior of the system is compared in real-time against the behavior expressed by the baseline. CylantSecure, which is the only thing securing victim, is a demonstration of the behavioral measurement technology that we have developed. Victim demonstrates that this technology is not only viable, but directly applicable when it comes to rejecting intrusion attempts. The core technology is described here: LinuxSecurity.com: Do you seethis as another 'Hack This Box' contest? Cylant: To a certain extent this is exactly another 'Hack This Box' contest. The nature of the target box sets this apart. First, victim represents every security admin's nightmare. Most of the running services have known exploits. Further, victim is running many unnecessary services. This doesn't seem to be the nature of most target systems in 'Hack this Box' challenges. Secondly, the system securing the box knows nothing about security or the vulnerabilities in the software running on victim. This system is the first we know of that uses execution behavioral measurement. This approach is not dependent on signatures or rule-sets that must be constantly updated to keep current with newly discovered vulnerabilities. There is one fundamental similarity, eventually somebody will succeed. Given the massive misconfiguration of the box, it is inevitable that somebody will successfully own victim. Our interest is in discovering the resolution limitations in CylantSecure's default settings in a very hostile environment. [UPDATE] Victim was hacked by some of my old co-workers at EarthLink/Mindspring. They succeeded in part because of a bug we found today in CylantSecure. We have fixed the bug and issued round two of the challenge. Part of the challenge for us, was watching this attack proceed over a period of hours. Not deleting a setuid shell for hours was kind of hard to do. Same challenge, same goal, but this time the CylantSecure isn't having suicidal tendencies. For details on the bug, see: LinuxSecurity.com: What kernel modifications have you made? Cylant: First, let me state that the source code for the modified kernel is available on our web site. Hat/kernels/ The kernels for the Advanced and SOHO versions are contained in the downloads for those products. Activation for SOHO and Advanced requires a license key. We changed the kernel source in four ways. First, weinserted about 3300 points of instrumentation throughout the source for the kernel. These instrumentation points are the source of the execution behavioral data that we both store into the baseline and measure. Secondly, we have added a few elements to the task_struct and sk_buff structures in the kernel. We use these to identify the cause of the behavior we are seeing at the instrumentation points. Thirdly, we have added code to start the profiling process when a process is execed or an IP packet is handed from the device driver to ip_rcv(). And finally, we have added a quick check in ip_rcv() against a table of banned IP addresses. This lets us drop packets from banned hosts very early. LinuxSecurity.com: What other changes have been made? Cylant: We load kernel modules that gather the instrumentation data into profiles and ship it on to our statistical engine. LinuxSecurity.com: What are the other components of your product? Cylant: We have a user land daemon that is essentially a multiplexor. It takes incoming behavioral profiles and passes them to the statistical engine for measurement against the baseline. There is also a management console which provides running reports and configures the CylantSecure core. Communication with the console happens through SSL. LinuxSecurity.com: Why did you choose Linux? Cylant: We chose Linux for a number of reasons. The principle reason was that it was a sufficiently large and complex piece of software. The core technology is applicable to any piece of software. The Linux kernel provided a good demonstration ground. Implicit in this is the fact that the source was available for us to instrument. We chose Linux over other open source operating systems because it has the most mind share. We chose to instrument a kernel because doing so imposed a high reliability requirement on the instrumentation and profiling process we developed. Debugging kernel crashesmight be a real pain, but you have a real hard time labeling the bug a "feature" and going on with the day. When instrumenting other applications, such as apache, we didn't have to deal with such a high reliability requirement. Another benefit of choosing a kernel was that it reduced the amount of options we had in terms of behavioral profiling. This refers to the number of different ways of attributing behavior to its cause. For example, activity in the IP stack can be "blamed" on the source IP and port in the packet traversing the stack. Behavior underneath the system calls can be tagged with the process ID in the task structure passed in and out of these functions. Naturally, you can spoof IP addresses and have the system not know the real cause of the behavior. I don't know of a good way around that other than getting access points to fix their ACLs. LinuxSecurity.com: Your victim.cylant.com page indicates that if your software detects anomalous behavior, the process associated with it will be killed. What is the definition of anomalous behavior? Cylant: Anomalous and normal behavior are a function of the role a system has been deployed in. For victim, the normal behavior is serving web pages. Additionally, it is normal for system administrator to be tailing log files, and building the auto-generated portions of the victim site. That is pretty much the extent of "normal" behavior. Abnormal behavior is anything else. The difference between normal and abnormal is not a bold black line though. What is really of interest is the difference between normal behavior, and the behavior currently occurring. This is where the behavioral measurement aspect of our approach applies. We set thresholds on the allowed difference from normal; anything over the thresholds is stopped. For victim we have set these thresholds rather low. LinuxSecurity.com: How much overhead is associated with your approach? Cylant: Typically the overhead is lessthan 1%. At times, the overhead can have as much as a 5% impact on the performance. The advanced version has a 40 MB memory footprint. The memory footprint is large because that is where the profiles are generated by the kernel. In the SOHO version of watcher, the memory footprint is less than 10 MB since it profiles less concurrent behavior. LinuxSecurity.com: What other applications do you think your software has? Cylant: Our background is in the area of software reliability. The behavioral measurement technology was developed to measure the reliability of running software. By generating the baseline during testing, you can tell if the software is being used in a tested manner. This lets you create a set of certified behavior for a system, and know when the system departs from this behavioral set in the field. Additionally, if the cause of the behavior can be determined, the behavior could be stopped. Ideally a truly hardened software system would actively work to keep the execution behavior within both a defined normal behavioral set, and a defined certified behavioral set. LinuxSecurity.com: What is the average amount of time that you believe a person will spend trying to compromise your system? Cylant: It depends on how determined the attacker is. We have had some people try for several hours, and others try for multiple days. On the other hand, I suspect that some people have given up after their first try. A full analysis of the logs would be required to really know for sure. The spoofable nature of IPv4 makes even the log analysis less than 100% reliable for determining this. LinuxSecurity.com: How closely do you monitor their actions? Cylant: The answer sort of depends on what is meant by "you". CylantSecure monitors essentially all the behavior their actions induce on the kernel. Humanly, we don't pay that much attention to victim. We tend to watch the page just to see what people have been trying to do.Periodically we check to see if somebody has created an /etc/owned_ file. That is about all we are doing in the way of monitoring attacks against victim. This lack of observation really stems from our goal of wanting to create a simple means for people to protect their servers from attacks. If we had to watch victim like a hawk, then we would not really have accomplished anything with CylantSecure. LinuxSecurity.com: How much detailed information will be made publicly available if the system is compromised? Cylant: We are going through the log files right now to put together a trace from the successful compromise by the EarthLink/MindSpring group. The information they provided about their method has helped us track their activity through the log files. We will be releasing all of the information we have garnered from the log files relating to their successful attack. LinuxSecurity.com: What do you believe the most common method people will use to find vulnerabilities on your system? Cylant: We have spent a fair amount of time thinking about how to circumvent our techniques. The first way that comes to mind is loading kernel modules that overwrite the instrumentation functions implemented by our kernel modules. Having our modules be the last ones loaded and disallow any further module loads would get around this vulnerability. The other mechanism which would work would be to kill the watcher daemon. The mathematical comparisons are done in watcher, so killing it would removed the protection provided by CylantSecure. In fact, a bug in our policy code which caused watcher to kill itself is what allowed the EarthLink/MindSpring team to successfully compromise the first victim. The CylantSecure kernel modules capture a certain amount of behavioral data before the profile is shipped on to watcher for measurement against the behavioral baseline. An attack that does not induce enough behavior to cause a profile to beemitted would be undetected. The dump interval is configurable to reduce this window. However, the current settings seem to be sufficiently low to spot and stop attacks. LinuxSecurity.com: Do you have any experience with previous intrusions, if so, how did it occur? Cylant: So far, intrusions have only happened when CylantSecure was exhibiting suicidal tendencies. That is the limit of our experience with successful intrusions. LinuxSecurity.com: What are some of the most creative ways people have tried to exploit your system, or any other that you may have had experience with? Cylant: Our way of securing systems doesn't really know "how" people are trying to exploit the system. Our view of the attacks is in terms of their "distance" from the normal behavior baseline. During this challenge, we have seen some seriously large distances. The normal behavior has a distance that is under .001; most of the attacks have a distance a full order of magnitude greater than that. On a couple of occasions we have seen attacks that have distances over 2; three full orders of magnitude greater than the distances for normal behavior. LinuxSecurity.com: Would you be willing to make the configuration changes that have been made from the default install available so one might set up a similar environment locally to test? Cylant: Certainly. We did an "Everything" install of Red Hat 6.2. Installed CylantSecure:LKP Advanced with the 2.2.18 kernel. Put a test web site on victim. Request pages from the test web site. Turn on nearly every service listed in inetd.conf. Setup cron jobs to restart services that get killed. Setup cron jobs to build log summary files. Setup a cron job to force httpd and inetd to be restarted. LinuxSecurity.com: What modifications are necessary to be made when new software is added or removed from the system? Cylant: If the new softwareuses the system in a different manner, then its behavior will need to be added to the calibration set, or a separate sub policy will need to be made for it. We do not yet have a tool for adding behavioral profiles into the calibration data without putting the resource back into profile gathering mode. We are working on tools to do this. LinuxSecurity.com: How much administrative overhead is involved? Cylant: For systems that are not constantly having new software installed on them there is very little maintainance. For systems that have new software installed on them regularly, the administrator will have to spend time updating the calibration set with the behavior for the new software. We feel that victim is representative of some of the worst possible conditions for an administrator, and our sys admin is not spending very much time working with CylantSecure. He does, however, counsel against running a hacking challenge. Especially one where the target box is massively vulnerable. LinuxSecurity.com: Did your old co-workers at EarthLink/Mindspring that cracked the box the first time have any previous knowledge about the configuration of the system? Cylant: No. They simply knew about a known password problem with Pirahna in the default Red Hat 6.2 configuration. They were the first of multiple people who attempted access victim this way. After they got in, they promptly changed the password. This kept them from being bothered, and resulted in more than one person asking if we had changed the password to the 'pirahna' account. LinuxSecurity.com: Would it have done any good had they had a map of the product configuration changes? Cylant: Not likely. We disclose the relevant configuration information on the web site on victim. People can see what services are running on victim. We have added the output from `rpm -qa` to the site just to help people more. At it's heart, CylantSecure is a tool for spottingand stopping new exploits and attacks. It does this by effectively representing the allowed normal system behavior. Therefore, the existence of vulnerabilities in installed software is something we take for granted. We simply enforce the behavior exhibited during calibration. As a consequence of CylantSecure being more of a behavioral measurement and control product than a security product, have you gained any additional knowledge about the thought process and methods of the typical attacker? We have observed that the processes used by attackers tend to be very noisy from a behavioral measurement point of view. Mostly what we have learned is that the current methodologies are not designed with circumventing behavioral measurement in mind. Since we are the first people doing behavioral measurement, this is not real surprising. LinuxSecurity.com would like to thank Cylant, Inc. for having this interview. We look forward to seeing your future projects, articles, and contributions to Linux and security.. Dive into the Cylant challenge showcasing innovative security methods on a fully active Red Hat machine.. Cylant Security Challenge,Behavioral Monitoring,Red Hat Security Techniques. . Brittany Day
May 10, 2001
•
102
risk managementsoftware patchsecurity best practicesRamen Worm Analysis: Risks and System Security Improvements
This article outlines the importance of monitoring vendor advisories and applying appropriate software patches when necessary. It uses the Ramen epidemic as an example showing the possible effects of poor system administration. . Whether you're a security professional, system administrator, or average Linux user you've probably already heard many of the stories surrounding the recent outbreak of the Ramen worm. If you haven't heard the details, or would like an overview of the specifics, you may want to skip down to the middle of this paper. I have answered some of the most common questions and provided specific information on how to prevent and disable the worm as well as how it works. Ramen does not only exploit vulnerabilities in wu-ftpd, nfs, and LRPng, it takes advantage of lazy/inattentive/irresponsible/naive system administrators. In this paper I answer many questions. What actually enabled the Ramen worm to be so successful? Who's responsible? What knowledge can we take from this situation? Maintaining a secure network can be broken up into 4 abstract parts: 1. Know your system 2. Be proactive 3. Update when necessary 4. Educate yourself Know your system - One of the most important factors of maintaining a system is knowing what you have. This often means reading documentation completely before installing, understanding all configuration options, and being aware of any risk that a particular package may incur. If you do not have a specific need for a package or service, then by all means remove it. Packages just lying around should be considered a threat and removed immediately. An administrator should be aware of all executables, configuration files, processes, users, and normal system operation. Know your system intimately! The Ramen worm is a great example showing how package negligence can lead to vulnerabilities. This particular worm attacks nfs, wu-ftpd, andLPRng, but it might as well have been a samba exploit in a general case. The specific vulnerable packages do not matter, it is the attitude of the administrator. I would be willing to bet that in most cases where there was a compromise the vulnerable services were not in use. Most users install Linux using an "out-of-the-box" configuration leaving the door wide open to compromise. Most distributions require a small bit of configuration before actually being ready for the Internet. Too often, unskilled users put boxes up not knowing what kind of significant effect it can have. This is a problem that will continue until vendors put more emphasis on a secure default configuration. Many times users will ignore warnings given simply because they do not maintain a high-profile server or have a connection faster than dialup, cable, or DSL. Proper precautions should still be taken because privately owned systems are often used as stepping stones to attack larger servers. By not updating regularly, you are contributing to the problem. Be proactive - Having a cut down Linux box is a good first step, but that does not eliminate the problem. It is necessary to monitor vendor advisories from the packages and distributions that you are using. Again, knowing your system is helpful. What packages do you have installed? Many system administrators have trouble managing advisories, keeping up with the lists, and following through. We have tried to make this process easier for you. For those of you who are not aware, we release a weekly vulnerability newsletter " Linux Advisory Watch ." Linux Advisory Watch is comprehensive newsletter that outlines the security vulnerabilities that have been announced throughout the week. It includes pointers to updated packages and descriptions of each vulnerability. Update when necessary - If no steps aretaken to fix known problems then the system is still vulnerable. Often, administrators will read new vendor advisories, but then get distracted performing other tasks. The system then sits idle and remains vulnerable until a new release of the distribution is installed. The process repeats itself. Advisories are often numerous and annoying. This is why it is necessary to have the minimum amount of packages installed. It should be your sole purpose in life to make sure that vulnerable packages are patched as soon as an advisory is released. If you are/were vulnerable to the Ramen worm, a general updating scheme could have eliminated that risk. Advisories dating back to June 2000 provided fixes to today's Ramen worm problem. Who's fault it that? If not this time, it will be the next. Staying current is extremely important. At times there may be situations when a patch is not available and you want to limit the impact of a vulnerability that may arise. Something as simple as: ipchains -A input -i eth0 -p tcp -s 0/0 -d 192.168.1.1 21 -j DENY ipchains -A input -i eth0 -p tcp -s 0/0 -d 192.168.1.1 23 -j DENY can be used to restrict access to telnet and ftp from the external interface. Although beyond the scope of this paper, ipchains should play an important roll in your configuration. Educate yourself - When you have time on your hands, it can be best spent reading articles and white papers that describe how to build and maintain secure networks. Where can you find good papers? Each week, in the "Linux Security Week" newsletter, LinuxSecurity.com outlines the best two or three articles/papers released. An archive of releases can be found here: LinuxSecurity News Education will help you avoid falling into problems that other people have faced. Security requires experience and often a bit of creativity. What else can be done? Testing your system often revealsvulnerabilities that you may not have been aware of. Here is an excellent paper on NMAP that can get you started. Red Hat users may want to consider using up2date (Red Hat Update Agent), a program that initiates an interactive process to easy apply the appropriate RPMSs to a system. The Ramen worm was successful because of a few factors. Lack of system knowledge Systems are installed using all default values not giving the configuration any thought Passive Administrators Advisories are not monitored and taken into consideration Failure to see significance. Vendor Advisories should be held in high regard and taken seriously Education Security requires constant learning. How can you prepare for new vulnerabilities? What is the Ramen Worm? The 'Ramen worm' is a set of scripts written to propagate by compromising vulnerable systems, downloading itself, and then using the compromised host to search for other systems to attack. After the system is compromised, the script replaces all files named 'index.html' with the text "Hackers looooooooooove noodles" and a picture touting their favorite snack, "Top Ramen." After the damage has taken place the scripts seemingly close the vulnerabilities (only disable FTP) to prevent the server from future Ramen attacks or looting script kiddies. What systems are vulnerable? Red Hat 6.2 systems not patched for wu-ftp for nfs vulnerabilities and Red Hat 7.0 systems not patched for LPRng are vulnerable. Although Red Hat is the only distribution specifically mentioned, other distributions (especially those based on Red Hat) that distribute these packages are also at risk. What exactly does the Ramen Worm do? do { Initially after a system has been compromised, the Ramen worm starts scanning forsystems with port 21 (common port used for FTP) open. The scripts then grab the FTP banner and use the version and date information to determine which vulnerability would most likely exist. After a system is exploited it creates a directory "/usr/src/.poop" and requests a copy of itself (ramen.tgz) for download through its own port 27374. It then changes every instance of "index.html" found on the system. } while (NETWORK_CONNECTION); How can it be prevented? After reading the text above, you should probably already know the answer to this question. In short, get to know your system, remove what you don't use, and update what you do use. Currently the Ramen worm targets Red Hat systems running LPRng, wu-ftp, and nfs. Red Hat 6.2 - wu-ftpd 6/23/2000 23:14 : Red Hat: wu-ftpd update Red Hat Advisories rpm -Uvh Red Hat 6.2 - nfs-utils 7/17/2000 23:19 : Red Hat: Updated package for nfs-utils available Red Hat Advisories rpm -Uvh 7/21/2000 13:32 : Red Hat: UPDATE: nfs-utils vulnerability Red Hat Advisories Red Hat 7.0 - LPRng 09/26/2000 13:28 : Red Hat: 'LPRng' vulnerability Red Hat Advisories rpm -Uvh How do I detect and remove the worm? Max Vision has written an excellent paper that describes the makeup of the Ramen Worm in great detail. It is titled "Ramen Internet Worm Analysis" and is located here: He offers a detailed section on removal and incident recovery. Here is the method that he outlines for removal. If you have any questions or have the curiosity to want to know how the scripts actually work I would highly recommend reading his paper. If you want to allow anonymous FTP, then remove "ftp" and "anonymous" from /etc/ftpusers If you use wu-ftpd thenupgrade to the latest version from the Red Hat errata web site If you use NFS then upgrade to the latest version from the Red Hat errata web site If you use LPRng then upgrade to the latest version from the Red Hat errata web site Remove "/usr/src/.poop/start*.sh" from /etc/rc.d/rc.sysinit Delete the /usr/src/.poop directory containing worm files Delete /tmp/ramen.tgz Delete /sbin/asp Change /etc/xinetd.conf or /etc/inetd to no include /sbin/asp Red Hat 6.2: Remove "asp stream tcp nowait root" from /etc/inetd.conf Red Hat 7.0: Remove asp entry from /etc/xinetd.conf Restore /etc/hosts.deny unless you didn't use tcp wrappers Restore any replaced index.html files with originals from backup Reboot the system to kill active worm daemons . Tracking supplier alerts is crucial for maintaining protection and reducing threats linked to the Sushi malware incident.. Ramen Worm, Software Patch Management, Risk Mitigation, System Security, Linux Administration. . Brittany Day
Jan 29, 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