Fri, 18 Jul 2003
Crackers died
Crackers is a silly name for Cockatiel, I suppose, but the kids were young and they helped name him. He was purchased as a gift for Christopher for his 11th birthday. This morning, Chris and Jenny were sitting on the sofa when they heard 3 distressed chirps from Crackers. When they got to his cage, he was feet up.
He was 11 years old. Supposedly cockatiels can live up to 20 years, so Crackers apparently died young.
Several years ago, Crackers gave us one of our lasting, family memories. He escaped and was missing for 2 weeks.
We had a policy of locking all the doors when Crackers was out of his cage to prevent him from escaping if someone unexpectedly opened an outside door. For whatever reason, one of the doors didn't get locked and one of the kids came in while another had him out of his cage. He made his exit.
I got a panicked call at work and came home to find some teary eyed kids trying to coax their bird down from the top of the willow tree in the back yard. To no avail.
He moved from tree to tree, then finally took off, circling higher and higher, and disappeared from sight.
We placed an ad in the news paper, notified the local pet stores, and spent evenings and weekends on our bikes pedaling around the Spokane Valley calling for our lost bird.
A failure on our part, we never called the Animal Shelter. We simply thought of it as a place for dogs and cats. Not birds. It turns out, someone found Crackers, exhausted beside the road and took him to the Animal shelter. A worker there saw our ad in the paper but not before they had adopted Crackers out. She called to tell us so that we wouldn't be worried, but offered little hope of us getting our bird back.
We pleaded our case, and she contacted the new owners. She ended up bringing Crackers to the house to see if she could determine, definitively, whether or not he was our missing bird.
It was obvious from the moment he entered the house. "HEY! Where's everybody been! You wouldn't believe what's happened to me!" he jabbered in bird speak.
The clincher for the lady that brought him by was when one of the kids
grabbed a toothbrush and said, Watch, he brushes his teeth.
While
April or Chris (I don't recall which) brushed their teeth in front of
Crackers, he started bobbing his head up and down doing his best
toothbrush noise imitation. There was no doubt in anyone's mind, it
was Crackers.
Rest in peace, Crackers.
Wed, 16 Jul 2003
Dropping IDENT requests causes e-mail delays
Some router/firewall boxes silently drop IDENT requests instead of
refusing them.
Steve Gibson
refers to this as stealth
mode. In theory, the advantage is that an
attacker can't tell that anything even exists at your IP address if it
doesn't respond to any connection attempts, including port 113, the
IDENT/AUTH service.
But dropping all IDENT requests leads to long connection delays for many popular services, including outbound e-mail connections to many SMTP servers.
The smart thing to do is drop (or stealth
) IDENT connections from
hosts you have no active, outbound connections with. Refuse IDENT
connections, which requires sending a reply packet, from hosts to which
you have established TCP connections. A stateful firewall should be
able to do this, but I haven't done any research to discover whether such
firewall/router boxes exist short of configuring a
Linux or
FreeBSD
server for that purpose.
An associate of mine has a Netgear RP614 Broadband Firewall/Router box. He complained that his e-mail connections were intolerably slow and asked me to investigate. The problem was dropped IDENT requests. His system made connections through the Netgear box to an SMTP server on the Internet. Upon establishing each connection, but before sending any data on the connection, the SMTP server attempted an IDENT connection back to my associates computer. His Netgear box silently dropped the incoming IDENT packets.
SMTP servers typically handle two situations quite well. The first is an accepted IDENT request. If the host making the outgoing SMTP connection has an active IDENT service, the SMTP server connects to it, request the user ID associated with the outgoing SMTP connection, and adds that bit of information to its logs and/or received headers. This is quite useful for tracking down the responsible party of e-mail abuse on a multi-user system. Without it, the task would be much more difficult.
The other common, and quite valid case, is to refuse IDENT requests.
When this happens, the SMTP server gets an immediate response to its
request, No!
Fine. It simply notes that no user ID is available and
proceeds with the SMTP mail transfer.
When the IDENT requests are silently dropped, however, what is the SMTP server to do? It has little choice. It assumes it's un-replied packets are traveling on a slow or congested network. It waits. After it has waited long enough, it decides the IDENT packet may have been lost on the Internet before reaching its destination. Another request is sent. This wait/resend cycle continues, usually for 30 seconds, but is often configurable and can be longer or shorter. In any case, it causes a very noticeable delay before the SMTP mail transfer actually begins.
While searching for a solution to this problem from the source of all knowledge, I found only one reference regarding the Netgear RP614 and IDENT requests, a comparative review of the Netgear RP614 and the D-Link DI-604 by Scot Finnie, publisher of the, apparently, very popular Scot's Newsletter.
In his review, Scot preferred the Netgear box's approach to IDENT requests: silently dropping IDENT packets. In fact, even though his bottom-line choice with the D-Link router, he considered the "closed port" (i.e., refused connections) a bug and encouraged the manufacturer to fix it.
I wrote Scot an e-mail explaining that I was trying to solve a problem
created by the very security feature he preferred. I assumed that he
may not have been aware of the connection delays stealthing
port 113
causes.
What did I expect?
I suppose I expected a reply along the lines of, "Yes, I'm aware of the issue. It is a non-issue, and here's why…"
I hoped for a reply along the lines of, "You are correct. I will let my readers know the pros and cons of stealthing port 113. Some, if not all, would be better served by a firewall that refuses IDENT requests than by one that silently drops them."
What I got was:
…RFCs don't matter to me in the least. What matters to me is something that works.
I'm not against the IDENT functionality; just the way it's been implemented.
To which, I replied:
…Surely, you don't mean what you're say[ing] here. The Internet works as well as it does because of compliance with RFCs. Without them, interoperability between platforms, programs, and networks would be virtually impossible. The fact that you and I are exchanging e-mail at all is because RFCs do matter to the people that created the tools we're using to communicate.
In what way is it implemented incorrectly? How would you implement the functionality it provides in a way that wouldn't create problems for firewalls that blindly drop IDENT packets?
Then I got this retort:
Marc, you're not listening. And you just want to b***** about your e-mail problem. As I said before, most people don't have this problem. If you decide to become a subscriber, let me know. I'll have more time to discuss this with you then.
I meant everything I said. And none of your arguments swayed me. I have thousands of readers. Not everyone has the same problems you do. I represent everyone. Not just one.
Wow! I truly was trying to be helpful by pointing out what I thought was an oversight in Scot's review. This exchange was really not what I expected.
Scot may have thousands of loyal subscribers. I think I only have one (Hi Mom!), but I think she's getting better advice.
No, I won't be subscribing to Scot's newsletter. My first encounter didn't leave me feeling like I'd discovered an expert.
Mon, 14 Jul 2003
Like the Nike commercials
Stage 9 of the Tour de France, Bourg d'Oisans to Gap, was perhaps the most thrilling TDF stage I've ever followed. Numerous breakaways were chased down. Lance Armstrong lost his overall lead, at one point over 5 minutes behind the stage leaders, then regained it to finish just 36 seconds behind the stage winner. The winner, Alexandre Vinokourov, of the Telekom team is now only 21 seconds behind Lance in the overall standings.
Lance narrowly avoided a crash that took second place, overall, Joseba Beloki, out of the the tour. He went down hard on a fast corner just ahead of Lance. Beloki sufferred a
fractured upper femur, a complex fracture of the right elbow, a simple fracture of a right finger and multiple contusions to the hip.
Beloki's crash cut off Armstrong's path forcing him off the road.
Just like a Nike commercial, Lance went cross country, cutting the corner and rejoining his group on the road. Tyler Hamilton, another incredible story this year, a former teammate of Armstrong, gave him an amazed, congratulatory pat on the back as Lance remounted his bike to finish the last few kilometers of the race.
Hamilton, who broke his collar bone in a crash in stage 1, has continued not only to ride, but to ride at the front. He's fifth overall, less than two minutes behind the yellow jersey.
I generally take a few minutes in the morning to read an article or two about the day's Tour de France coverage. After reading about today's stage I had to arrange to watch the television coverage after work with my bikin' buddy, Tim Maher. I don't get the Outdoor Life Network channel; Tim does, so I invited myself over. (Sorry Michele!)
There are literally hundreds of articles about the Internet about today's Tour de France stage to feast on:
Sat, 12 Jul 2003
Highway 27 Climb
This morning, for the first time this year, I rode up the hill on highway 27.
I made two loops:
- from 32nd Avenue south on Highway 27, up the 1.35 mile, 4% grade,
- right on Dismhman-Mica Road, back down to the Painted Hills golf course,
- right on Thorpe,
- left on Madison,
- then right back onto 32nd Avenue.
I time the climbs from the reflector pole at the base of the hill to the last reflector pole before the climb flattens and the road begins to curve left.
Somewhere (hopefully not on the hard drive from the old Windows system that died) I have times from prior years. It seems to me I had gotten my times down under 6 minutes and was hoping to get down to 5. I was younger, lighter, and in better shape then.
Today's climb times were 9:04.5 and 9:04.9. Consistently slow. <g>
There was a strong headwind to fight or the times would have been slightly better, but I obviously have a long way to go to regain my prior fitness level.
Fri, 11 Jul 2003
Happy Birthday, Christopher!
Wow! The years have gone by way too fast. Our little boy is all grown
up. We had been parents for 21 months when Chris was born; we thought
we had the game all figured out. Chris quickly taught us how
wonderfully wrong we were. Some children need strong discipline, strict
guidelines, and constant supervision. Chris, crushed by a harsh word,
needed only encouragement, love, advice, and challenge.
Happy 21st, Chris!
Tue, 08 Jul 2003
SMTP Authentication in Exim
At work, we recently took our Microsoft Exchange Server off the front lines. It still handles internal mail, but all external connections are made via Linux servers running Exim.
The motivation for the change was spam. We discovered we could eliminate about 50% of our spam by using the Spamhaus RBL. It is trivial to configure Exim to use an RBL. The same can't be said for Exchange Server. Simply making a Linux server the primary MX wasn't enough. The spammers just backed off to other MX hosts, the Exchange Server being one of them.
So, we configured back-up MX support on three separate domains each on different broadband networks. They each provide backup MX for the other two and they each use the same RBLs. Spam on all three domains dropped dramatically.
We had, however, relied on the Exchange Server to provide our road warriors with SMTP access. We allowed relaying from IP address on the internal network and for authenticated connections from the Internet.
I was unable to find a way to allow relaying for authenticated connections while disallowing any mail delivery from unauthenticated connections. So, I simply added SMTP authentication support to one of the Exim servers.
The following configuration was added to a new, 7th section in the exim.conf file:
# End the Rewrite section. It was implicitly ended here before,
# because this was the end of the file.
end
################################################################
# AUTHENTICATION CONFIGURATION #
################################################################
auth_login:
driver = plaintext
public_name = LOGIN
server_prompts = "Username:: : Password::"
server_condition = "${if eq{$2}{${lookup{$1}lsearch\
{/etc/exim/passwd}{$value}fail}}{1}{0}}"
server_set_id = $1
auth_plain:
driver = plaintext
public_name = PLAIN
server_condition = "${if eq{$3}{${lookup{$2}lsearch\
{/etc/exim/passwd}{$value}fail}}{1}{0}}"
server_set_id = $2
auth_cram:
driver = cram_md5
public_name = CRAM-MD5
server_secret = "${lookup{$1}lsearch{/etc/exim/passwd}\
{$value}fail}"
server_set_id = $1
I started with CRAM-MD5 hoping, but not expecting, the remote Microsoft Outlook clients would use it to authenticate without sending clear text passwords. Not surprisingly, Outlook did not use it.
Next, I added the PLAIN method. This time, I was surprised when Outlook did not use it. I resorted to sniffing the authentication transactions between an Outlook client and the Exchange Server and discovered that the LOGIN method was being used. So, finally, I added LOGIN support. The other two remain to support any mail clients we may employ in the future that use them.
The password file /etc/exim/passwd is a simple key value list of user
IDs and passwords:
alice: sea-kert
bob: mySecret
One step closer to a non-Microsoft network!
Sun, 06 Jul 2003
Getting mail to AOL users
Since finally getting broadband Internet access a few weeks ago, I have very much enjoyed the ability to host my own web server and mail server.
Today, however, I had trouble sending e-mail to a couple of AOL users in my address book. I remembered reading a /. article about AOL blocking e-mail from DSL hosted accounts, so I immediately recognized the problem.
Fortunately, solving it was trivial. I prefer to let my mail server, running Exim, send mail directly, but adding a smarthost router entry for AOL was quick, easy, and solved the problem:
smarthost:
driver = domainlist
transport = remote_smtp
route_list = "aol.com smtp.comcast.net bydns_a"
I just inserted the smarthost entry ahead of my default lookuphost router entry. Now, mail to aol.com users is sent via my ISP's mail server. Everything else is still sent directly.
Sat, 05 Jul 2003
While you were away…
April and I had
some fun. Family friends asked her to care for their animals while they
were away for the holiday weekend. They told her to feel free to use
the pool. So, even before they left town, we hatched a plan for a bit
of a prank,
Internet style.
Yesterday, we drove over with a grocery sack full of empty beer bottles as props and a digital camera. April took pictures while I modeled my swim wear. (No commercial offers, please — it’s just a hobby. <g>)
Our biggest problem was finding empty beer bottles. Where do you find them the day after trash pickup and a holiday to boot? Sad, but true, I dumped many good bottles of perfectly good beer down the drain. Our little project was more important at the time than our cooler full of beer.
You can see a few more of our favorite shots here.
Wed, 02 Jul 2003
First flat
I left the office at 5:15. At home, we've been working on a house painting/repair project for weeks. Cheaply built in the mid-70s, the house needed poorly sealed windows, weather damaged fascia boards, and a dry rotted false chimney replaced.
Christopher was scheduled to work 6 PM to close at his summer job. If I made it home by 5:30, that would get me 15 minutes to get the heavy panels for the false chimney I assembled yesterday onto the roof before he left for work.
I carried the bike up the outside stairs from the basement before realizing the back tire was flat. Sigh. Oh well. Back inside to fix my first flat of the year.
Halfway through the tube replacement, I was paged. Had to take a support call.
Now, this particular user's initials are TDS. He's my employer. (And if I've exceeded the boundaries of his sense of humor, that last statement may only be true in the past-tense!) By force of authority, TDS reverses the troubleshooting process. Instead of starting with the most likely problem (user error), and working forward (user's desktop computer, …, mail server), we have to work in reverse.
The mail server is down.
I check the server. It's up and running. I can connect from inside. I
ssh to an external system and try from there. "The server is up and
running and it is accessible from the outside," I report.
We go from there to checking server logs for authentication errors, firewall rules, and eventually, packet sniffing to watch the inbound and outbound packets on port 25. Nothing.
Perhaps your ISP is now blocking port 25 access,
I venture. Testing
that hypothesis, I have him check various other mail servers with
telnet to port 25. No luck. We seem to be confirming the theory.
I have him try the POP3 port. If his ISP has blocked port 25, we will have to use their SMTP server for outbound mail. He should still be able to retrieve mail directly from the company's mail server, though.
No luck. Then, in the midst of failed attempts to connect to other servers, I see a series of packets exchanged between his IP address and our POP3 server.
What did you do differently,
I query.
Nothing.
Hmmm. Go see if Brenda can receive mail.
TDS runs a small home
network, and Brenda, his better half, has a mail account.
Sure enough, Brenda can send and receive mail, and it was a periodic
mail check I had seen with tcpdump.
Well, obviously, it's your system,
I say.
How can that be?
Are you running Windows?
Yes. I blame everything on
Windows. It's easy, and usually correct.
No,
he says, I'm running Linux.
An outright lie, of course. If he
was running Linux, we wouldn't be having this
conversation. First, Linux wouldn't be behaving this way. Second, any
user capable of running Linux could troubleshoot this problem without my
assistance. No offense to the hand that feeds me. <g>
Well, then, it's a hardware problem.
What's that line? The first
liar doesn't have a prayer — I learned it from TDS.
Are you running a virus scanner?
Yes, of course. I updated it today.
Ah-ha!
"Let's see. It's supposed to be scanning incoming and outgoing e-mail, but there's an error icon."
A config change (unadmitted, of course) and reboot, and he's receiving mail, again.
And I make it home by 7. Just enough time left to haul the components for the false chimney up on the roof without Christopher and assemble them before an advancing thunderstorm chases me off the off.
Damn, that was a pretty sunset behind those lightning bolts from my vantage point on the roof. <g>
About this weblog
This site is the personal weblog of Marc Mims. You can contact Marc
by sending e-mail to:
[email protected].
Marc writes here about cycling, programming, Linux, and other items of personal interest.
This site is syndicated with RSS.
Archives
Credits
CSS stolen from Tom Coates who didn't even complain.