Was I attacked? [Resolved]

Yesterday while using DC++, I received a two warnings about Denial of Service attack. Here is one log entry:

Date/Time :2007-01-07 01:01:10
Severity :High
Reporter :Network Monitor
Description: DDOS Attack (UDP Flood)
Duration: 23 seconds # of packets: 229 # of attackers: 278
Attacker(s): 83.227.108.205, 85.157.12.115, (… 19 more different IP addresses…)
The firewall has switched to EMERGENCY mode

This happened before I opened a dedicated port for DC++ in CPF (it was my first use of DC++ after instaling CPF). After that, I didn’t receive additional warnings, and continued to use DC++ without any trouble.

Was I really attacked, or was it just a normal p2p traffic, missinterpreted by CPF. If so, many thanks to Comodo for protecting me (S).

Note that I am behind a NAT router/firewall…

Although an DDoS attack of some sort cannot be ruled out, it is more likely to be the P2P network that is generating this traffic. These incoming UDPs are likely to be other DC++ users trying to either identify what you are or just cataloging what you are sharing.

Thank you for your answer!

Now, I have another question on the same subject. I am sorry to bother you with this, but I would like to learn the difference between the true attacks and the ordinary internet traffic…

During the period of 20 minutes, CPF logged more than 50 log entries. They are all the same (except for time, offcorse ;D):

Date/Time :2007-01-09 00:12:27
Severity :Medium
Reporter :Network Monitor
Description:Inbound Policy Violation (Access Denied, ICMP = PORT UNREACHABLE)
Protocol:ICMP Incoming
Source: 80.69.95.xxx
Destination: 192.168.2.101
Message: PORT UNREACHABLE
Reason: Network Control Rule ID = 9

During this time, the only application with access to the internet were Firefox and Thunderbird. Can someone please shed some light on this matter?

Have you done a search on the IP address from which these ICMP IN attempts were made? You can use a site like DNSStuff, to find out who the IP is.

Since it’s an inbound request, all from the same IP (you said the only thing that varied was the time…), it should be pretty easy. That might help shed some light on it…

LM

Yes, I’ve checked the IP, it belongs to a www.transip.nl. It’s a web hosting site (at least I think so) in the Nederlands.

And that’s not a site/IP you’re familiar with, I guess? You don’t use them for anything, and it’s not related to a torrent? (I know you said you only had FF and TB open at the time.) In which case it would look like it’s an unsolicited communication…

You can add a Network rule, if you want, to specifically Block IP In from that IP address (or range of IPs, if you want to block them all…). In that rule, you can either block the ICMP protocol, or all IP protocol. If I knew that I had not in some way initiated the connection, I would probably block All IP protocols (ie, “Any”).

Thus, your rule would be added to the Network Monitor above the bottom Block Rule, something like this:

Action = Block & Log
Protocol = IP
Direction = In
Source IP = The IP you want to block
Destination IP = Any
Details = Where IPProto is Any

If it persists, and you know that you are not initiating the contact, you can use the information from your CPF logs to contact your ISP, so that they can investigate and take appropriate action.

Hope that helps,

LM

You’re right, I’ve never contacted them, never heard of them, I don’t even speak Dutch ;D.
I will block this site, and keep monitoring the logs. And if I see this happen again, I will report them.

Thank you very much for the advice!

Chances are, the IP address is being used as a sort of proxy for the originator of the contact, probably through the use of bots and whatnot. Technojargon stuff… :wink:

I say that to say, if you end up with a recurrent event, and wish to report to your ISP, I would not say that www.transip.nl was trying to hack you; I would report it that you are having an unexplained, unsolicited contact from the offending IP address, along with date/time info, etc.

Your ISP has an obligation to follow up on it, and should have better tools at their disposal for tracking down the source.

LM

It is very likely that it came from a proxy, but we will probably never know.

Hm, I was thinking about the rule you’ve posted earlier… isn’t this kind of traffic already blocked by the default cpf Network rules?

And I can’t figure out how did these ICMP traffic got past my router? ???

Yes, it is. I give you a gold star for noticing… ;D (:CLP)

Here’s the thought process:

  1. It is currently blocked, because it’s not explicitly allowed (ie, ICMP Port Unreachable is not allowed by the default rules), and the bottom Block and Log rule stops it.
  2. CPF’s rules filter from the top down, until the connection is either explicitly allowed or implicitly/explicitly denied.
  3. If you left it as it is, and the “person” on the other end changed the IP protocol, it’s possible (although not necessarily probable) that the connection might be allowed before it hits the bottom block rule.
  4. By creating an explicit Block rule, rather than an implicit one, and moving it closer to the top of the hierarchy of Network Rules (ie, closer to Rule ID 0 ), you have a better chance of making sure it doesn’t get thru by accident…
  5. By having a separate Block & Log rule for the IP or IP range, you have a separate log entry; it may be easier to track that way.

As far as how it got past your router, well you’d have to access your router configuration and see what the deal is there. My guess is that ICMP is allowed for Pings, and there are probably some settings to tighten that aspect of it up.

LM

Thanks! :■■■■

Here's the thought process:
  1. It is currently blocked, because it’s not explicitly allowed (ie, ICMP Port Unreachable is not allowed by the default rules), and the bottom Block and Log rule stops it.
  2. CPF’s rules filter from the top down, until the connection is either explicitly allowed or implicitly/explicitly denied.
  3. If you left it as it is, and the “person” on the other end changed the IP protocol, it’s possible (although not necessarily probable) that the connection might be allowed before it hits the bottom block rule.
  4. By creating an explicit Block rule, rather than an implicit one, and moving it closer to the top of the hierarchy of Network Rules (ie, closer to Rule ID 0 ), you have a better chance of making sure it doesn’t get thru by accident…
  5. By having a separate Block & Log rule for the IP or IP range, you have a separate log entry; it may be easier to track that way.

Thank you for explaining.
As far as how it got past your router, well you'd have to access your router configuration and see what the deal is there. My guess is that ICMP is allowed for Pings, and there are probably some settings to tighten that aspect of it up.
I will check it. The firewall is alredy set on High, but obviously needs some fine tuning...

Thanks again, you’ve been very helpfull!

No problem.

If you consider this to be fixed, you can Edit the Subject line of your first post in this topic (icon on the lower right, by your IP address), and add “[Resolved]” for other users’ benefit.

If you want to wait a few days, to see what happens with the new Network Rule, and get your router figured out (someone here may be able to provide some input on that as well, even though it’s not a Comodo thing…), or for some more follow up on this incident, that’s fine as well.

We’re glad to help.

LM

I think we can consider this case closed.
(V)

I will lock this topic.