evilrouters.net

I was bored so decided to play with hping3 a bit tonight.

[jlgaddis@bertram:~]$ sudo hping3 --udp -p 10000 --destport 10000 --flood 192.168.1.12
HPING 192.168.1.12 (eth0 192.168.1.12): udp mode set, 28 headers + 1400 data bytes
hping in flood mode, no replies will be shown

I have the same thing running 192.168.1.12 as well, for “bi-directional” traffic.

c1811# sh int fa7 | in put\ rate
  5 minute input rate 96657000 bits/sec, 8404 packets/sec
  5 minute output rate 93537000 bits/sec, 11389 packets/sec

This morning, I received an e-mail from a cronjob on one of my production RHEL 5.2 servers:

From: Cron Daemon
To: Jeremy L. Gaddis
Cc:
Subject: Cron <root@SERVERNAME> run-parts /etc/cron.weekly

/etc/cron.weekly/makewhatis.cron:

rpmdb: Lock table is out of available locker entries
rpmdb: Unknown locker ID: b4a0
error: db4 error(22) from db->close: Invalid argument
error: cannot open Pubkeys index using db3 - Cannot allocate memory (12)

...

There were probably a couple hundred errors in that e-mail. In addition, I also received an e-mail from our RHN Satellite Server letting me know that this particular server had failed to check in. Logging in, I saw that, indeed, it had not been checking in with the our satellite.

So, what to do? Google, of course! Fortunately, major over at Racker Hacker encountered this same issue about a year and a half ago and has already provided the fix for us:

[root@SERVERNAME ~]# tar cvzf rpmdb-backup.tar.gz /var/lib/rpm
[root@SERVERNAME ~]# rm /var/lib/rpm/__db.00*
[root@SERVERNAME ~]# rpm --rebuilddb
[root@SERVERNAME ~]# rpm -qa | sort # to make sure everything's okay

I wanted to verify that the cronjob would now successfully execute, so I invoked it manually:

[root@SERVERNAME ~]# sh /etc/cron.weekly/makewhatis.cron
[root@SERVERNAME ~]#

Success! It also seemed like a good time to go ahead and install the updates that were missing so I took care of those using yum.

Many thanks to major at Racker Hacker for the fix!

In this demonstration, we’re going to install FreeRADIUS onto a CentOS 5.2 server and configure it to support AAA on Cisco devices.

“FreeRADIUS is the most widely deployed RADIUS server in the world. It is the basis for multiple commercial offerings. It supplies the AAA needs of many Fortune-500 companies and Tier 1 ISPs. It is also widely used in the academic community, including eduroam. The server is fast, feature-rich, modular, and scalable.” –FreeRADIUS home page

I’ve been using FreeRADIUS in production for a few years now, mostly to support wireless users. One of the benefits of FreeRADIUS — besides being open source, of course — is the numbers of backends one can use for authentication:

“If a password is not available locally for some reason, the server can pass the authentication to another system such as LDAP, PAM, Unix (/etc/passwd), Kerberos, Active Directory, or RADIUS server via RADIUS proxying. Local programs (e.g. CGI scripts) can also be used to authenticate users via shell scripts or any other method. Perl or Python scripts can be pre-loaded into the server, which significantly lowers the cost of running such programs.”

Powerful, huh? Indeed.

For this demonstration, I’m installing a new CentOS 5.2 virtual machine on my MacBook under VMware Fusion. Installing the operating system, however, is beyond the scope of this document. Also, we’ll just be using the local system database for now — we’ll save SQL and LDAP (perhaps even Active Directory) authentication for later. After we get FreeRADIUS up and running, we’ll set up a user account and then configure a Cisco router to use RADIUS for authentication.

Let’s begin with installing FreeRADIUS by running (as root) the following command:

[root@bertram ~]# yum -y install freeradius

“yum” should have went out, grabbed the appropriates packages and dependencies, and installed them. If the end of your output looks like this, you’re all set:

Complete!
[root@bertram ~]#

