Re: Spamd sending packets from 127.0.0.1 to the outside?

Previous thread: Re: Seg fault by cc1 on AMD-K6-2 by Mats Erik Andersson on Monday, December 10, 2007 - 6:44 am. (1 message)

Next thread: ACX on Thinkpad A31 by Chris Eidem on Monday, December 10, 2007 - 11:14 am. (2 messages)
To: <misc@...>
Date: Monday, December 10, 2007 - 10:14 am

Hello,

I am running OpenBSD 4.2-stable
I just noticed that spamd is trying to send ack packets from 127.0.0.1 to the IP
of the sender when it hits the greytrap IP. I don't feel this is wanted
behavior. Has anymone any idea of why it is doing so? It doesn't seem to be due
to the "set skip on lo" as even when I remove it, it spamd continues to do so.

Here is the symptom:
tcpdump -ttt -n -e -i em0 host 127.0.0.1

tcpdump: listening on em0, link-type EN10MB
Dec 10 15:01:43.176753 00:15:17:19:0e:be 00:04:23:09:79:68 0800 54:
127.0.0.1.8025 > 213.134.27.110.62745: R 1407486039:1407486039(0) ack 2902409159
win 0

spamdb | grep 213.134.27.110
TRAPPED|213.134.27.110|1197313245

My config:

/etc/pf.conf
ext_if="em0"
table <spf-no-greylist> persist
table <spamd-white> persist
table <no-greylist> { 195.238.0.0/21 , 216.23.191.47 , 212.234.67.22 ,
146.82.138.6 }
set skip on lo
set limit table-entries 1000000
scrub on $ext_if all no-df random-id min-ttl 30 reassemble tcp fragment reassemble
no rdr on $ext_if inet proto tcp from { <spamd-white>, 157.164.0.0/16,
<no-greylist>, <spf-no-greylist> , 193.190.18.193 , 193.190.18.212 } to
($ext_if) port smtp
rdr pass on $ext_if inet proto tcp from any to ($ext_if) port smtp -> 127.0.0.1
port spamd

em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 00:15:17:19:0e:be
groups: egress
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet 157.164.187.68 netmask 0xffffff00 broadcast 157.164.187.255
inet6 fe80::215:17ff:fe19:ebe%em0 prefixlen 64 scopeid 0x1
inet 157.164.187.78 netmask 0xffffff00 broadcast 157.164.187.255

spamdb is launched with:
/usr/libexec/spamd -S 30 -s 2 -v -G7:24:864 -4 -h greylist.wallonie.be -n '' -y
em1 -Y em1 -d -M 157.164.187.78

Best Regards

To: <misc@...>
Date: Monday, December 10, 2007 - 10:42 am

ACK packets are part of any two-way TCP/IP communication. Spamd's
mission with respect to blacklisted hosts is to waste spammers' time
by replying slowly. If you primarily want to blackhole rather than
greylist and tarpit, spamd is not the tool you are looking for.

--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.datadok.no/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

To: Peter N. M. Hansteen <peter@...>
Cc: <misc@...>
Date: Monday, December 10, 2007 - 11:24 am

I know that ack packets are one part of the two-way TCP/IP communication.
However sending ack packets with an originating IP of 127.0.0.1 to any non local
(! 127.0.0.0/8) IP shouldn't happen, as they will never get back to (or at least
be accepted by) the sender. So in my mind it is not normal behaviour or it is
some kind of bug.

To: Renaud Allard <renaud@...>
Cc: Peter N. M. Hansteen <peter@...>, <misc@...>
Date: Monday, December 10, 2007 - 11:50 am

On Mon, Dec 10, 2007 at 04:24:03PM +0100, Renaud Allard wrote:
| Peter N. M. Hansteen wrote:
| > Renaud Allard <renaud@llorien.org> writes:
| >
| >> I just noticed that spamd is trying to send ack packets from 127.0.0.1 to the IP
| >> of the sender when it hits the greytrap IP. I don't feel this is wanted
| >> behavior. Has anymone any idea of why it is doing so?
| >
| > ACK packets are part of any two-way TCP/IP communication. Spamd's
| > mission with respect to blacklisted hosts is to waste spammers' time
| > by replying slowly. If you primarily want to blackhole rather than
| > greylist and tarpit, spamd is not the tool you are looking for.
| >
|
| I know that ack packets are one part of the two-way TCP/IP communication.
| However sending ack packets with an originating IP of 127.0.0.1 to any non local
| (! 127.0.0.0/8) IP shouldn't happen, as they will never get back to (or at least
| be accepted by) the sender. So in my mind it is not normal behaviour or it is
| some kind of bug.

