Need help understanding log

[Acadia]

I purchased Firewall Pro several days ago and I must admit that I don't know why I waited so long. But while playing around with this new toy I discovered something that I don't quite understand. Under the Event Viewer > Packet Log there is a list of items that were Blocked by the Attack Detection component. What exactly am I seeing here and why? This firewall is also behind a router.

Thank you,
Acadia

[wat0114]

Hi Acadia,

could you please post some of those log entries so we can get a better idea of what's been blocked? They are most likely nothing to worry about (could even be caused by the router's traffic).

[stanny]

I got this in my log.

13:37:13 Block IN UDP 208.67.222.222 53 192.168.1.4 53497 Blocked by the Attack Detecton component 73

I wonder why and which Attack Detection rule OSS is using for this OpenDNS IP.

[Acadia]

Thanks, wat0114, I will later this evening when I get to the pc where this is happening.

Acadia

[Acadia]

Ok, here it is, thank you, Acadia.

[stanny]

Connection termination

The connection termination phase uses, at most, a four-way handshake, with each side of the connection terminating independently. When an endpoint wishes to stop its half of the connection, it transmits a FIN packet, which the other end acknowledges with an ACK. Therefore, a typical tear-down requires a pair of FIN and ACK segments from each TCP endpoint.

A connection can be "half-open", in which case one side has terminated its end, but the other has not. The side that has terminated can no longer send any data into or receive any data from the connection, but the other side can (but generally if it tries, this should result in no acknowledgment and therefore a timeout, or else result in a positive RST, and either way thereby the destruction of the half-open socket).

Source: http://en.wikipedia.org/wiki/Transmi...ntrol_Protocol

I'm wondering what the reason of blocking those two packets was where your Flags are empty.

[wat0114]

Quoted from here:

FIN - bit 111. The FIN bit indicates that the host that sent the FIN bit has no more data to send. When the other end sees the FIN bit, it will reply with a FIN/ACK. Once this is done, the host that originally sent the FIN bit can no longer send any data. However, the other end can continue to send data until it is finished, and will then send a FIN packet back, and wait for the final FIN/ACK, after which the connection is sent to a CLOSED state.

Maybe somehow the remote servers don't yet know your end has stopped sending data, so they continue sending a series of "FIN/ACK packets and Outpost perceives this as an attack?? I know there are others who understand this and can explain it better than I (I seem to remember seeing an explanation on this somewhere in this forum but can't find it). At any rate, I don't think it's antthing to worry about.

[Manny Carvalho]

Just remember logs - particularly this one - can drive you crazy and are best used for troubleshooting.

The packet log is probably the most complex and poorly understood -me included - logs in OP. In this case, OP is data rich but information poor. Largely that's due to poor documentation at what exactly is going on here. Couple that with the greater amount of information available when in log debugging and the different levels this thing is hard to understand fully without help.

Agnitum, in the help file, says that this log "Displays all the packets sent or received by the system and the reason they were allowed or blocked." While that's true what I see in that log includes:

1. The standard TCP/IP packet logs and their flags.
2. Attacked Detection blocked packets.
3. IP addresses blocked by IP Blocklist.
4. Several other protocols like ethernet, IGMP and maybe more.

Most of what is seen is the TCP handshake using the flags in to trace TCP/IP trafic. If no flag is present it means it's not TCP traffic because the flags are unique to such traffic.

The attack detection entries are in the packet log rather then the attack detection log because - and this is my opinion - because this traffic doesn't rise to the level of an attack as defined by Attack Detection. However, it is blocked traffic due to some criteria and documented in this log.

What I think happened with this entry:
13:37:13 Block IN UDP 208.67.222.222 53 192.168.1.4 53497 Blocked by the Attack Detecton component 73

was a DNS lookup was slow in returning and got blocked by Attack Detection. It wasn't an attack so it didn't show up in the Attack Detection log but since it was a packet that got blocked by AD it ended up in this log.

I'm not quite sure about your logs Acadia since its TCP traffic. But they are all inbound and I'm assuming it's something that went wrong with the TCP handshake. The FIN is a flag from the sender saying there's no more data and the ACK is the acknowledgement. The FIN-ACK should have been the graceful acknowledgement that the handshake was done and data finished. OP saw something wrong and blocked it. It would probably take a packet sniffer to really figure it out. Maybe Agnitum knows. You could ask them what this is all about.

Well, that's my story and I'm sticking to it....

[stanny]

Superb post Manny!

[Acadia]

Thanks Manny and stanny. Does Agnitum read these forums or should I actually submit a tech support request?

Acadia

[Manny Carvalho]

They do read but you get a bigger bang for your buck if you actually document it by sending a support request. I would encourage you to do so and include a request for better documentation on their part for what exactly the packet log entails.

[mepreocupo]

I found this thread when I was tearing my hair out this afternoon trying to understand the warning that popped up on my screen telling me that my Outpost Pro 7 firewall in its infinite wisdom had blocked some kind of attack from 130.85.12.2. As far as I know, that's the IP address of my university's email. I went to the Packet Log file and found all kinds of information I didn't understand. I went to the Help file and tried to find out, for example, the meaning of the various flags listed, but the Help file doesn't have ANY entry for flags. Duh....

I then tried to search this forum for "flags." After reading through this thread from a year ago, I'm wondering whether what Outpost is responding to is simply a momentary loss of Internet connectivity. For some reason that I have been unable to determine, every few minutes I lose my Internet connectivity for a few seconds. It then returns. (This has been true for years.) If my university's IMAP email program is trying to contact me at a time when the Internet connection is lost, would that make Outpost think that I'm under attack because the flags aren't as they should be? Does Outpost then make things worse by preventing my university's email program from contacting me? Is there some way I can deal with this without leaving myself open to genuine problems? I've attached a screenshot of the most recent part of my packet log in the hope that that may prove useful.

Thanks in advance for any help you can provide.