Just spotted in my firewall log that painless uses IDENT auth calls

src="81.187.30.51:44942" dst="192.168.0.2:113" 

I am just dropping them. Two questions:

1) Why are the A&A email servers doing this? Google suggests it is 
very old practice.

2) What do others do about them? GRC suggests port forwarding them to 
nowhere.

TIA
-- 
Regards
Dave Saville

Dave Saville wrote:
> Just spotted in my firewall log that painless uses IDENT auth calls
> 
> src="81.187.30.51:44942" dst="192.168.0.2:113" 
> 
> I am just dropping them. Two questions:
> 
> 1) Why are the A&A email servers doing this? Google suggests it is 
> very old practice.
> 
> 2) What do others do about them? GRC suggests port forwarding them to 
> nowhere.

My firewalls (since 1993) have always had a line to respond
to these, possibly just reset.

Yep,  block return-rst proto tcp from any to any port = 113


David



> 
> TIA

Quoting  Dave Saville <dave@invalid.invalid>:
>Just spotted in my firewall log that painless uses IDENT auth calls
>src="81.187.30.51:44942" dst="192.168.0.2:113" 
>I am just dropping them.

Ident is widely misunderstood.

If A makes an SMTP (say) connection to B, and B does an ident lookup back,
A should provide an answer _for A's benefit_. B can't infer much from the
answer; if A is malicious, it could be a total lie. Often the answer will
now be encrypted and meaningless to B. 

So why bother? If A has multiple users some of whom may be malicious, and
gets a complaint from B with the results of B's ident lookup, A can use it
to identify the culprit.

So... do drop them unless _you_ have a use for it.
-- 
David Damerell  Kill the tomato!
Yesterday was Mania, September.
Today is Aponoia, September.
Tomorrow will be Epithumia, September - a weekend.

David Damerell  wrote:
> Quoting  Dave Saville <dave@invalid.invalid>:
>>Just spotted in my firewall log that painless uses IDENT auth calls
>>src="81.187.30.51:44942" dst="192.168.0.2:113" 
>>I am just dropping them.
> 
> Ident is widely misunderstood.
> 
> If A makes an SMTP (say) connection to B, and B does an ident lookup back,
> A should provide an answer _for A's benefit_. B can't infer much from the
> answer; if A is malicious, it could be a total lie. Often the answer will
> now be encrypted and meaningless to B. 
> 
> So why bother? If A has multiple users some of whom may be malicious, and
> gets a complaint from B with the results of B's ident lookup, A can use it
> to identify the culprit.
> 
> So... do drop them unless _you_ have a use for it.

Nitpicking your choice of 'drop':

And you *do* have a use for not having your connections arbitrarily
delayed, so rather than dropping (in common firewalling parlance)
either reset the connection or send back an ICMP port unreachable.

The same holds true when connecting to IRC servers, for one.

-- 
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)

Dominic Hargreaves wrote:
> 
> Nitpicking your choice of 'drop':
> 
> And you *do* have a use for not having your connections arbitrarily
> delayed, so rather than dropping (in common firewalling parlance)
> either reset the connection or send back an ICMP port unreachable.
> 
> The same holds true when connecting to IRC servers, for one.

