Troy:
Hello! I agree with Ray: my advice on the fwlog processor
is incorrect. Okay, misleading. :) The parser on the processor is
very much like how ipchains works: it checks the packet against
a chain of rules, and the first one that matches is applied. Your
ident packet log wasn't recognized by a more specific rule, and so
it hit the "default" rule for TCP packets with the SYN flag set.
I'll add a more specific rule for TCP-113 that should be more
helpful.
The new advice will read a lot like Ray's: I've found it's
best to *not* block incoming ident queries. Rather, let them thru
your firewall where they'll hit your system that has no identd
service running. Keep in mind that a "hole" in your firewall is *not*
a security problem if there's no service listening on the port that
the packet was destined for.
Sorry for the confusion!
-Scott
PS: FWIW, the echowall firewall package has an ALLOW rule for
all incoming TCP-113.
> Well ... assuming you are correct that this DENY is associated with the ftp
> attempt ... your ftp server, or some related application (like tcp wrappers)
> on the system it is running on (192.139.75.6), is sending an ident query to
> the client (192.139.75.156 in the log entry you posted) you are trying to
> connect from. That query is blocked by the firewall with a DENY. Eventually
> (30 seconds, as you report it), the ftp server (or the related app) gets
> tired of waiting for a reply, times out the ident request, and lets you
> connect anyway.
>
> Since both source and destination addresses are on the same /24 network, I'm
> a bit uncertain about what the router is routing. So I don't know if the
> ident request is being misrouted to the LEAF/DachStein router or if your
> address space is being subnetted in a fashion that calls for this routing.
> For now, I'll assume the second -- that the routing is OK and the only
> problem is with the router not passing the packet on.
>
> Even so, since you use Seawall and I don't, I'm going to have to leave it to
> someone who does use Seawall to give you the specific fix. The rest of these
> comments pertain to ipchains generically.
>
> In general terms, the most likely solution is to add a rule that ACCEPTs
> traffic to port 113 from the internal side (or at least from the ftp host),
> and *perhaps* a rule that ACCEPTs responses from port 113 to the ftp server
> (whether you need this or not depends on what the rest of your ruleset is).
>
> Or you could replace the rule that DENYs the port-113 query with one that
> REJECTs it. This should cause the ftp server to know right away that the
> query is unsuccessful, instead of having to wait for it to timeout; then,
> since it is willing to connect without an ident response, it should connect
> more quickly. (But the REJECT rule might not work; firewall REJECTs are
> different from tcp-stack REJECTs, and not all receiving hosts recognize them
> correctly. If this be true in your circumstances, I don't believe there is a
> workaround available.)
>
> Or you could modify the ftp host so it does not generate ident queries to
> authenticate connections. Since I know nothing about this host -- like what
> OS is uses, what ftp server package, and what if any intermediate security
> wrapper -- I don't know if this option is even feasible, let alone the
> details of how to do it.
>
> BTW, I think the Echogent suggestion that " ... it's likely someone trying
> to take advantage of your system in some manner" is simply wrong (sorry,
> Scott). It doesn't apply to your situation in any case (the ident request is
> coming *from* your LAN, though that is not apparent from the packet log
> viewed by itself, without your clarifying comments). Even if the DENY'd
> packet were coming from outside, ident requests are common enough that the
> interpretation is implausible even in that case.
>
> At 10:22 AM 11/28/01 -0600, Troy Aden wrote:
> > When I attempt to ftp our server (192.139.75.6) it was taking up to
> >30 sec to connect. (It should take 2 sec) I turned on logging and this is
> >the output.
> >
> >Nov 27 22:12:12 firewall kernel: Packet log: remote DENY eth0 PROTO=6
> >192.139.75.6:1083 192.139.75.156:113 L=60 S=0x00 I=19689 F=0x4000 T=63 SYN
> >(#10)
> >
> > I went to http://www.echogent.com/cgi-bin/fwlog.pl
> ><http://www.echogent.com/cgi-bin/fwlog.pl> and this is what it told me.
> >A TCP packet to this port (113) is associated with the ident service. If
> >you're running this service on your firewall or on your LAN, with the
> >intention of offering external access to it, then your firewall may be
> >mis-configured. If you're *not* running this service, and have no idea what
> >it is, it's likely someone trying to take advantage of your system in some
> >manner. You may want to investigate 192.139.75.6 further and see if there's
> >an Administrative Contact there whom you could email this packet log to.
> > I am running Dachstein rc2. with Seawall 4.1. I have ftp_masq
> >enabled. Anyone have any ideas as to what is happening here?
_______________________________________________
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