Because FreeRADIUS will need to use the local system database for authentication, we need to set ‘user = root’ and ‘group = root’ in radiusd.conf. This is easy enough, just open up /etc/raddb/radiusd.conf, and change the lines that reads “user = radiusd” and “group = radiusd” to “user = root” and “group = root”, respectively. Note that this (running our daemons as root) is almost always something we want to avoid. Using other authentication backends, such as SQL or LDAP, would not require this change and would allow the FreeRADIUS service to run under the default “radiusd” unprivileged account.

Next, we need to let FreeRADIUS know about our NAS — in this case, our Cisco router. For the sake of this demonstration, our router (R1) will have IP address 192.168.1.201. We’ll also need a shared secret that the router and RADIUS server use. Let’s use the ever popular “SECRET_KEY”. Add the following to the end of /etc/raddb/clients.conf:

client 192.168.1.201 {
        secret = SECRET_KEY
        shortname = R1
        nastype = cisco
}

Then, on the FreeRADIUS side, we need to create a user account in the local user database that we’ll use for actually authenticating to R1. Nothing special here, just creating a new user account and setting the password. I’ve passed the plain-text password into “passwd” via stdin so that you can see it. Normally, we wouldn’t do that — just run “passwd cisco” and enter the password when prompted:

[root@bertram ~]# /usr/sbin/useradd cisco
[root@bertram ~]# echo secret | passwd --stdin cisco
Changing password for user cisco.
passwd: all authentication tokens updated successfully.
[root@bertram ~]#

We now have a local user named “cisco” with a password of “secret” that we’ll use when it comes time to authenticate to R1. Before we can do that, however, we must let FreeRADIUS know about the user. Append the following to /etc/raddb/users:

cisco   Auth-Type := System
        Service-Type = NAS-Prompt-User,
        cisco-avpair = "shell:priv-lvl=15"

This notifies FreeRADIUS of a local user account named “cisco”. Using the “cisco-avpair” attribute in this manner allows us to automatically assign privilege level 15 to the user, removing the requirement for the user to issue “enable” (and the enable secret) in order to gain elevated access.

Let’s get started configuring R1. I’m going to assume that you’re starting from a default configuration. The first thing we want to do is create a “fallback” user account (on the router itself) that we can use to authenticate if, for some reason, connectivity to the RADIUS server is lost. Let’s create a user named “admin” with a password of “letmein”:

R1(config)#username admin privilege 15 secret letmein

Under normal circumstances, we’ll never use this local account — only when the RADIUS server is unavailable.

The first thing I need to do is configure my interface on R1 and verify we can ping the RADIUS server. Assuming you already have your router up and running, you can likely skip this step:

R1(config)#interface fastethernet 3/0
R1(config-if)#ip address 192.168.1.201 255.255.255.0
R1(config-if)#no shutdown
R1(config-if)#
*Mar  1 00:10:14.635: %LINK-3-UPDOWN: Interface FastEthernet3/0, changed state to up
*Mar  1 00:10:15.635: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet3/0, changed state to up
R1(config-if)#do ping 192.168.1.51

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.51, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 4/11/24 ms
R1(config-if)#

Excellent, all set! Let’s start configuring R1 for AAA:

R1(config)#aaa new-model
R1(config)#radius-server host 192.168.1.51 auth-port 1812 acct-port 1813 key SECRET_KEY

AAA should now be enabled on R1. Note that we provided the IP address of the RADIUS server as well as the shared secret we configured in FreeRADIUS earlier. In addition, we must specify the “auth-port” and “acct-port” used by FreeRADIUS, as these are different from Cisco’s defaults (1645 and 1646). Let’s configure authentication:

R1(config)#aaa authentication login default group radius local
R1(config)#line vty 0 4
R1(config-line)#login authentication default
R1(config-line)#line con 0
R1(config-line)#login authentication default

Here, we’ve told R1 to use RADIUS for authentication and to fall back to the local user database if the RADIUS server is not available. We don’t want to DoS ourselves!

