Postfix "lost connection after DATA from unknown..." and ipfilter "-AF OUT" log message

[Jim Seymour]

Hi All,

This may be a weird one, and may be completely OT. If the latter:
Feel free to tell me to bugger off :)

System is FreeBSD 8.2, running ipfilter and
postfix-current-2.9.20111119,4.

Occasionally I see something like this from ipfilter in
/var/log/messages:

bge1 @0:24 b <my_outside_ip>,25 -> 89.73.201.168,36545 PR tcp len
20 40 -AR OUT

Looking in /var/log/maillog...

Dec 11 17:47:08 myhost postfix/smtpd[48290]: connect from
unknown[89.73.201.168]
Dec 11 17:47:10 myhost postfix/smtpd[48290]: NOQUEUE: reject:
RCPT from unknown[89.73.201.168]: 450 4.7.1 Client host
rejected: cannot find your reverse hostname, [89.73.201.168];
from=<an...@carloerbareactifs.com> to=<nng...@mydom.ain>
proto=ESMTP helo=<89-73-201-168.dynamic.chello.pl>
Dec 11 17:47:11 myhost postfix/smtpd[48290]: lost connection
after DATA from unknown[89.73.201.168]
Dec 11 17:47:11 myhost postfix/smtpd[48290]: disconnect from
unknown[89.73.201.168]

This particular one occurred seven times in a row, in quick
succession.

I've searched on this *fairly* seriously and come up with nothing.
Anybody got any idea what this is?

Thanks,
Jim
--
Note: My mail server employs *very* aggressive anti-spam
filtering. If you reply to this email and your email is
rejected, please accept my apologies and let me know via my
web form at <http://jimsun.LinxNet.com/contact/scform.php>.

[Reindl Harald]

Am 12.12.2011 00:10, schrieb Jim Seymour:
> Occasionally I see something like this from ipfilter in
> /var/log/messages:
>
> bge1 @0:24 b <my_outside_ip>,25 -> 89.73.201.168,36545 PR tcp len
> 20 40 -AR OUT
>
> Looking in /var/log/maillog...
>
> Dec 11 17:47:08 myhost postfix/smtpd[48290]: connect from
> unknown[89.73.201.168]
> Dec 11 17:47:10 myhost postfix/smtpd[48290]: NOQUEUE: reject:
> RCPT from unknown[89.73.201.168]: 450 4.7.1 Client host
> rejected: cannot find your reverse hostname, [89.73.201.168];
> from=<an...@carloerbareactifs.com> to=<nng...@mydom.ain>
> proto=ESMTP helo=<89-73-201-168.dynamic.chello.pl>
> Dec 11 17:47:11 myhost postfix/smtpd[48290]: lost connection
> after DATA from unknown[89.73.201.168]
> Dec 11 17:47:11 myhost postfix/smtpd[48290]: disconnect from
> unknown[89.73.201.168]
>
> This particular one occurred seven times in a row, in quick
> succession.
>
> I've searched on this *fairly* seriously and come up with nothing.
> Anybody got any idea what this is?

why do you use "reject_unknown_reverse_client_hostname" if you do not
like the results of it?

[Wietse Venema]

Jim Seymour:

> Hi All,
>
> This may be a weird one, and may be completely OT. If the latter:
> Feel free to tell me to bugger off :)
>
> System is FreeBSD 8.2, running ipfilter and
> postfix-current-2.9.20111119,4.
>

> Occasionally I see something like this from ipfilter in
> /var/log/messages:
>
> bge1 @0:24 b <my_outside_ip>,25 -> 89.73.201.168,36545 PR tcp len
> 20 40 -AR OUT

Why are you blocking outbound TCP RST?

Wietse

[Sahil Tandon]

On Sun, 2011-12-11 at 18:10:34 -0500, Jim Seymour wrote:

> Looking in /var/log/maillog...
>
> Dec 11 17:47:08 myhost postfix/smtpd[48290]: connect from
> unknown[89.73.201.168]
> Dec 11 17:47:10 myhost postfix/smtpd[48290]: NOQUEUE: reject:
> RCPT from unknown[89.73.201.168]: 450 4.7.1 Client host
> rejected: cannot find your reverse hostname, [89.73.201.168];
> from=<an...@carloerbareactifs.com> to=<nng...@mydom.ain>
> proto=ESMTP helo=<89-73-201-168.dynamic.chello.pl>
> Dec 11 17:47:11 myhost postfix/smtpd[48290]: lost connection
> after DATA from unknown[89.73.201.168]
> Dec 11 17:47:11 myhost postfix/smtpd[48290]: disconnect from
> unknown[89.73.201.168]
>
> This particular one occurred seven times in a row, in quick
> succession.

