[CLUE-Talk] RFI packet log deny message

[Dave Anselmi]

B O'Fallon wrote:

> Hello,
>
> I was looking at my root mail tonight and noticed the following:
>
>      Oct 23 21:56:11 mudhen kernel: Packet log: input DENY eth0
>      PROTO=6
>      152.2.210.121:20 10.0.0.3:32897 L=60 S=0x00 I=21355 F=0x4000
>      T=51 SYN
>      (#59)
>
> 10.0.0.3 is address assigned to my ethernet card by the NAT feature of
> my Cisco 675.
>
> Could someone explain what this is? Is someone at unc probing the ftp
> port of the ipaddress for my cisco and it is getting passed through to
> the firewall I am running on 10.0.0.3?

Protocol 6 is TCP, no surprise.  The source port, 20, is ftp data.  So an
ftp server at UNC is trying to send you something.  Apparently your
Cisco's DNAT lets this sort of thing through (perhaps that's necessary -
the 675 isn't as smart as netfilter).  I'm not sure that you need this, I
use ftp (client) through my 678 without doing DNAT.  What servers are you
running that require you to do DNAT?

The ftp protocol allows a control connection from one machine to tell the
ftp server to open a data connection to another machine.  I don't remember
the details, but could look them up.  By any chance was any computer on
your network ftping to metalab?  If so, perhaps your DNAT is interferring
and sending the data connection to the wrong machine.  Also, it is
possible that there are aliases for metalab and you were ftping to one of
those (didn't sunsite become ibiblio, or something like that?)  Did you
have any ftp or http errors around this time?

This is not a probe of ftp on your end - the source port is ftp, not the
destination port.  Your 675 doesn't run ftp anyway.

What was listening to port 32897 when these connections came in?  It seems
unlikely that port would get picked at random.  Perhaps you have DNAT
sending something there, more likely something went out from there and had
a NAT entry on the 675.  Although the NAT that your 675 provides gives you
some protection from probing, I suspect it is possible to trace back an
existing connection and do a limited amount of probing.  That would be
pretty hardcore, I think.

A sniffer log might show some interesting traffic, or you can look at
netstat et. al. if you can reliably reproduce this traffic.  If not,
probably nothing to worry about.

Dave