The following command will allow the user to run an “exec” shell when logging into the router:

R1(config)#aaa authorization exec default group radius if-authenticated 

Last, but not least, we want accounting (the final “A” in “AAA”):

R1(config)#aaa accounting exec default start-stop group radius
R1(config)#aaa accounting system default start-stop group radius

That should be enough to allow us to login with our local (Linux) system account “cisco” that we created earlier. Let’s give it a shot:

macbook:~ jlgaddis$ telnet 192.168.1.201
Trying 192.168.1.201...
Connected to 192.168.1.201.
Escape character is '^]'.


User Access Verification

Username: cisco
Password:

R1#show ip interface brief
Interface                  IP-Address      OK? Method Status                Protocol
Ethernet0/0                unassigned      YES unset  administratively down down
Ethernet0/1                unassigned      YES unset  administratively down down
Ethernet0/2                unassigned      YES unset  administratively down down
Ethernet0/3                unassigned      YES unset  administratively down down
Serial1/0                  unassigned      YES unset  administratively down down
Serial1/1                  unassigned      YES unset  administratively down down
Serial1/2                  unassigned      YES unset  administratively down down
Serial1/3                  unassigned      YES unset  administratively down down
FastEthernet3/0            192.168.1.201   YES manual up                    up
R1#exit
Connection closed by foreign host.
macbook:~ jlgaddis$

Success! We’ve installed FreeRADIUS, added a local user account, set up the NAS client (R1) and configured it to authenticate against the RADIUS server. Let’s take a look at what was logged by FreeRADIUS:

[root@bertram ~]# cat /var/log/radius/radacct/192.168.1.201/detail-20081119
Wed Nov 19 00:24:47 2008
        Acct-Session-Id = "00000005"
        User-Name = "cisco"
        Acct-Authentic = RADIUS
        Acct-Status-Type = Start
        NAS-Port = 130
        NAS-Port-Id = "tty130"
        NAS-Port-Type = Virtual
        Calling-Station-Id = "192.168.1.49"
        Service-Type = NAS-Prompt-User
        NAS-IP-Address = 192.168.1.201
        Acct-Delay-Time = 0
        Client-IP-Address = 192.168.1.201
        Acct-Unique-Session-Id = "31b757fca2145e79"
        Timestamp = 1227072287

Wed Nov 19 00:25:14 2008
        Acct-Session-Id = "00000005"
        User-Name = "cisco"
        Acct-Authentic = RADIUS
        Acct-Terminate-Cause = User-Request
        Acct-Session-Time = 27
        Acct-Status-Type = Stop
        NAS-Port = 130
        NAS-Port-Id = "tty130"
        NAS-Port-Type = Virtual
        Calling-Station-Id = "192.168.1.49"
        Service-Type = NAS-Prompt-User
        NAS-IP-Address = 192.168.1.201
        Acct-Delay-Time = 0
        Client-IP-Address = 192.168.1.201
        Acct-Unique-Session-Id = "31b757fca2145e79"
        Timestamp = 1227072314

[root@bertram ~]#

If there’s interest, I may expand on this later to include huntgroups, multiple RADIUS servers, using MySQL for accounting, or even through some LDAP and/or Active Directory authentication into the mix. If you’re interested, please leave a comment below!

A few weeks ago, eWeek ran an article by Steven J. Vaughan-Nichols entitled “Cheap Laptops Bad for Vista, Good for Linux“. In the article, he talks about the number of cheap laptops that people are buying up that aren’t capable of running Vista — but are quite capable of running Linux just fine.

Working in IT at an .edu, this is something I’m all too familiar with. I wish our Help Desk had kept count of how many students had come to them for assistance with their cheap laptops running Vista. I remember just a year or two ago and we were aghast at people who were running XP on laptops with only 256MB of RAM. Now it’s Vista laptops with just 512MB of RAM that we’re seeing.