Postfix sends a 450 response because your DNS server cannot find the
client's reverse hostname; following that, the client foolishly sends
DATA, to which Postfix responds with a 554. Finally, instead of
gracefully QUITing, the client drops the connection.

--
Sahil Tandon

[Jim Seymour]

On Mon, 12 Dec 2011 00:14:08 +0100
Reindl Harald <h.re...@thelounge.net> wrote:
[snip]

>
> why do you use "reject_unknown_reverse_client_hostname" if you do
> not like the results of it?

Why do you answer the question when you obviously have not read it?
(Or at least apparently not understood it.)

Regards,

[Reindl Harald]

Am 12.12.2011 01:04, schrieb Jim Seymour:
> On Mon, 12 Dec 2011 00:14:08 +0100
> Reindl Harald <h.re...@thelounge.net> wrote:
> [snip]
>>
>> why do you use "reject_unknown_reverse_client_hostname" if you do
>> not like the results of it?
>
> Why do you answer the question when you obviously have not read it?
> (Or at least apparently not understood it.)

wtf - i have read your log-snippet and explained you what
"cannot find your reverse hostname" means

what "bge1 @0:24 b <my_outside_ip>,25 -> 89.73.201.168,36545 PR tcp len"
means i have not commented since i am not a bsd-user, if this is your
only question so why do you post maillog-snippets?

[Jim Seymour]

On Sun, 11 Dec 2011 18:35:23 -0500 (EST)
Wietse Venema <wie...@porcupine.org> wrote:

[snip]

>
> Why are you blocking outbound TCP RST?

I am not, to the best of my knowledge.

There is a TCP control traffic rate limit in the border router, there
as a DoS prevention tactic, but that's it.

This doesn't happen all the time. It doesn't even happen often. Out
of nearly 6000 connections, today, there are 145 various "A.. OUT" and
"A.. OUT OOW" messages. Each of them occurs two-or-more times,
involving the same contacting IP.

[Jim Seymour]

On Mon, 12 Dec 2011 01:11:00 +0100

Reindl Harald <h.re...@thelounge.net> wrote:

>
>
> Am 12.12.2011 01:04, schrieb Jim Seymour:
> > On Mon, 12 Dec 2011 00:14:08 +0100
> > Reindl Harald <h.re...@thelounge.net> wrote:
> > [snip]
> >>
> >> why do you use "reject_unknown_reverse_client_hostname" if you do
> >> not like the results of it?
> >
> > Why do you answer the question when you obviously have not read
> > it? (Or at least apparently not understood it.)
>
> wtf - i have read your log-snippet and explained you what
> "cannot find your reverse hostname" means

I know what "cannot find your reverse hostname" means.

>
> what "bge1 @0:24 b <my_outside_ip>,25 -> 89.73.201.168,36545 PR tcp
> len" means i have not commented since i am not a bsd-user, if this
> is your only question so why do you post maillog-snippets?

To show the relationship between the information in the two logfiles.

If it was *purely* a FBSD or ipfilter question (which I allowed as
how it might actually be), I'd have asked in a FBSD or ipfilter forum.

[Jim Seymour]

On Sun, 11 Dec 2011 19:15:35 -0500
Jim Seymour <jsey...@LinxNet.com> wrote:

> Each of them occurs two-or-more
> times, involving the same contacting IP.

Clarification: That was to say that, when it occurs multiple times
in a row, it's the same IP trying over-and-over again in each set of
retries. A total of 17 unique IPs have been involved in such
occurrences today.

In fact: No client has tried less than twice in a row, most have
averaged around six tries. Some up to a dozen or more.

[Jim Seymour]

On Sun, 11 Dec 2011 18:41:56 -0500
Sahil Tandon <sahil+...@tandon.net> wrote:

[snip]

>
> Postfix sends a 450 response because your DNS server cannot find the
> client's reverse hostname; following that, the client foolishly
> sends DATA, to which Postfix responds with a 554. Finally, instead
> of gracefully QUITing, the client drops the connection.

I see. So the "odd" ipfilter message is probably as a result of the
client pulling the rug out from under the connection, as it were?

Thanks,

[Wietse Venema]

Wietse Venema:

> > bge1 @0:24 b <my_outside_ip>,25 -> 89.73.201.168,36545 PR tcp len

> > 20 40 -AR OUT

>
> Why are you blocking outbound TCP RST?

According to ipmon(8), -AR means the ACK and RST flags are set.
My question is why is your firewall blocking outbound ACK|RST?

Wietse

[Jim Seymour]

