Scott Kitterman wrote:
-----Original Message-----
I'm not a 100% sure on the calculations either, and I was hoping that
someone would go over them and do a sanity check. Hopefully not
Scott-style, but more of an engineering check, where my assumptions are
checked as well as my calculations and results. Perhaps David would do
this ? :) Hint, hint, thank you in advance :)
OK. Let's try it again.
I think your scenario is based on a fundamental misunderstanding of how SMTP
works.
Be going back to RFC 2821, I was trying to check your assumptions.
I think they are wrong and your single 60 byte UDP packet has no effect.
First of all, it's not a UDP packet. It's a TCP packet. Second I said
that there was some connection handshake (a couple of _small_ packets
back and forth), and then the 60-byte packet.
Have a look at the following ethereal trace (I'm sorry about the
wrapping, please view in a wider window).
the setup is SMTP, virus and DNS running on the same machine, so the
same IP address shows for all transactions. I have manually changed the
packets that come from or go to the virus by indicating an ip of
"192.168.1.10". All other packets are between the SMTP server and the
local NS server.
If anyone other than Scott has doubts, I will try to run this again from
a different machine so that it's easier to identify the source of
destination of each packet.
[root(_at_)sun libspf2]# /usr/sbin/tethereal -i lo
Capturing on lo
0.003086 192.168.1.10 -> 192.168.1.11 TCP 3216 > smtp [SYN] Seq=0
Ack=0 Win=32767 Len=0 MSS=16396 TSV=295033318 TSER=0 WS=0
0.003124 192.168.1.11 -> 192.168.1.10 TCP smtp > 3216 [SYN, ACK]
Seq=0 Ack=1 Win=32767 Len=0 MSS=16396 TSV=295033318 TSER=295033318 WS=0
0.003156 192.168.1.10 -> 192.168.1.11 TCP 3216 > smtp [ACK] Seq=1
Ack=1 Win=32767 Len=0 TSV=295033318 TSER=295033318
^^^^^^^^^^^^^^ this has been the connection exchange
0.006710 192.168.1.11 -> 192.168.1.11 DNS Standard query PTR
11.1.168.192.in-addr.arpa
0.007416 192.168.1.11 -> 192.168.1.11 DNS Standard query response PTR
sun.ohmi.org
0.008168 192.168.1.11 -> 192.168.1.11 DNS Standard query PTR
11.1.168.192.in-addr.arpa
0.008725 192.168.1.11 -> 192.168.1.11 DNS Standard query response PTR
sun.ohmi.org
0.009303 192.168.1.11 -> 192.168.1.11 DNS Standard query A sun.ohmi.org
0.009911 192.168.1.11 -> 192.168.1.11 DNS Standard query response A
192.168.1.11
^^^^^^^^^^ Here is the SMTP server doing it's PTR thing. I don't know
why it's being done twice.
0.015013 192.168.1.11 -> 192.168.1.11 SMTP Response: 220 sun.ohmi.org
ESMTP Sendmail. Aloha!
^^^^^^^^^^^ Here is the SMTP server showing its banner.
0.015051 192.168.1.11 -> 192.168.1.10 TCP 3216 > smtp [ACK] Seq=1
Ack=42 Win=32767 Len=0 TSV=295033319 TSER=295033319
^^^^^^^^^^ I don't know what this is.
0.024788 192.168.1.10 -> 192.168.1.11 SMTP Command: ehlo u
^^^^^^^^^^ this is the 60 byte packet. Ethereal's dissector only shows
the 1st line.
The packet I used is (smaller than 60). Since your ISP fixed their SPF
record, it generates much less DNS traffic:
ehlo u
mail from: <b(_at_)pobox(_dot_)com>
rcpt to: <radu(_at_)ohmi(_dot_)org>
0.024826 192.168.1.11 -> 192.168.1.10 TCP smtp > 3216 [ACK] Seq=42
Ack=59 Win=32767 Len=0 TSV=295033320 TSER=295033320
0.026579 192.168.1.11 -> 192.168.1.11 DNS Standard query A pobox.com
0.060684 192.168.1.11 -> 192.168.1.11 DNS Standard query response A
207.8.226.7
0.065216 192.168.1.11 -> 192.168.1.11 DNS Standard query TXT
spf.trusted-forwarder.org
0.066048 192.168.1.11 -> 192.168.1.11 DNS Standard query response TXT
0.067765 192.168.1.11 -> 192.168.1.11 DNS Standard query A
11.1.168.192.wl.trusted-forwarder.org
0.068304 192.168.1.11 -> 192.168.1.11 DNS Standard query response, No
such name
0.069336 192.168.1.11 -> 192.168.1.11 DNS Standard query PTR
11.1.168.192.in-addr.arpa
0.069884 192.168.1.11 -> 192.168.1.11 DNS Standard query response PTR
sun.ohmi.org
0.070844 192.168.1.11 -> 192.168.1.11 DNS Standard query A sun.ohmi.org
0.071439 192.168.1.11 -> 192.168.1.11 DNS Standard query response A
192.168.1.11
0.072407 192.168.1.11 -> 192.168.1.11 DNS Standard query A
sun.ohmi.org.wl.trusted-forwarder.org
0.072913 192.168.1.11 -> 192.168.1.11 DNS Standard query response, No
such name
0.073853 192.168.1.11 -> 192.168.1.11 DNS Standard query TXT pobox.com
0.074506 192.168.1.11 -> 192.168.1.11 DNS Standard query response TXT
0.075509 192.168.1.11 -> 192.168.1.11 DNS Standard query MX pobox.com
0.076477 192.168.1.11 -> 192.168.1.11 DNS Standard query response MX
10 mx-pa-2.pobox.com MX 10 mx-pa-5.pobox.com MX 10 mx-pa-7.pobox.com MX
10 mx-all.pobox.com MX 10 mx-il-1.pobox.com MX 10 mx-il-2.pobox.com MX
10 mx-il-3.pobox.com MX 10 mx-pa-1.pobox.com
0.077757 192.168.1.11 -> 192.168.1.11 DNS Standard query A
mx-pa-2.pobox.com
0.078428 192.168.1.11 -> 192.168.1.11 DNS Standard query response A
207.8.226.3
0.079430 192.168.1.11 -> 192.168.1.11 DNS Standard query A
mx-pa-5.pobox.com
0.080084 192.168.1.11 -> 192.168.1.11 DNS Standard query response A
208.210.124.70
0.081037 192.168.1.11 -> 192.168.1.11 DNS Standard query A
mx-pa-7.pobox.com
0.112305 192.168.1.11 -> 192.168.1.11 DNS Standard query response A
207.8.226.2
0.113733 192.168.1.11 -> 192.168.1.11 DNS Standard query A
mx-all.pobox.com
0.114466 192.168.1.11 -> 192.168.1.11 DNS Standard query response A
207.8.226.3 A 208.58.1.193 A 208.58.1.194 A 208.58.1.198 A
208.210.124.70 A 208.210.124.73 A 207.8.226.2
0.115923 192.168.1.11 -> 192.168.1.11 DNS Standard query A
mx-il-1.pobox.com
0.116634 192.168.1.11 -> 192.168.1.11 DNS Standard query response A
208.58.1.193
0.117601 192.168.1.11 -> 192.168.1.11 DNS Standard query A
mx-il-2.pobox.com
0.118251 192.168.1.11 -> 192.168.1.11 DNS Standard query response A
208.58.1.194
0.119204 192.168.1.11 -> 192.168.1.11 DNS Standard query A
mx-il-3.pobox.com
0.119850 192.168.1.11 -> 192.168.1.11 DNS Standard query response A
208.58.1.198
0.120831 192.168.1.11 -> 192.168.1.11 DNS Standard query A
mx-pa-1.pobox.com
0.158524 192.168.1.11 -> 192.168.1.11 DNS Standard query response A
208.210.124.73
0.159677 192.168.1.11 -> 192.168.1.11 DNS Standard query MX
fallback-relay.pobox.com
0.160423 192.168.1.11 -> 192.168.1.11 DNS Standard query response MX
10 gretel.pobox.com
0.161982 192.168.1.11 -> 192.168.1.11 DNS Standard query A
gretel.pobox.com
0.162661 192.168.1.11 -> 192.168.1.11 DNS Standard query response A
208.58.1.197
0.163909 192.168.1.11 -> 192.168.1.11 DNS Standard query A
webmail.pobox.com
0.204830 192.168.1.11 -> 192.168.1.11 DNS Standard query response A
207.106.36.222
0.207072 192.168.1.11 -> 192.168.1.11 DNS Standard query A ohmi.org
0.207760 192.168.1.11 -> 192.168.1.11 DNS Standard query response A
216.187.106.200
0.231218 192.168.1.11 -> 192.168.1.11 SMTP Response: 250-sun.ohmi.org
Hello sun.ohmi.org [192.168.1.11], pleased to meet you
0.266560 192.168.1.10 -> 192.168.1.11 TCP 3216 > smtp [ACK] Seq=59
Ack=399 Win=32767 Len=0 TSV=295033345 TSER=295033341
15.226785 192.168.1.11 -> 192.168.1.10 TCP smtp > 3216 [FIN, ACK]
Seq=399 Ack=59 Win=32767 Len=0 TSV=295034841 TSER=295033345
15.230522 192.168.1.10 -> 192.168.1.11 TCP 3216 > smtp [FIN, ACK]
Seq=59 Ack=400 Win=32767 Len=0 TSV=295034841 TSER=295034841
15.230574 192.168.1.11 -> 192.168.1.10 TCP smtp > 3216 [ACK] Seq=400
Ack=60 Win=32767 Len=0 TSV=295034841 TSER=295034841
^^^^^^^^^^ This is the SMTP server timing out because no more commands
are coming. I have the timeout set to 15 seconds, much lower than the
installation default.
Obviously since the processes involved are on the same machine, and the
pobox's info is already in the DNS cache, the whole attack takes 263ms.
In the real world, this would clearly take longer.
I am not the world's greatest SMTP expert, so I'm quite willing to accept
that I'm the one that's wrong.
Next time don't contradict me based on ignorance. If you don't know what
you're saying, ask for more detailed explanations.
Before we move on and redesign SPF to take into account your amplification
factors, I'd like to understand if they are correct. I don't think they
are.
It appears that we are not communicating very well. I am not trying to
insult you. I am trying to figure this out. If I have, my apologies. It
wasn't intended.
It offends me that even though you do not run either a mail server, a
DNS server, nor a server-side spam filter, you have all these opinions
that I am wrong in so many ways. I usually speak from my own experience
of running an SMTP server with a backup MX (which sounds simpler than it
is), running a master DNS server with several slaves, as well as being a
slave to some other master DNS servers, and running a spam solution I
have created and integrated into sendmail myself. That also means that I
have some knowledge of the sendmail source code and inner functionality.
Sendmail is one of the most popular mail servers currently on the
internet. I don't mention the firewall, NAT router and so on. When I do
not speak from experience, I try hard to state all the assumptions I am
making such that if I do make a mistake, someone else can catch it and
point it out.
Radu.