Is this the reason why, when I try to send an email directly to the MX of 
another AAISP user (one who uses AA's relay, not a direct server), I see 
several seconds delay at two or more points in the SMTP exchange, where if I 
send an email to almost anyone else the process is more or less instantaneous? 
If I was set up to reply on port 113, would this not happen?

If so, how do I do this? I have a Zyxel router with the firewall set to pass 
everything except known nasties, and a PC with ZoneAlarm and a Mercury mail server.

On Thu, 17 Sep 2009 23:39:01 +0100, Alfred E Neuman wrote:

> Dominic Hargreaves wrote:
>> 
>> Nitpicking your choice of 'drop':
>> 
>> And you *do* have a use for not having your connections arbitrarily
>> delayed, so rather than dropping (in common firewalling parlance)
>> either reset the connection or send back an ICMP port unreachable.
>> 
>> The same holds true when connecting to IRC servers, for one.
> 
> Is this the reason why, when I try to send an email directly to the MX
> of another AAISP user (one who uses AA's relay, not a direct server), I
> see several seconds delay at two or more points in the SMTP exchange,
> where if I send an email to almost anyone else the process is more or
> less instantaneous? If I was set up to reply on port 113, would this not
> happen?
> 
> If so, how do I do this? I have a Zyxel router with the firewall set to
> pass everything except known nasties, and a PC with ZoneAlarm and a
> Mercury mail server.

You need it to *reject* traffic on port 113, rather than dropping it on 
the floor, which just forces a timeout (hence the delay). I use a 
separate firewall (I have a P660-R which doesn't have a firewall), and 
that's what I do).



-- 
Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

Bob Eager wrote:
> On Thu, 17 Sep 2009 23:39:01 +0100, Alfred E Neuman wrote:
> 
>> Is this the reason why, when I try to send an email directly to the MX
>> of another AAISP user (one who uses AA's relay, not a direct server), I
>> see several seconds delay at two or more points in the SMTP exchange,
>> where if I send an email to almost anyone else the process is more or
>> less instantaneous? If I was set up to reply on port 113, would this not
>> happen?
>>
>> If so, how do I do this? I have a Zyxel router with the firewall set to
>> pass everything except known nasties, and a PC with ZoneAlarm and a
>> Mercury mail server.
> 
> You need it to *reject* traffic on port 113, rather than dropping it on 
> the floor, which just forces a timeout (hence the delay). I use a 
> separate firewall (I have a P660-R which doesn't have a firewall), and 
> that's what I do).

I've just tried setting up a Zyxel firewall rule to reject port 113, but when I 
test port 113 with ShieldsUp the Zyxel log shows "access dropped" not rejected, 
ShieldsUp indicates "Stealth" and sending an email to myself via secondary-mx 
has the same delays as before. Is this yet another Zyxel firmware bug?

On Fri, 18 Sep 2009 11:52:39 +0100, Alfred E Neuman wrote:

> I've just tried setting up a Zyxel firewall rule to reject port 113, but
> when I test port 113 with ShieldsUp the Zyxel log shows "access dropped"
> not rejected, ShieldsUp indicates "Stealth" and sending an email to
> myself via secondary-mx has the same delays as before. Is this yet
> another Zyxel firmware bug?

I don't have a firewall in mine, but the manual includes firewall stuff 
anyway.

It doesn't indicate a way of rejecting port 113 traffic. It has 'Block' 
or 'Forward'. Naturally, 'Block' won't work as it silently discards the 
packet; you want the connection rejected. I guess you can forward it to a 
machine that doesn't have a port 113 listener, and that should work fine.



-- 
Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

Bob Eager wrote:
> On Fri, 18 Sep 2009 11:52:39 +0100, Alfred E Neuman wrote:
> 
>> I've just tried setting up a Zyxel firewall rule to reject port 113, but
>> when I test port 113 with ShieldsUp the Zyxel log shows "access dropped"
>> not rejected, ShieldsUp indicates "Stealth" and sending an email to
>> myself via secondary-mx has the same delays as before. Is this yet
>> another Zyxel firmware bug?
> 
> I don't have a firewall in mine, but the manual includes firewall stuff 
> anyway.
> 
> It doesn't indicate a way of rejecting port 113 traffic. It has 'Block' 
> or 'Forward'. Naturally, 'Block' won't work as it silently discards the 
> packet; you want the connection rejected. I guess you can forward it to a 
> machine that doesn't have a port 113 listener, and that should work fine.

Looks like the manual is out of date as usual. Mine has three options: Permit, 
Drop and Reject, though as I say, Reject seems to do Drop, which is no help.

If I set it to Permit (which was the default) then it would get dropped by 
ZoneAlarm unless an active server was running on that port.

Ah, just thought of something ... in addition to the firewall rule to reject 
the connection, I've added a virtual server NAT rule to route port 113 to my PC 
(which of course it won't do since it's blocked by the firewall), and now it 
shows up on ShieldsUp as closed. The bad news is that there are still delays in 
accessing the AA MX server, so it doesn't look like that was the problem.

If I leave in the virtual server but disable the firewall rule, ZoneAlarm logs 
the connection attempt from ShieldsUp, but there is nothing from the AA server 
when I try to send an email.

Ah well, back to the drawing board!

On Sep 17, 11:14 am, "Dave Saville" <d...@invalid.invalid> wrote:
> Just spotted in my firewall log that painless uses IDENT auth calls
>
> src="81.187.30.51:44942" dst="192.168.0.2:113"
>
> I am just dropping them. Two questions:
>
> 1) Why are the A&A email servers doing this? Google suggests it is
> very old practice.

It's the default in exim, which I've never understood.

First thing I always do with any exim install is set:

rfc1413_query_timeout = 0s

joe