Network Security with /proc/sys/net/ipv4

In additional to firewall rulesets, the /proc filesystem offers some significant enhancements to your network security settings. Unfortunately, most of us are unaware of anything beyond the vague rumors and advice we’ve heard about this beast. In this article, we’ll review some of the basic essentials of the /proc/sys/net/ipv4 filesystem necessary to add to the overall network security of your Linux server.

/proc/sys/net/ipv4

Perhaps one of the more frequently neglected areas of firewall configuration involves the /proc filesystem. The pseudo file structure within proc allows you to interface with the internal data structures in the kernel, either obtaining information about the system or changing specific settings. Some of the parts of /proc are read-only, while others can be modified. It is often referred to as a virtual filesystem in that it doesn’t take up any actual hard drive space; files are created only on demand when you access them. In this article, we will be focusing specifically on /proc/sys/net/ipv4.

In order to benefit from the use of the /proc filesystem, you’ll need to enable two settings when building your kernel. CONFIG_PROC_FS is the setting that allows you to access and view the /proc filesystem, and CONFIG_SYSCTL is the bit that actually allows you to modify /proc entries without requiring a reboot of the system or a recompile of the kernel. Settings are only available at boot time after the /proc file system has been mounted.

ICMP Specific Settings

Ping scanning is typically used to determine which hosts on a network are up. Typically this is done by sending ICMP ECHO request packets to the target host. This is seemingly innocent behavior, however often network administrators will block such traffic to increase their obscurity. The choices involve blocking ICMP ECHO requests to broadcast/multicast addresses and directly to the host itself. To enable protection against both types of ICMP ECHO requests, use the following commands:

echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_all

ICMP redirect messages can also be a pain. If your box is not acting as a router, you’ll probably want to disable them:

echo "0" > /proc/sys/net/ipv4/conf/all/accept_redirects

Sometimes you will come across routers that send out invalid responses to broadcast frames. This is a violation of RFC 1122, “Requirements for Internet Hosts — Communication Layers”. As a result, these events are logged by the kernel. To avoid filling up your logfile with unnecessary clutter, you can tell the kernel not to issue these warnings:

echo "1" > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses

IP Specific Settings

Ironically, IP forwarding of packets between interfaces is enabled by default on many systems in their startup scripts. If you’re not intending for your box to forward traffic between interfaces, or if you only have a single interface, it would probably be a good idea to disable forwarding. Note that altering this value resets all configuration parameters to their default values; specifically, RFC1122 for hosts and RFC1812 for routers. As a result, you’ll want to modify this one before all other /proc settings.

if [ -r /proc/sys/net/ipv4/ip_forward ]; then echo "Disabling IP forwarding" echo "0" > /proc/sys/net/ipv4/ip_forward fi

If instead you decide to enable forwarding, you will also be able to modify the rp_filter setting; something which is often misunderstood by network administrators. The rp_filter can reject incoming packets if their source address doesn’t match the network interface that they’re arriving on, which helps to prevent IP spoofing. Turning this on, however, has its consequences: If your host has several IP addresses on different interfaces, or if your single interface has multiple IP addresses on it, you’ll find that your kernel may end up rejecting valid traffic. It’s also important to note that even if you do not enable the rp_filter, protection against broadcast spoofing is always on. Also, the protection it provides is only against spoofed internal addresses; external addresses can still be spoofed.. By default, it is disabled. To enable it, run the following:

if [ -r /proc/sys/net/ipv4/conf/all/rp_filter ]; then echo "Enabling rp_filter" echo "1" > /proc/sys/net/ipv4/conf/all/rp_filter fi

You may have also noticed the “all” subdirectory in this last example. In /proc/sys/net/ipv4/conf there is one subdirectory for each interface on your system along with one directory called “all”. Changing specific interface directories only affects that specific interface, while changes made to the “all” directory affects all interfaces on the system.

If you have compiled your kernel with CONFIG_SYNCOOKIES, you will be able to optionally turn on or off protection against SYN flood attacks. Note the emphasis, as compiling the kernel with this value does not enable it by default. It works by sending out ’syncookies’ when the syn backlog queue of a socket overflows. What is often misunderstood is that socket backlogging is not supported in newer operating systems, which means that your error messages may not be correctly received by the offending system. Also, if you see synflood warnings in your logs, make sure they are not the result of a heavily loaded server before enabling this setting. They can also cause connection problems for other hosts attempting to reach you. However, if you do want to enable this setting, perform the following:

if [ -r /proc/sys/net/ipv4/tcp_syncookies ]; then echo "Enabling tcp_syncookies" echo "1" > /proc/sys/net/ipv4/tcp_syncookies fi

Normally, a host has no control over the route any particular packet takes beyond its first hop. It is up to the other hosts on the network to complete the delivery. IP Source Routing (SRR) is a method of specifying the exact path that a packet should take among the other hosts to get to its destination. This is generally a bad idea for the security conscious, as someone could direct packets to you through a trusted interface and effectively bypass your security in some cases. A good example is traffic, such as SSH or telnet, that is blocked on one interface might arrive on another of your host’s interfaces if source routing is used, which you might not have anticipated in your firewall settings. You’ll probably want to disable this setting with:

if [ -r /proc/sys/net/ipv4/conf/all/accept_source_route ]; then echo "Disabling source routing" echo "0" > /proc/sys/net/ipv4/conf/all/accept_source_route fi

Packets that have source addresses with no known route are referred to as “martians”. For example, if you have two different subnets plugged into the same hub, the routers on each end will see each other as martians. To log such packets to the kernel log, which should never show up in the first place, you’ll need to issue:

if [ -r /proc/sys/net/ipv4/conf/all/log_martians ]; then echo "Enabling logging of martians" echo "1" > /proc/sys/net/ipv4/conf/all/log_martians fi

Additional Resources

For more information regarding the /proc filesystem, you may want to refer to the documentation that comes with the Linux kernel source. Of specific help is Documentation/filesystems/proc.txt by Bowden, Bauer & Nerin. Additionally, you can refer to Documentation/networking/ip-sysctl.txt by Kuznetsov & Savola.

About the Author

David Lechnyr is a Network Administrator at the Human Resources department of the University of Oregon. He holds a Master’s Degree in Social Work along with his MCSE+I, CNE, and CCNA certifications. He has been working with Linux for the past five years, with an emphasis on systems security, network troubleshooting, PHP scripting, and web/SQL integration.

© 2002 by David Lechnyr, david@lechnyr.com. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at http://www.opencontent.org/openpub/). Distribution of substantively modified versions of this document is prohibited without the explicit permission of the copyright holder. Distribution of the work or derivative of the work in any standard (paper) book form is prohibited unless prior permission is obtained from the copyright holder.

Unlike your lawyer ;), software is one of those rare exceptions to “you get what you pay for”. Instead, it may be helpful to change your thinking to you get what you are willing to search for.

eGroupware Server Requirements:
As the name implies, the first thing you need is a server. Before you stop reading because you don’t want to invest in a high end server hardware, I should tell you about my humble ’server’. For those who are unfamiliar with what exactly a server is, it is simply a computer dedicated to one or more tasks. e.g. holding your files, collecting your mail, hosting your website, etc. The application uses very little system overhead, and can be run on an LAMP or WAMP server. In my office, I run eGroupware on my mail and file server. I installed a LAMP server on an outdated desktop. My machine, which lives in the corner of a closet, has a 1.2Ghz AMD Athlon processor, 640 MB of memory, a 40 GB hard drive, and a network card. I don’t even have the machine hooked up to a monitor since all of the configuration can be done via ssh (a secure telnet session). And even this machine averages about 95% cpu idle time, although the memory does get used by the mail server. All that while running my file server, WebDAV server, groupware server, mail server, IMAP server, Spamassassin and a few other applications.
A LAMP (Linux Apache MySQL Php) or WAMP (Windows Apache MySql Php) server is relatively straight forward to install and set up. If you are not too paranoid about security, you can use Ubuntu Server, http://ubuntu.org, which has an option to actually install a LAMP server during the setup prompts. If you have a old Windows machine, you can install Windows versions of Apache 2, MySql, and Php on an existing machine (although I would NEVER trust it to be secure on the Internet). Or, if you are paranoid, like me, then you can base your system on OpenBSD, or your other favorite distribution. Again, the key components are Apache, MySql, and Php. Each distribution has its own server installation instructions that range anywhere from a step-by-step walkthrough (see Ubuntu, Mandriva, Fedora), to efficient but enigmatic (see OpenBSD, SlackWare, etc).

Installation of eGroupware
The installation of the program is very straight-forward. Several Linux distributions actually offer eGroupware as a package. Installation is as easy as selecting the package and telling the system to install it.
If you want to install the package manually, simply download the latest version to the server, unzip/untar the package, and then copy it to your web base directory in Apache (usually /var/www). If you copy it to the your base directory in Apache (usually /var/www), then you can reach the program by pointing a web browser (on another computer) to http://servername/egroupware. From this point, the installation instructions are reasonably well explained in the package and on the eGroupware website. All computers are different, but I did not run across any question that I could not find an answer to on their website.

