No, I don’t have any idea.
I have SPI (Stateful Packet Inspection) enabled, and some option called DOS protection or something.
Still, I can’t be sure it was a DOS-attack, but it looks very suspicious with 2000+ blocked intrusions from a single IP.
No, I don’t use it. And shouldn’t PeerGuardian use port 80 or something for updating?
First up, remember that CFP isn’t showing you the entire log. It’s giving you a representation of the log, with duplicates and near duplicates removed. If you’re seeing 2k entries displayed, you’ve probably got 5x times that in the raw log.
And, second, UDP is very easy to spoof. The actual sending IP can be just about anything. There’s no handshake like there is in TCP. Not that TCP can’t be spoofed, but it is a whole lot harder.
I’ll presume that you’re not using the factory defaults for router passwords, per topic elsewhere.
The suggestion to turn off UPnP is a good one. I don’t know if a browser reflection attack on UPnP is possible, but I wouldn’t discount the possibility.
Have you taken any packet captures with Wireshark or some other network monitor?
Hey, I turned off UPnP at the router, shortly after firewall alert poped up, Windows operating system was trying to connect, I didn’t allow it. I’ll try out wireshark now and get back to you. Thanks for the help
I’ve gotten alot of blocked Icmp entries in log but thats just my router pinging me. Source port (type 8 ) > destination port (code 0) . Thats just cause I left the default global setting for now. I don’t have anyone on the LAN . When I did, I never shared anything with my brother. I’m behind NAT/router. I swear he caused me to be Dos’d but that was awhile back. Your ICMP code is different tho.
Your router is pinging you? A ping (ICMP 8.0, as you show) from a router is manual operation, and not something a router does on its own. A router uses arp, not ping, to find things. This doesn’t sound right, or good, or both.
you have an application that connects/connected with the host on port 23400, you application crashed and the system doesn’t know where to leave the packets (seen this before, also with Kerio Firewall).
This is not the “normal ping” icmp echo/reply but a message telling you pc you are trying to connect to a port that is unreachable (icmp 3/3) or a host 3/1 (the top message). So you have outgoing traffic to a system that’s not listening on that port then it should send you this message telling you it is not available.
So it’s nothing to worry about, if you don’t like this to mess up your logging make a global deny rule without logging.
Codes
0 Net Unreachable [RFC792]
1 Host Unreachable [RFC792]
2 Protocol Unreachable [RFC792]
3 Port Unreachable [RFC792]
4 Fragmentation Needed and Don't [RFC792]
Fragment was Set [RFC792]
5 Source Route Failed [RFC792]
6 Destination Network Unknown [RFC1122]
7 Destination Host Unknown [RFC1122]
8 Source Host Isolated [RFC1122]
9 Communication with Destination [RFC1122]
Network is Administratively Prohibited
10 Communication with Destination Host is [RFC1122]
Administratively Prohibited
11 Destination Network Unreachable for Type [RFC1122]
of Service
12 Destination Host Unreachable for Type of [RFC1122]
Service
13 Communication Administratively Prohibited [RFC1812]
14 Host Precedence Violation [RFC1812]
15 Precedence cutoff in effect [RFC1812]
So it's nothing to worry about, if you don't like this to mess up your logging make a global deny rule without logging.
ICMP 3.1 and 3.3 are the more common error conditions that get reported, and blocking those can make surfing slow down to a crawl while fetches go thru a packet timeout. I’ve found it to usually be better to make Global Rules to accept ICMP 3.1 and 3.3 so the applications get the “sorry, no one home right now” instead of waiting.
Ah I made a mistake. Type 8 from the router is ‘Echo’ and the host code 0 would be ‘net unreachable’ ? Is that right ? If left that way it would slow down browsing ?
Nope, you had it right. CFP logging shows ICMP information a little differently.
ICMP packets are a type, and a code within that type. A type 8 (an “echo request”, better known as a ping), does not have any codes or subtypes. So a zero is used as a placeholder. So you get an ICMP 8.0.
CFP logging puts the type in the source port, and the subtype code into the destination port.
Note that the zero code for the ICMP subtype does not mean “any” or “none”. For example, ICMP 3.0 has a very special meaning, as does 5.0. It’s the case for ICMP 8, that the zero is used as a placeholder. It’s just the way things got defined way back when.
I don’t think that’s the case, as I was only browsing. If this was the reason for why, the destination port should’ve been 80 or 443.
Also, I’ve never ever seen more blocked intrusions than about 10 in one day or something.
But I believe a port scan would’ve had one blocked entry for each port, and not only port 1031?
It could be sending different probes to the same port overtime to “detect” the os version and such.
Or the exploit could take a sequence of packets for the “attack” to be successful.
that way you are seeing a lot of log entries from the same server, however keeping the source port the same is suspicious, i would suspect a incrementing source port. A tcpdump could be very interesting to investigate.
as for option 3 i didn’t suggest a port scan, a increased scan specific for port 1031 vulnerabilities. (:WIN)
Thankyou