Have you actually seen these packets live on the wire ?

I doubt it. In general (the recommended setup), pf redirects incoming
requests to 127.0.0.1:8025, the port where spamd is listening *on
localhost*. Replies such as ACK's etc. *MUST* originate from
127.0.0.1:8025 in this case. PF will take care of rewriting the packet
to the address the client originally used to contact your mailserver
(spamdserver).

Unless you can demonstrate packets *on the wire* with 127.0.0.1 src
addresses, I think spamd and pf are doing their job just fine.

Cheers,

Paul 'WEiRD' de Weerd

+++++++++++>-]<.>++[<------------>-]<+.--------------.[-]
http://www.weirdnet.nl/

To: Renaud Allard <renaud@...>
Cc: Peter N. M. Hansteen <peter@...>, <misc@...>
Date: Monday, December 10, 2007 - 12:02 pm

Hi Renaud,

On Mon, Dec 10, 2007 at 04:50:36PM +0100, Paul de Weerd wrote:
| Have you actually seen these packets live on the wire ?

I re-read your original mail, and it turns out you have seen these
packets on the wire. Sorry for the too-quick-answer ;P

| I doubt it. In general (the recommended setup), pf redirects incoming
| requests to 127.0.0.1:8025, the port where spamd is listening *on
| localhost*. Replies such as ACK's etc. *MUST* originate from
| 127.0.0.1:8025 in this case. PF will take care of rewriting the packet
| to the address the client originally used to contact your mailserver
| (spamdserver).

For some reason, pf doesn't seem to take care of rewriting the return
traffic where it should. Can you confirm there is a matching pf-state
in the state table when you see this sort of traffic ?

Paul 'WEiRD' de Weerd

+++++++++++>-]<.>++[<------------>-]<+.--------------.[-]
http://www.weirdnet.nl/

To: Paul de Weerd <weerd@...>
Cc: Peter N. M. Hansteen <peter@...>, <misc@...>
Date: Monday, December 10, 2007 - 12:11 pm

No problem. The firewall admin told me he was blocking packets from 127.0.0.1

It is quite hard to capture as it seems sporadic and servers are heavy loaded:

tcpdump: listening on em0, link-type EN10MB
Dec 10 17:07:18.585359 00:15:17:19:0e:be 00:04:23:09:79:68 0800 113:
127.0.0.1.8025 > 217.132.142.68.2199: FP 959669614:959669673(59) ack 2605929486
win 65535

all tcp 127.0.0.1:8025 <- 157.164.187.68:25 <- 217.132.142.68:4557
FIN_WAIT_2:FIN_WAIT_2
all tcp 127.0.0.1:8025 <- 157.164.187.68:25 <- 217.132.142.68:1052
FIN_WAIT_2:FIN_WAIT_2
all tcp 127.0.0.1:8025 <- 157.164.187.68:25 <- 217.132.142.68:1181
FIN_WAIT_2:FIN_WAIT_2
all tcp 127.0.0.1:8025 -> 217.132.142.68:2199 CLOSING:CLOSED

I guess the last one is the one I see on the firewall.

--
010100100110010101101110011000010111010101100100
010000010110110001101100011000010111001001100100

[demime 1.01d removed an attachment of type application/x-pkcs7-signature which had a name of smime.p7s]

To: Renaud Allard <renaud@...>
Cc: <misc@...>
Date: Monday, December 10, 2007 - 11:47 am

yYou're right, that is odd. My reading skills must be sligtly off
this afternoon.

--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.datadok.no/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Previous thread: Re: Seg fault by cc1 on AMD-K6-2 by Mats Erik Andersson on Monday, December 10, 2007 - 6:44 am. (1 message)

Next thread: ACX on Thinkpad A31 by Chris Eidem on Monday, December 10, 2007 - 11:14 am. (2 messages)