Building a Transparent Firewall with Linux, Part III
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.
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.
Listing 1. Changing Time Zone and Hostname
root@OpenWrt# uci set ↪system.@system.timezone=CST6CDT,M3.2.0,M11.1.0 root@OpenWrt# uci set system.@system.hostname=sugartongs root@OpenWrt# uci commit system
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).
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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Tech Tip: Really Simple HTTP Server with Python
- Doing for User Space What We Did for Kernel Space
- Rogue Wave Software's Zend Server
- Parsing an RSS News Feed with a Bash Script
- SuperTuxKart 0.9.2 Released