Getting up and Running:
Once the server is installed, now you get to put it into action. After logging in, you can create some users, and start setting up you backoffice environment.
The calendar can be displayed by day, weekview without weekend, weekview with weekend, planner by category, planner by user, or by activity list. If you want you can also add custom fields to the calendar. And most importantly, when you enter an activity, you can choose which users, by user or group, can view the activity.
The next most-used feature for me in Egroupware is the address book. Like the calendar you can query by group or category, and can also set the user access permissions for other users to any of your contacts.
One of the features that is especially useful is that the calendar and contacts can be synced to several support applications and devices. The information can be synced with Outlook, Evolution, Kontact or other message programs, and can also be synced with several PIMs. A list of the supported applications and devices is shown on eGroupware’s website.
The other feature that I use on a regular basis is the Document Management Server, myDMS. For me, it is a great place to store and organize all types of templates, and versions of documents. In addition to organizing documents in logical categories, you can also set user access permissions individually for any single, or group of documents.
In addition to these features, there is also an included project manager, resource manager (useful for conference rooms, etc), timesheet, and file manager. While I, admittedly, do not use these features on a regular basis, from what I have seen, they appear to be just as useful as the modules that I outlined above.

Support
In my case, any technical issue that I ran into was easily answered by a quick Google of the issue. If you cannot find it by internet search, then they have mailing lists in seven different languages, including one specifically for users of Windows.
For those who are not so inclined to read answers in the form of a mailing list digest, then you will need to find a local person who is knowledgeable of LAMP or WAMP servers to assist you with the installation and maintenance of the server.

Conclusion
EGoupware, for my small office, is a solid software project, that provides an open source implementation to share contacts, calendars, files, and other information. I admit that when I have a software need, I look to open source products instead of proprietary programs. I have used Linux for almost ten years, and I am pleased with the available software, the system security, the choices of desktops, and the flexibility of the Product. But, I also understand that Microsoft-based products have their place in the office as well…I’ve been a Microsoft Certified Systems Engineer for over 10 years, and spent several years implementing enterprise CRM, work flow, and financial systems. The good news is that the only client requirement is a working browser, and more importantly you get complete control of your data and your security. For a small to mid-sized, efficient, and frugal operation, this open source application might be a perfect fit.

Instead, go to the box to type in the URL. then put http://yourcupsserver:631/printers/YourPrinter. Of course you will need to substitute the actual ip address or host name for the CUPS server, and you will need to know the printer as it is called on the CUPs server. Additionally, unlike Unix clients, you will need to put the port information behind the server name, e.g. :631.

If you put in the correct server name, then you simply need to choose the printer, and print driver from the following Windows menus.

Happy printing.

I’m sharing how I got my shared printers to work from my main server. I’ll admit that I may not have used all of the correct formatting, nor do I have a guru’s understanding of CUPS, but it works, it seems secure, and I’m hopeful that it doesn’t drain as many hours from the readers’ life as it did mine in order to get it working.

First off, the general idea is easy: just install cups, go to the web-based configuration tool, and voila, you’re up and running. Unfortunately it was not so simple in my case. My goal was to share my workstation printer among the desktops and laptops on my network.

To install CUPS on Debian or Ubuntu, simply log into the terminal and type “sudo apt-get install cups”. The system will ask you for your administrative password and will then install the latest version of the software. If you are using other distros, you can get cups by RPM on RedHat, Mandriva, and similar systems. On OpenBSD, you use the pkgadd script to get the program. At this point, there is not much to discuss. The installation programs will download and install the latest version on your system.

Once installed, open your browser and go to http://localhost:631 to access the web-based administration panel. You can choose your Basic Server Settings from the Administration tab. And now is where the frustration begins…

If you want to employ any reasonable security on your system, you will need to go to Edit Configuration File. This utility edits /etc/cups/cupsd.conf. If you choose, you can edit the file by hand using vim, pico, or your favorite edit from the terminal.

An annotated example of my cupsd.conf file. Note that all lines beginning with # are ignored, so this is where I will put my comments and explanations. Reference files and man files that describe each heading can be found at http://www.cups.org/documentation.php.
LogLevel error
#This can be set to none, emergency, alter, critical, error, warn, notice, info, and debug. I put mine to error to log all general errors.
AccessLog /var/log/cups/access_log-%s
ErrorLog /var/log/cups/error_log-%s
#You can choose where to store the logs. the -%s adds the system name behind the log name.
SystemGroup lpadmin system
#Name all system administration groups separated by spaces
# Allow remote access. Port specifies a port to listen on. 631 is the default port e.g. http:localhost:631
Port 631
Listen /var/run/cups/cups.sock

# Share local printers on the local network.
Browsing On
# Turn on port browsing to listen for clients

BrowseOrder allow,deny
# Set access. either allow, deny or deny, allow. I use allow, deny because it automatically denies all requests, then it allows requests as per the following lines, then it can specifically deny requests from within any of these groups.

BrowseAllow 10.0.0.*.*
# this allows any local address in the 10.0 network e.g your local network.

