Re: FTP problems

This is a discussion on Re: FTP problems within the IPFilter forums, part of the System Security and Security Related category; Hi, Paul Mackey wrote: > Hi, > > I have a box with IP Filter (v3.4.31, Solaris 8, ...


Go Back   Usenet Forums > System Security and Security Related > IPFilter

FAQ Members List Calendar Search Today's Posts Mark Forums Read
  #1 (permalink)  
Old 09-25-2003
Slawek
 
Posts: n/a
Default Re: FTP problems

Hi,



Paul Mackey wrote:

> Hi,
>
> I have a box with IP Filter (v3.4.31, Solaris 8, Sun 420) running along
> with an FTP proxy (jftpgw).
>
> client -> idmz: | FW | :edmz -> FTP server
>

[...]
> Sep 25 15:41:08 picsbh6 ipmon[364]: [ID 702911 local0.warning]
> 15:41:07.576601 qfe5 @475:2 b 207.25.253.21,20 -> EDMZ-IP,38578 PR tcp
> len 20 52 -AR 771141879 715035279 32148 IN
>
> ipfstat -slv shows still in state:
>
> 207.25.253.21 -> EDMZ-IP ttl 168692 pass 0x500a pr 6 state 4/4
> pkts 74009 bytes 57939348 20 -> 38578 2df6b0f6:2aa02b5b
> 32148<<2:24624<<0
> pass in quick keep state IPv4
> pkt_flags & 2(b2) = b, pkt_options & ffffffff = 0
> pkt_security & ffff = 0, pkt_auth & ffff = 0
> interfaces: in qfe5,- out -,qfe5



We can see that the packet blocked has sequence number 715035279.
Ipfilter has already accepted packet with sequence number 715139931
(0x2aa02b5b)

It means that ipfilter accepted the packet which is 104652 bytes
ahead of some packet which got lost (and is just being resent).

We can also see that in this tcp connection we have window of
32148<<2, so it is perfectly allowed to have pakcets at most
128592 bytes earlier or after last accepted packet.

So far so good (there is no problem in packets' flow).



Now let's see why ipfilter blocks this packet....

In ipfilter's source. In file ip_state.c we can find:

--- start --
#define SEQ_GE(a,b) ((int)((a) - (b)) >= 0)
#define SEQ_GT(a,b) ((int)((a) - (b)) > 0)
if ((SEQ_GE(fdata->td_maxend, end)) &&
(SEQ_GE(seq, fdata->td_end - maxwin)) &&
/* XXX what about big packets */
#define MAXACKWINDOW 66000
(ackskew >= -MAXACKWINDOW) &&
(ackskew <= MAXACKWINDOW)) {
-- end --

Ok! Here it is!

We've got hard coded maximum allowed skew for flowing packets
instead of reading that from the packets themselves.

I find it really funny, that the code is commented as it may have
a problem with that.


You may want to change this hardcoded value to something bigger
or read it from variable "win" (which has window's size at the moment).


Note that I'm not involved in ipfilter coding and I cannot guarantee
if proposed fix would help you or screw up your system ;)



Hope it helps anyway,
Slawek Piotrowski


Reply With Quote
Reply
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are Off
[IMG] code is Off
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On



All times are GMT +1. The time now is 04:21 AM.


Powered by vBulletin® Version 3.7.3
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO 3.0.0