Linux Security for Beginners
Security is one of the biggest issues on the Internet today. It affects everyone in one way or another. If you use Linux, it should be a big concern to you. You may think security is for system administrators managing 20 or more machines and not for the average user with a simple PPP link to the Internet. This may in fact be true, for the chances of anything happening are rare. Are you willing to take a chance and trust the security of your system right out of the box?
Ignorance on your part may turn into a powerful tool in the hands of a cracker willing to compromise your system. Is knowing every in and out truly necessary to keep your system secure enough for safe usage? Not really, but one of the best things you can do is become aware of what is available. Many people are intimidated by the subject, since it covers a wide area, but you don't have to be a security guru to be safe. On the other hand, you do need to be willing to get your hands a little dirty.
Before talking about security, the basic underlying principles of the TCP/IP protocol suite must be understood. There are two parts to TCP/IP: tcp and udp. I won't go into great detail about the difference between them—mainly, tcp is connection-oriented and udp is connectionless. Both have their advantages and disadvantages, and both are used differently.
These two protocols are the underlying base for applications run over TCP/IP networks. Each machine connected to a TCP/IP network has its own IP address to uniquely identify it. Each application has its own port number on that IP address. A normal connection to the Internet is no different, since it could be considered a giant TCP/IP network. The two files which govern an application's port and protocol are /etc/services and /etc/protocol. The first, /etc/services, identifies the machine's services and the port number and protocol for each particular service. The second file, /etc/protocol, simply identifies the protocols used in /etc/services.
These two files identify only each service, its port number and its protocol. Where is the application? Instead of having an application running in the background listening for its respective port and protocol and perhaps generating hundreds of daemons, we have only one: inetd. inetd listens for each service, and when it notices a remote host making a call, it spawns the application bound to that port number. How does inetd know which application goes with which service? It uses its configuration file, /etc/inetd.conf. This file matches the service found in /etc/services with an application found on the system.
For example, let's take a look at a small chunk of that file:
ftp stream tcp nowait root /usr/sbin/ftpd in.ftpd\ -l telnet stream tcp nowait root /usr/sbin/telnetd\ in.telnetd finger stream tcp nowait bin /usr/sbin/fingerd\ in.fingerd
You may be familiar with some of these common Internet applications. But what does all this mean? Beginning with the first column, the variables correspond to the service, the socket type (depends on tcp or udp), the protocol to be used, wait or nowait (depends on tcp or udp), user field, the application or server to be called, and the arguments passed to the application.
Where is the security problem in all this? All of these services offer some kind of access to your system and are the principal means by which a cracker can compromise your system. How do we police it? Let us look again at the fields of the code chunk shown above. The first field, representing the service, can be understood with common sense. If you won't be using that service, there is no reason to offer it. If no one besides yourself will be using your box, comment the line out of your /etc/inetd.conf file. The same thing applies to those services that run independently of inetd, such as web servers (httpd) and mail servers (sendmail). Each has its own daemon running in the background which must be killed to eliminate them as potential security risks.
The next field of concern is the user field. Run applications under the least privileged user possible. If an application doesn't require root to run properly, don't run it with root privileges.
The last field of concern is the most important for those services you do require to be available. My example above works fine when offering those services, but inetd doesn't give you much control. A far better alternative comes with most Linux distributions: tcpd. This daemon wrapper is executed instead of your usual server application, and offers far more protection. It will log requests for services to syslog, and it can allow and deny hosts based on rules specified in the /etc/hosts.allow and /etc/hosts.deny files. The rules can do very complex things you wouldn't normally be able to do, such as allowing or denying certain services for certain hosts. It can also trigger applications based on access of services or requests by remote hosts. The list of possibilities is endless. Details on this subject can be found in the August 1997 Linux Journal (issue 40) in the excellent article entitled “Wrap a Security Blanket Around Your Computer” by Lee Brotzman. Many security and administration books covering this subject are also available.
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- Designing Electronics with Linux
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Dynamic DNS—an Object Lesson in Problem Solving
- Validate an E-Mail Address with PHP, the Right Way
- What's the tweeting protocol?
- Mediated Reality: University of Toronto RWM Project
- New Products
- Using Salt Stack and Vagrant for Drupal Development
- Dart: a New Web Programming Experience
- OpenOffice.org Off-the-Wall: ToCs, Indexes and Bibliographies in OOo Writer
34 min 41 sec ago
- Kernel Problem
10 hours 37 min ago
- BASH script to log IPs on public web server
15 hours 4 min ago
18 hours 40 min ago
- Reply to comment | Linux Journal
19 hours 12 min ago
- All the articles you talked
21 hours 36 min ago
- All the articles you talked
21 hours 39 min ago
- All the articles you talked
21 hours 40 min ago
1 day 2 hours ago
- Keeping track of IP address
1 day 3 hours ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?