BrowseAllow nnn.nnn.nnn.nnn/255.255.255.0
#nnn… is your local internet viewable network and netmask if you have one

BrowseAddress @LOCAL
#Browse all local ports

ErrorPolicy retry-job
# what happens when there is an error. I set to retry the job.

JobRetryInterval 45
# How long to wait before retrying the job

JobRetryLimit 5
# How many times should it try to retry the job.

# And now we reach the most important part, how to allow access to CUPS.

<Location /> #Access to the root directory of CUPS
Encryption IfRequested # Use encryption if requested by client, Optional
Require user @SYSTEM #Require a system user from the server.
# Allow shared printing and remote administration…
Order allow, deny # Same as above, you can choose allow, deny or deny allow
Allow 10.0.*.* # Allow all computers on the subnet 10.0.0.0
Allow @Local # Allow all computers on the local network. If it is the same as 10.0.0.0 then you could only put this
Allow nnn.nnn.nnn.nnn/255.255.255.0 #nnn… is your local internet viewable network and netmask if you have one
</Location>

<Location /jobs> #Same as above
Encryption IfRequested
Require user @SYSTEM
Order allow, deny
Allow @Local
</Location>

<Location /printers> #Same as above
Encryption IfRequested
Require user @SYSTEM
Order allow, deny
Allow @Local
</Location>

<Location /admin> # who can access the administrative interface by going to http://yourserver:631
Encryption IfRequested
Require user @SYSTEM
Order allow, deny
Allow @Local
</Location>

<Location /admin/conf> # who can access the configuration interface by going to http://yourserver:631
Encryption IfRequested
Require user @SYSTEM
Order allow, deny
Allow @Local
</Location>

<Policy default> # Honestly, these settings are the default ones, it works, so I didn’t touch them.

<Limit Send-Document Send-URI Hold-Job Release-Job Restart-Job Purge-Jobs Set-Job-Attributes Create-Job-Subscription Renew-Subscription Cancel-Subscription Get-Notifications Reprocess-Job Cancel-Current-Job Suspend-Current-Job Resume-Job CUPS-Move-Job>
Require user @OWNER @SYSTEM
Order deny,allow
</Limit>

<Limit CUPS-Add-Modify-Printer CUPS-Delete-Printer CUPS-Add-Modify-Class CUPS-Delete-Class CUPS-Set-Default>
AuthType Default
Require user @SYSTEM
Order deny,allow
</Limit>

<Limit Pause-Printer Resume-Printer Enable-Printer Disable-Printer Pause-Printer-After-Current-Job Hold-New-Jobs Release-Held-New-Jobs Deactivate-Printer Activate-Printer Restart-Printer Shutdown-Printer Startup-Printer Promote-Job Schedule-Job-After CUPS-Accept-Jobs CUPS-Reject-Jobs>
AuthType Default
Require user @SYSTEM
Order deny,allow
</Limit>

<Limit CUPS-Authenticate-Job>
Require user @OWNER @SYSTEM
Order deny,allow
</Limit>

<Limit All>
Order deny,allow
</Limit>
</Policy>

If you are familiar with CUPS and see an error, I would appreciate any corrections. For a complete explanation of all options in the cupsd.conf, go to http://www.cups.org/documentation.php/ref-cupsd-conf.html

Now for the client side:

Using this configuration, I never was able to browse the IPP queues using the printers manager applet system-config-printer.py So I used the web interface on my client computers by going to http://localhost:631

From the client configuration page, shut down all access to the client as a server by unchecking everything but Allow users to cancel any job on the Basic Server Settings. I leave the Allow users to cancel any job because we have a small office and there is not a problem with persons usurping print queues.

Then go to Add Printer.

From here you can put in the printer name, no spaces no special characters. e.g. LaserPrinter. The next two fields allow you to add human readable text to describe the printer location and the printer itself. Click on Continue and move one.

The next screen lets you choose how the client computer will access the device. Choose Internet Printing Protocol and click on continue.

Now is when I wish that the browse function worked in system-config-printer.py, because you have to input the actual address. Fortunately it is relatively logical. type in ipp://yourprintserverhostname/printers/LaserPrinter Of course you will need the hostname of your print server and the actual name of your printer.

Click Continue and move on to choosing the driver for your printer. If you cannot find the specific driver that works with your printer, and if you do not have a ppd file for your printer, then go to http://linuxprinting.org and look up your printer there. This site has information on most printers and will state the driver that works best, and how well the printer works with Linux.

Finally, click on my printer. Voila, you should now have access to the network printer.

I am writing this because I spent two days trying to configure my CUPS server so that I could actually browse the queues over the system-config-printer application. Alas, I was unable to actually make that part work. If there is someone who knows how to answer this conundrum, I would find it helpful.

Otherwise, happy network printing, and I hope that this was helpful.