David Lechnyr submitted a paper he wrote on how to use /proc to tune network security settings. “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. “. . . David Lechnyr submitted a paper he wrote on how to use /proc to tune network security settings. “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. ”

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.

Once you have CUPS installed properly, you can easily print from both Unix and Windows clients. On Windows (at least Windows XP), open up the Printers list from the Control Panel and click on Add New Printer. Windows will ask whether it is a local printer or a networked printer. Choose networked printer. From the next screen, do NOT choose browse the network. Windows will only browse the local windows network and will not show the CUPS server unless it is also running SAMBA.

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.

Of all of the features that I rave about using Linux, network printing is not one of them. Linux uses CUPS (Common UNIX Printing System) to natively share printers and connect to shared printers on other UNIX boxes. Unlike Windows, this is not as simple as choosing the printer and sharing it among your peers. But, on the other hand, the network security is highly configurable albeit draconian and frustrating to figure out. Plus, once it is configured you can forget about it.

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.

Post-It notes are one of the most used pieces of office ‘equipment’ that I used from day to day. My desk, my monitor, and even my office are all dotted with spots of color, tidbits of information that help me remember what I did, what I learned, and what I need to do next.

Tomboy notes is a small applet that puts these notes in my screen instead of on my screen. Plus, it has the added bonus of cross referencing all notes to make digging for information, a simple and efficient task. I leave the unobtrusive icon in the corner of my main monitor. When I receive, or make a phone call, all I have to do is type a simple subject line, jot down the information I need, and voila: any time that subject line comes up again in any other note, it is automatically linked and cross-referenced back to the original note with the subject line.

For example, say I am tracking down a new computer supply shop. I make note with the subject line computer supply, and put down all of the information I need in the note. Then if I make a later note (it also cross-references prior notes), and mention the phrase “computer supply”, that phrase is highlighted and automatically linked back to the original note.

This applet is not a panacea to rid my desk of Post-It notes. The catch is that it has to be used on a regular basis to be an effective tool, and moreso, the subjects must be organizationally intuitive. I admit that I use the applet mostly when organizing case information, or when doing cursory research. And, even though I spend my time with technical issues, I often find a pen and paper to be more reliable, and more accessible. But, for those who are fastidiously organized, and tech addicted, this may just be one of those little apps that makes life a bit easier.

One of the greatest advantages, and ironies, of using Linux applications is that they often interoperate with certain Windows protocols faster and more efficiently than Windows itself. This was true for several years with SMB file server where SAMBA outperformed Windows file servers using a Windows protocol. I still find SAMBA to be easier to configure, secure, and troubleshoot than its Windows counterpart, but, new Windows Servers have made headway to fix that embarrassment. Another application that I found works better than the Windows Citrix client is Linux’s Remote Desktop Client.

One of my pet peeves with many companies’ (and universities’) Windows-reared tech support staff is their absolute ignorance of, and unwillingness to support, any other system other than the one that they currently employ… including former versions of Windows itself. Let me say once and for all that having a short rehearsed script, and Microsoft’s tech support number entered into speeddial does not qualify one to be a computer support technician.

I’ll shed some light on my disdain for certain, but unfortunatley not unique, IT support staff by describing a recent encounter with just such an IT ’specialist.’

A university employee needed to access a certain file server to which the university IT team had understandably restricted access only to local clients and via a citrix interface. Since she was using my laptop, I told her I would get her set up so she could work remotely. So, I phoned the department to get the login parameters through which to access the computer. I specifically asked the server’s address, the domain name, and the client name. Simple? Apparently not.

Out came the script… You need to open IE from the desktop, go to xyz web page, log in to the page, download the client, and then we’ll talk… Oh, you use Linux; we don’t support that.

I didn’t ask him to provide software support for my computer; I asked the login parameters.

If you run into a similar situation, here is the fast and easy way to get the parameters from the .ica file. Citrix usually has a web-based front end through which you can access one or more systems. These links open a configuration file, citrix.ica, which, if you run Windows with an installed Citrix client, will open the client, automatically provide the connection parameters, and let you log in.

With the Linux Remote Desktop Client, you can skip the Citrix interface, and log in directly with Remote Desktop Protocol.

You will need fill out at least 5 fields in the Remotedesktop Client, most of which can be taken from the .ica file. So the first thing to do is download (not open) the ica file, and then open it with cat, pico, vi, or your favorite text viewer.

Computer: Use theIP address listed next to Address, without the four digit port extension :1494. e.g. 123.456.789.123

Username: This is windows login name. e.g. mylogin, not Domain\mylogin

Password: self explanatory

Domain: Put the Windows network domain name here. e.g. Domain, not Domain.com

Click on the Resources tab in Remotedesktop client and choose the keyboard language code, e.g. US. If you do not do this, you will get a keyboard error when attempting to login.

Last, and most importantly, click on the Extended tab and go to the Fake Clientname field: Get the client name from [WFClient] ClientName=

Now, simply login and enjoy troublefree, Citrix-Client-free, remote access.

Good luck.