Last Friday, someone poked their head into my office to let me know that a man and woman I knew wanted to talk to me. When I went out to talk to them a few moments later, it was the same thing I’ve heard countless times before. They had a laptop running Vista and were having issues. Besides the usual “it’s slow” routine, they said it had become completely unusable after the latest round of Windows Updates (the neverending “reboot, BSOD, reboot, BSOD” cycle). The laptop had came with Vista and they suffered through it up until this point. I knew what was coming and I tried to avoid it, but I finally gave in. I told them I’d blow it away and install XP for ‘em.

I learned a long time ago never to accept payment from friends because when their laptops screw up again, they’ll expect you to fix it again — for free, of course. Since this was late in the afternoon on a Friday and I had plans for the evening, I gave ‘em the “I’ll do it, but I can’t promise when I’ll have it done” spell. That was fine with them; the laptop was useless anyways.

When I finally got around to working on it, I watched it boot up and was surprised — I don’t know why — to see it was a 1.7GHz Pentium Mobile sporting a whopping 512MB of RAM. Who in their right mind would try to run Vista on that!? Anyways, long story short, I blew away Vista, reinstalled XP, got it back to ‘em and they’re happy as hell — the laptop is running faster than it ever has.

Now, back to the eWeek article… Vaughan-Nichols goes on to talk about how any modern Linux distribution (such as Fedora) will run great on these laptops, and he’s right. Every since I started using Linux over 10 years ago, it’s been possible to run it on hardware that Windows would choke on. I get better performance from my much slower Linux machines than I do from my better equipped XP machines, and I’m much more demanding of the Linux machines.

I’d love to convince these people to use Linux instead of Windows, but I just can’t. To do that would be to volunteer myself to be their first line of “tech support” and I just don’t have the time for that. These people aren’t interested in tinkering with their PCs, they just want ‘em to work.

Ironically, that’s one of the reasons I’ve never been a big fan of “Linux on the desktop”. All that tinkering is great for a while, but it gets old pretty quick. I used to love to constantly tweak my Linux machines, always downloading, compiling, and rebooting into the latest kernel just moments after it was released. Once I started having real work to do, however, I cut that out. Now, like most consumers, I just want my computers to work so that I can get my work done.

That’s one of the reasons I just ordered a MacBook…

[root@jlgaddis-xen ~]# xm list
Name                                      ID Mem(MiB) VCPUs State   Time(s)
Domain-0                                   0      440     4 r-----   1834.7
xen_01                                     1      255     1 -b----    502.3
xen_02                                     2      255     1 -b----    512.3
xen_03                                     3      255     1 -b----    508.5
xen_04                                     4      255     1 -b----    508.2
xen_05                                     5      255     1 -b----    511.7
xen_06                                     6      255     1 -b----    513.6
xen_07                                     7      255     1 -b----    503.7
xen_08                                     8      255     1 -b----    508.9
xen_09                                     9      255     1 -b----    511.2
xen_10                                    10      255     1 -b----    507.7
xen_11                                    53      255     1 -b----     29.7
xen_12                                    54      255     1 -b----     32.0
xen_13                                    55      255     1 -b----     31.3
xen_14                                    56      255     1 -b----     37.9
xen_15                                    57      255     1 -b----     26.8
xen_16                                    60      255     1 -b----     46.5
xen_17                                    59      255     1 -b----     46.2
xen_18                                    63      255     1 -b----     38.0
xen_19                                    65      255     1 -b----     34.8
xen_20                                    84      255     1 -b----     19.2
xen_21                                    85      255     1 -b----     20.0
xen_22                                    71      255     1 -b----     38.6
xen_23                                    70      255     1 -b----     37.4
xen_24                                    74      255     1 -b----     41.6
xen_25                                    73      255     1 -b----     41.3
xen_26                                    75      255     1 -b----     43.3
xen_27                                    76      255     1 -b----     43.2
xen_28                                    86      255     1 -b----     19.4
xen_29                                    87      255     1 -b----     20.2
xen_30                                    83      255     1 -b----     26.0