Building a Transparent Firewall with Linux, Part III

Hack your cheap wireless gateway into a stealth firewall.
Enabling SSH

Both examples I showed last month for how to connect to OpenWrt involved telnet. Although this is the default way to log on to OpenWrt (at least for initial setup), it's highly insecure.

Luckily, on OpenWrt Backfire, the Dropbear Secure Shell (SSH) dæmon package is installed and runs at startup, by default. All you have to do to disable telnet logins and enable SSH logins is first to telnet in to OpenWrt and then set a root password via the passwd command, like this:

root@OpenWrt:~# passwd
Changing password for root
New password: *********
Retype password: *********
Password for root changed by root

You don't need to restart the router; simply log out of the telnet session, and ssh back in. This time, you'll be prompted for a user name (use “root”) and password (the one you just entered).

Now that you've got a secure administrative session, you can get to work reconfiguring OpenWrt using the Unified Configuration Interface (uci) system.

Using uci

In earlier versions of OpenWrt, such as White Russian, you had to manage two different configuration systems: NVRAM settings, via the nvram command and the standard /etc system for ordinary Linux OS and application settings. With the Kamikaze and Backfire versions of OpenWrt, however, nvram settings are maintained in files stored in /etc/config, making OpenWrt a bit more UNIX-like than before.

In fact, most OpenWrt behavior, not just NVRAM-specific settings, can be managed via files in /etc/config/. The catch is that unlike ordinary configuration files, you're supposed to use the command uci rather than a text editor to manipulate anything in /etc/config.

uci automatically decides whether changes in a given /etc/config file need to trigger an NVRAM change, require other commands such as iptables to be invoked and so forth. Strictly speaking, you probably don't always have to use uci—for example, I was able to change my WRT54GL's time zone by editing /etc/config/system and rebooting. However, things work better on OpenWrt when you stick to uci.

Listing 1 shows a block of uci commands with which you can change your OpenWrt box's time zone and hostname.

The general syntax of the uci command is uci [action] [config-file-name].[config-file-section].[option-name]=[value]. Thus, the first line in Listing 1 translates to “change a setting in /etc/config/system, in its system section, called timezone, to have the value CST6CDT,M3.2.0,M11.1.0”.

Why does a time zone value have so much gobbledygook after the name of the actual time zone? Why not just say “CST6CDT”? It's because of the difference in Daylight Savings Time start and end dates in different countries. See Resources for a link to a chart of different time zone strings you can use.

Setting the correct time zone is important. It allows your OpenWrt Backfire system to synchronize its time over the Internet automatically, using the rdate command (or you can install ntpclient to have it use ntp instead). If you don't set the correct time zone, rdate won't work correctly, which means lots of other things will fail too, such as IPsec and anything else that uses digital certificates.

Moving on, the second line in Listing 1 involves changing the setting of option “hostname” from its default of “OpenWrt” to “sugartongs”. Obviously, you can specify whatever hostname you like.

The third line tells uci to commit all changes to /etc/config/ since the last time it was run—that is, to change NVRAM, execute iptables commands and so forth, as applicable. I find that with time zone and hostname settings, however, you also need to reboot the router for the changes to take effect (using the command reboot, naturally).

Installing Optional Packages

I'll come back to uci in a moment. First, a here's quick word about optional software packages.

Like any Linux distribution, OpenWrt has optional software packages you can install after the base system image is in place. The majority of OpenWrt's packages are network-oriented, and they include apache, bind, freeradius, various Linux kernel modules, snort, squid, stunnel, vpnc and vsftpd.

But these are out of scope for this series of articles. Everything you need in order to build a transparent firewall using OpenWrt Backfire is included in the base image (at least that was true for my Linksys WRT54GL). Furthermore, most broadband routers have between 16 and 72 megabytes total combined Flash-memory and RAM; even with a compressed filesystem, this doesn't amount to much storage space either for applications themselves or for their data.

Still, if you want to install optional packages, they're available from openwrt.org in the packages directory of your architecture's download site. For example, for my system, running the Broadcom 47xx version of OpenWrt Backfire, optional packages are located in backfire.openwrt.org/10.03/brcm47xx/packages. See the OpenWrt Wiki page for Packages for more information on finding and managing OpenWrt packages.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Compile time configuration

Paddy's picture

In the article, you indicate that the relevant binaries are to be found under 'bin/brcm47xx'. Though when I compile using the default configuration (target system: Broadcom BCM947xx/953xx [2.4], target profile: Linksys WRT610N v1) I get the 'bin/brcm-2.4' directory instead.

My guess is you used 'Broadcom BCM947xx/953xx' as target system. Still, I am not sure about the target profile that should be used.

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState