SPI - unwantedly blocked outgoing traffic.

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?

 

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

 

Yeah sure, will have to enable it and test, will attach it then. Thanks.

 

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.

 

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

 

Another log here...

 

Hi,

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

 

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.

 

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.

 

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.

 

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?

 

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

 

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.

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

 

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.