SPI - unwantedly blocked outgoing traffic.

Discussion in 'LnS English Forum' started by doktornotor, Apr 24, 2010.

Thread Status:
Not open for further replies.
  1. doktornotor

    doktornotor Registered Member

    Joined:
    Jul 19, 2008
    Posts:
    2,047
    This is caused by going to Avast Free GUI where it attempts to download the advertising banner. Well, I really don't want this blocked and logged, it's perfectly expected for local outgoing traffic, why's SPI hitting this and how to disable such behaviour? o_O
     

    Attached Files:

    • SPI.PNG
      SPI.PNG
      File size:
      11.8 KB
      Views:
      336
  2. Frederic

    Frederic LnS Developer

    Joined:
    Jan 9, 2003
    Posts:
    4,354
    Location:
    France
    Is it possible to have a full raw log of such a connection ? (the raw log is required to get the TCP flags)
    This is the only way to know why this kind of packet is considered as not belonging to an allowed connection.

    Thanks,

    Frederic
     
  3. doktornotor

    doktornotor Registered Member

    Joined:
    Jul 19, 2008
    Posts:
    2,047
    Yeah sure, will have to enable it and test, will attach it then. Thanks.
     
  4. doktornotor

    doktornotor Registered Member

    Joined:
    Jul 19, 2008
    Posts:
    2,047
    The log attached... (at least I hope that's what you want). Also, took me a while to find the location, the show logs button doesn't seem to work when running LnS under LUA as a service.
     

    Attached Files:

  5. Frederic

    Frederic LnS Developer

    Joined:
    Jan 9, 2003
    Posts:
    4,354
    Location:
    France
    I've examined the log but it contains only the SPI alerts.
    What I would need is the full sequence of packets leading to one of these SPI alerts.
    To do that, you need to enable the Log attribute for the "TCP : Authorize most common Internet services" rule.
    To limit the log size and number of packets, do that only when there is no other internet traffic (I mean, no browser open, no email client sending pop requests at the same time...).

    Thanks,

    Frederic
     
  6. doktornotor

    doktornotor Registered Member

    Joined:
    Jul 19, 2008
    Posts:
    2,047
    Another log here...
     

    Attached Files:

  7. Phant0m

    Phant0m Registered Member

    Joined:
    Jun 7, 2003
    Posts:
    3,684
    Location:
    Canada
    Hi,

    The raw log file has lines missing, ... and not enough lines. I wouldn’t mind seeing the entire raw log file for this...
     
  8. doktornotor

    doktornotor Registered Member

    Joined:
    Jul 19, 2008
    Posts:
    2,047
    Shrug; folks, forget about this perhaps. The log has as many lines relevant as LnS managed to produce. I enabled logging for the allowed TCP stuff, went to Avast, it started spewing this SPI blocked packets, then it stopped since the banner was already downloaded or what. Reproducing it again is possible only after a couple of hours since the banner is probably cached somewhere and downloaded just every once a while.

    The only thing I deleted there was irrelevant local LAN traffic. So, I don't have any more "entire" log file available and I can't produce one. If I leave it logging longer, the only thing you'll get in addition will be tons of irrelevant noise starting w/ LAN file sharing, including NTP traffic, iSCSI traffic etc. etc. etc.

    If you want to try to reproduce this behaviour, then enable SPI, install Avast Free, go to the summary page where it displays the banner and see if you get anything logged or not. Sorry, but I don't see what more information I could provide here.

    EDIT: And to further clarify where the bug lies - see, the outbound TCP traffic is clearly allowed since it wasn't blocked by any of the internet filtering rules in my setup, nor by the application rules. So, it's none of SPI's business to mess with that. It should check for established/related inbound traffic and allow that one as required, not block allowed outgoing traffic.

    Thanks for help anyway.
     
    Last edited: Apr 26, 2010
  9. Phant0m

    Phant0m Registered Member

    Joined:
    Jun 7, 2003
    Posts:
    3,684
    Location:
    Canada
    If you look at the stateful alert entries, the number at the very end of the line represents TCP flags used, the number 17 means connection closing. All the SPF alerts entries shows either source-port 4797 or 4798, and there is no other entries in that log with those two source ports showing the connection being performed using those two source ports. Since the oldest line is the topmost line, and the SPF alerts are at the very top and using the two source ports, the performing connection entries would have to be before that even.
     
  10. Phant0m

    Phant0m Registered Member

    Joined:
    Jun 7, 2003
    Posts:
    3,684
    Location:
    Canada
    I did as you had suggested; downloaded Avast! and installed and tested
    For me.., she re-connects every-time to the banner server when visiting the Avast! GUI, but cleaning your browser caches should also ensure things.

    Anyways..., I tried several times and still not been able to reproduce your experiences. :'(
     
  11. doktornotor

    doktornotor Registered Member

    Joined:
    Jul 19, 2008
    Posts:
    2,047
    Well... no idea really. Would anti-flood cause the missing parts of the log? But once again - why's SPI even involved here? See, this is basically what I'd expect (in iptables syntax):

    Code:
    iptables -A INPUT -p tcp -m state --state ESTABLISHED,RELATED -j ACCEPT
    iptables -A OUTPUT -p tcp -s $myip --sport xxxx:yyyy -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
    
    but that's apparently not how SPI in LnS works, it's applied as an "after-thought" in addition to all the internet filtering rules. What I definitely don't want though is SPI interfering w/ allowed outgoing traffic, I really don't understand what's it trying to inspect there. Perhaps you could clarify what's the SPI intended to do in LnS?
     
  12. Phant0m

    Phant0m Registered Member

    Joined:
    Jun 7, 2003
    Posts:
    3,684
    Location:
    Canada
    When dealing with SPF capable firewalls, these SPF capable firewalls keeps track of the creation and life of a connection and using timeouts for different connection states. Basically gives an time limit on what comes, and the manner which it does ... in through the door and out before she closes the door. Different firewall vendors can use different timeout values in their SPF implementation, but they usually offers controls of tweaking the different timeouts. It’s best to specifically ask for the different timeouts, and the details to exactly what each timeout applies too.

    Look ‘n’ Stop has configurable timeouts, but I’ll give you the one that I feel is specific to your problem, with an correction, little bit more of an extended period;


    Windows Registry Editor Version 5.00

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\lnsfw]
    "TCPSPITimeoutReuseClosing"=dword:0001d4c0
     
  13. doktornotor

    doktornotor Registered Member

    Joined:
    Jul 19, 2008
    Posts:
    2,047
    Well, I probably didn't ask very well... I understand what's SPI expected to do, however LnS is somewhat special in this department (tried to explain on the iptables example). Whatever, the above settings seem to work, so I guess issue solved here. Thanks again. :thumb:

    (BTW, the DWORD value is in miliseconds? I.e., 120s in the above example?)
     
  14. Phant0m

    Phant0m Registered Member

    Joined:
    Jun 7, 2003
    Posts:
    3,684
    Location:
    Canada
    Correct! the timeouts are in milliseconds, 120000, 2 minutes with that tweak you had just applied. The hard coded timeout for TCPSPITimeoutReuseClosing is 60 seconds I believe. You could probably fiddle with that tweak timeout I had giving and decrease it some more.
     
    Last edited: Apr 26, 2010
Thread Status:
Not open for further replies.