Stateful Packet Inspection logs

Im new to Look'n'Stop and just started testing the new beta 2.05 so i just have a quick question. I turned on Stateful Packet Inspection under advanced options and now im seeing in the logs a bunch of Stateful Packet Inspection rules showing up all the time now. They are being blocked from coming in with the address being 127.0.0.1 and with a source port of 80. So my question is, is this normal or not to be happening all the time? and if so is there a way to disable them from being logged?

 

Some months ago I also experienced this kind of packets.
it seemed to me that is was a real detection of bad (malicious ?) packets.
Here is the reference to my post:
http://www.wilderssecurity.com/showthread.php?t=13244;start=msg88614#msg88614

I added a rule to block specifically these packets before they were examined by the TCP SPI:
http://looknstop.soft4ever.com/Rules/LocalHost80.rie

and after that everything was Ok.

Frederic

 

Hi Frederic,

To bad i cant read french or else i would read the thread you posted on this before.

The link to the rule you posted above to block this i couldnt make out totally but i think i understand it enough. I just created a rule at the top of my filter rules to block localhost inbound source ip 127.0.0.1 and source port 80 and that seems to be doing the trick.

I have used both kerio 2.1.5 and 8signs firewalls and have never seen this happen before and they are both supposed to have stateful packet inspection. So i have to wonder then if this could be a bug or something with Look'n'stops SPI perhaps?

 

Ok, I just checked my logs again after awhile and noticed some more very strange Stateful Packet Inspection logs.

I got hit with 27 SPI logs all at the same time from ip address 64.4.199.68 , dest ports range 1409-1440, src port 80.

Then almost 2 min. later I got 75 more SPI logs all at the same time again from the same address. dest ports 1554-1697, src port 80. Now whats really strange is that 20 of these SPI logs say that they were blocked from going out? The ones showing as being blocked from going out show the src ports range of 1677-1697 and the dest port 80. Same ip address.

So right now im really baffled. Was i being attacked? Or is there something else going on here?

 

Hi tester

With the source port 80 (HTTP) and destination ports in the ephemeral range (1024-5000) would suggest late packets from a connection to a web site. The IP you provided above resolves to www.fatwallet.com Had you been to that site around the time of these log entries?

No I don't think you were being attacked or have anything to worry about. As above, just likely late packets from a connection LnS no longer considers part of a valid connection. On checking out the IP/web site I ended up with a couple of similar entries in my logs:

Details: TCP non-syn/non-ack packet on invalid connection. Packet has been dropped
Source IP address: www.fatwallet.com(64.4.199.6
Destination IP address: wrkstn10(192.168.xx.xx)
TCP Source Port: http(80)
TCP Destination Port: 1603
TCP Message Flags: 0x00000011

Details: TCP non-syn/non-ack packet on invalid connection. Packet has been dropped
Source IP address: www.fatwallet.com(64.4.199.6
Destination IP address: wrkstn10(192.168.xx.xx)
TCP Source Port: http(80)
TCP Destination Port: 1601
TCP Message Flags: 0x00000011

Regards,

CrazyM

 

Actually I just said there, that the packets were real and Look 'n' Stop discarded them correctly. For me it was a kind a spoof attack, the sender replacing its IP with 127.0.0.1. , but perhaps there is another explanation.

If it is the same case as the one I've experienced, there is no problem with Look 'n' Stop. Look 'n' Stop doesn't make up packets
Since these packets are very rare and the period you can see them is limited (in my case it happens only during few days), it is perhaps normal you didn't see them before with other firewalls. They also can discard these packets without notifying the user.

Frederic

 

Yes, this could be an explanation (when the IP is not 127.0.0.1). However, this is normally handled by the TCP SPI engine if the late packets are not coming too late.
Having a lot of simultaneous TCP connections (when using a p2p application for instance) could also cause this kind of detection on late packets (because old connections will be reused more quickly).

Frederic

 

Thank you CrazyM for explaining that so well to me. Yes i was visiting that web site. That really had me puzzled as to what was happening exactly. I thought either someone was after me probably or Look'n'stop was going crazy on me lol. Big sigh of relief now!


As to the 127.0.0.1 SPI logs its good to know at least Look'n'stop is blocking them, whether they are spoofed packets or not. My question is should i continue to log and watch them to see if they persist constantly or should i just forget about them now? I just wonder if its the same thing you had Frederic or perhaps something else. Is there anyway to know for sure if what im getting are indeed spoofed packets or something completely different? Thank you Frederic.

 

I think you can let the rule blocking them without alerting, and from time to time select the ! attribute to see if the packets are still there.

I my case, I'm really sure that the packets were coming from my cable modem, so the IP address of the sender was changed somewhere, either by a real spoof or maybe by a network routing error somewhere (I don't know if it can happen).

Frederic.

 

It looks like its calmed down now Frederic. I haven't gotten any more of those logs in awhile. I turned the logging back on for that rule awhile back just to see if it was still continuing or not. Looks a-ok now. I'll go and turn off the logging for it and just do as you said. It just had me a bit worried and puzzled all at the same time there since i am so new to Look'n'stop. Thanks again for your help.

 

To be brief most if not all probably consists with infected boxes on your own ISP, that being said the infected boxes don’t normally stay “Online” for to long as the ISP locks-up accounts of the infected machines.