On Sun, 11 Dec 2011 20:03:59 -0500 (EST)
Wietse Venema <wie...@porcupine.org> wrote:

> Wietse Venema:
> > > bge1 @0:24 b <my_outside_ip>,25 -> 89.73.201.168,36545 PR
> > > tcp len 20 40 -AR OUT
> >
> > Why are you blocking outbound TCP RST?
>
> According to ipmon(8),

The web is rotting my brain. I never thought to actually check, you
know, the manual page.

Good. Grief.

> -AR means the ACK and RST flags are set.
> My question is why is your firewall blocking outbound ACK|RST?

I'm using basically "canned" rulesets in my ipfilter setup. That is
the default deny at the end of bge1's output filters.

I must've messed-up, somewhere. I'll take a look in the morning.

Thanks, Wietse, Sahil, for the education.

Regards,

[James Seymour]

On Sun, 11 Dec 2011 22:57:12 -0500
Jim Seymour <jsey...@LinxNet.com> wrote:

> On Sun, 11 Dec 2011 20:03:59 -0500 (EST)
> Wietse Venema <wie...@porcupine.org> wrote:
>
> > Wietse Venema:
> > > > bge1 @0:24 b <my_outside_ip>,25 -> 89.73.201.168,36545 PR
> > > > tcp len 20 40 -AR OUT
> > >
> > > Why are you blocking outbound TCP RST?

[snip]

>
> > -AR means the ACK and RST flags are set.
> > My question is why is your firewall blocking outbound ACK|RST?
>
> I'm using basically "canned" rulesets in my ipfilter setup. That is
> the default deny at the end of bge1's output filters.
>
> I must've messed-up, somewhere. I'll take a look in the morning.

[snip]

Looking at it with fresh eyes, fortified by a cup of coffee :), if I
messed-up, I'll be darned if I can see where. The firewall rules
related to this couldn't be more straight-forward:

.
.
.
pass out quick on bge1 proto tcp from any to any port = 25 keep state
.
.
.
block out log first quick on bge1 all


That's it.

[Wietse Venema]

James Seymour:

> > > -AR means the ACK and RST flags are set.
> > > My question is why is your firewall blocking outbound ACK|RST?
> >
> > I'm using basically "canned" rulesets in my ipfilter setup. That is
> > the default deny at the end of bge1's output filters.
> >
> > I must've messed-up, somewhere. I'll take a look in the morning.
> [snip]
>
> Looking at it with fresh eyes, fortified by a cup of coffee :), if I
> messed-up, I'll be darned if I can see where. The firewall rules
> related to this couldn't be more straight-forward:
>
> .

> pass out quick on bge1 proto tcp from any to any port = 25 keep state
> .

> block out log first quick on bge1 all
>
> That's it.

There are two stateful engines: the TCP stack and ipfilter.

With "keep state", ipfilter "remembers" the connection and lets
packets pass, up to the point that ipfilter believes the connection
no longer exists.

The TCP stack sends an outbound ACK|RST because it received *something*
on port 25. Your firewall should not have passed that. Perhaps you
don't have "flags S keep state" for inbound port 25 traffic.

Wietse

[James Seymour]

On Mon, 12 Dec 2011 08:24:38 -0500 (EST)
Wietse Venema <wie...@porcupine.org> wrote:

[snip]

>
> There are two stateful engines: the TCP stack and ipfilter.

*nodding*

>
> With "keep state", ipfilter "remembers" the connection and lets
> packets pass, up to the point that ipfilter believes the connection
> no longer exists.

Understood.

>
> The TCP stack sends an outbound ACK|RST because it received
> *something* on port 25. Your firewall should not have passed that.

Should not have passed it *incoming*, do you mean?

> Perhaps you don't have "flags S keep state" for inbound port 25
> traffic.

I do:

# SMTP to gateway
pass in quick on bge1 proto tcp from any to any port = 25 flags S
keep state

(The stuff all says "any" because there are only two devices in the
DMZ: The border router's "inside" interface and the firewall's
"outside" one. It's a true DMZ.)

[Wietse Venema]

James Seymour:

> > The TCP stack sends an outbound ACK|RST because it received
> > *something* on port 25. Your firewall should not have passed that.
>
> Should not have passed it *incoming*, do you mean?

Indeed (assuming that ipfilter actually tracks state in the exact
same way as the TCP stack, which is an assumption that may not
be valid).

Wietse

[James Seymour]

I think it's only happening with spammer/scammer attempts. I'll write
up a litte ad hoc script to reconcile the ipmon entries with the
maillog. If it's only abusive behaviour when which it happens, I don't
know as it's worth putting much time into?