Inbound policy violation and 2.4 ver. [Resolved]

Hi I finally upgraded to 2.4.17.183 from ver. 2.3 this week. I’m seeing something new in my logs and need help. Please forgive me if this has been covered. I attached a pic. and another source that is similar to the one in the pic is 10.18.41.1:bootp(67). Is this new to 2.4?

[attachment deleted by admin]

Hi, DHCP is a subset of bootp so the two go together. This is also giving you your ip on a network. What may be happening is something is sent from other computers on network which every pc sees but only the one that the info is destined for actually takes the info. If not for your pc is simply blocked. Basically this request is bouncing and you are getting the report in your firewall. Although Ewen, Kail or others may better assess this, this is my take and you are fine.

Paul

Thanks for you quick reply Shifter. I’m getting a lot of these in my logs (by a lot, I mean more than 50%) and I did not see this with ver. 2.3. My harddrive is also “ticking” slowly all the time now. Also, I have only 1 desktop hooked directly to my cable modem. No router or network yet. I should have mentioned that earlier. My logging has been and is set on low. My machine is clean because my HJT log was checked today for another unrelated problem. No malware was found. Also If you have time please briefly explain DHCP and bootp or point me to a simple explanation. I really want to learn more about firewalls so I can tighten my rules up.

Thanks again, innerpeace

Hi , you can read here…

Have you tried this…find your network connections usually in control pannel, it’ll say “view NW connections” right click and choose a repair and see if it works. Also, I would clear all logs to start over and see exactly what happens after this as well. :wink:

Paul

Hi Comicfan. Thanks for the link. dhcp looks a bit complicated to me. Everything seems to be back to normal today. Go figure! I will try the repair if it starts again. I guess it just took 3 days for my system and Comodo 2.4 to get along. Thanks again!

I’m now having this problem again. I preformed the repair and everythings ok for a while then later I still see many of the attempts again in my logs. Why would this start happening after I moved from 2.3? Comodo has also had to shut down a few times now since installing 2.4. That worries me. I really do not want to uninstall my security system just to try again with 2.4. If I have to uninstall Comodo I will go back with 2.3.

Thanks, innerpeace

Please help with my questions ???. I have uninstalled 2.4 then reinstalled 2.3 and ran it for a few days with no problems. Curiosity got the better of me and I just can’t stand having a problem that I can’t figure out. Today I reinstalled 2.4.18.184 clean and am getting the same log results. Is this normal? Should 50% of my logs show these results. I’m trying ■■■■■■■ this end to run the newest version. The ball is in your court now. innerpeace

Innerpeace,

Are we then correct in assuming that you are using Internet Connection Sharing (you said you did not have a router) and have one computer serving addresses to 1 or more other computers ?

AJB

Hi, I have only one desktop directly connected to my cable modem. I also am using the normal factory network rules and scanned for known applications and all my listed application rules have been set up by answering pop-ups. Where can I find the ICS settings? I know that dhcp is enabled if that helps.

Okay if we’re only talking about one computer, ignore the ICS comment (ICS would be applicable if you had a second computer connecting through your first computer in order to get to the internet).

DHCP being enabled is okay as this how your computer gets its IP. What you don’t want is having the DHCP server functionality enabled. Your modem is only a modem right, not a modem/router combo ? What make/model is your modem ?

Very curious that the problem only occurs with 2.4 and not 2.3. Is 10.17.5.17 your computer’s IP ? Looks as if your computer gets its address but the DHCP server continues to broadcast. Here’s another link on how DHCP works (see slide 15).

http://www.borella.net/mike/MITP432/08%20dhcp.pdf

You could just add a Network Monitor Block rule just above your existing Block & Log rule to Block (but not log) the request (Block UDP In,Source: Any, Source Port: Any, Destination: Any, Destination Port 68). But that just covers up the problem (although it keeps your log clean).

AJB

Hi Birdman, Here is my modem model. ARRIS DOCSIS 1.1 Touchstone Cable Modem HW_REV: 06. AFAIK it is only a modem. I can look under http://192.168.100.1/ and give details as to its status. I also have no literature since its from the cable company.

Very curious that the problem only occurs with 2.4 and not 2.3. Is 10.17.5.17 your computer's IP ? Looks as if your computer gets its address but the DHCP server continues to broadcast. Here's another link on how DHCP works (see slide 15).

I’m also puzzled to as to why it only appears in version 2.4. My ip starts with 24...* Also in addition to the 10.17.5.1 there is the 10.18.. number. Thanks for your help. innerpeace

Innerpeace,

Well given the destination port for the message is 68 I think we’re just dealing here with ‘noise’ from your ISP’s DHCP server. For clients that have not been assigned IP’s the DHCP server needs to communicate with them using these 255.255.255.255. Disection of the message to reveal the MAC address (if specified) might confirm this, depending on the message type. Those of us who hide behind routers never see this stuff as the router screens it for us. Perhaps one of the COMODO designers will jump in at some point and confirm whether or not there was a change that now causes CFP (2.4.x.x.) to flag unsolicited (inbound, but not in response to an outbound request) broadcast messages.

Surf safely,

AJB

While I don’t know specifically about changes in 2.4 from 2.3 that address this, I do know that there were changes starting with the 2.4 Betas, to the way that CFP monitors/shows/logs connections. For instance, it previously showed Listening Ports, now it does not, and I think there were some other material changes as well.

LM

Hi Birdman, thanks for your reply. Yes the destination ports are 67 and 68. Are saying that these could be requests (noise) from my isp to others trying to obtain their ip addresses?

Hi LM, thank you for replying. This definitely is a problem/irritation unique to version 2.4, at least on my machine. When I check the logs and right click on any log to get the options, one of the options is for “log events from” that has 4 options that are all checked. Did version 2.3 have all 4 options too I wonder? I just found the settings this week looking for a solution. Here is a sample of my logs. My only complaints are that this didn’t happen in version 2.3 and it makes it difficult when looking at the logs for real attacks.

Date/Time :2007-02-19 18:43:21
Severity :Medium
Reporter :Network Monitor
Description: Inbound Policy Violation (Access Denied, IP = 10.18.48.1, Port = dhcp(68))
Protocol: UDP Incoming
Source: 10.18.48.1:bootp(67)
Destination: 255.255.255.255:dhcp(68)
Reason: Network Control Rule ID = 5

Date/Time :2007-02-19 18:43:21
Severity :Medium
Reporter :Network Monitor
Description: Inbound Policy Violation (Access Denied, IP = 10.17.5.1, Port = dhcp(68))
Protocol: UDP Incoming
Source: 10.17.5.1:bootp(67)
Destination: 255.255.255.255:dhcp(68)
Reason: Network Control Rule ID = 5

Date/Time :2007-02-19 18:43:16
Severity :Medium
Reporter :Network Monitor
Description: Inbound Policy Violation (Access Denied, IP = 10.17.5.1, Port = dhcp(68))
Protocol: UDP Incoming
Source: 10.17.5.1:bootp(67)
Destination: 255.255.255.255:dhcp(68)
Reason: Network Control Rule ID = 5

Date/Time :2007-02-19 18:43:16
Severity :Medium
Reporter :Network Monitor
Description: Inbound Policy Violation (Access Denied, IP = 10.18.48.1, Port = dhcp(68))
Protocol: UDP Incoming
Source: 10.18.48.1:bootp(67)
Destination: 255.255.255.255:dhcp(68)
Reason: Network Control Rule ID = 5

What’s odd to me is that the 10.x.x.x IP addresses are reserved addresses; they’re used for internal networks. Thus if your IP is 24.x.x.x, and your modem is 192.x.x.x, where is it coming from?

You can verify (if you haven’t already) your IP info by going to Start/Run, type “cmd” then at the DOS prompt, type “ipconfig /all”. This will show your computer’s IP, your DNS Server, Default Gateway, etc. If you see a match there, then that will help clear things up.

I did some research on your cable modem, and while I cannot quantify the following, here’s what it looks like to me (someone more knowledgeable would have to confirm). It seems like when you’re using cable internet, it’s almost like your modem is networked with the server downstream (called a “cable modem termination system” or CMTS), which your cable modem communicates with, both upstream & downstream (as does every other subscriber’s modem). If indeed this does create a sort of “network” it might be possible that an “internal” IP address like the 10.x.x.x is used by the CMTS, and you’re getting backwash from that (since your modem won’t stop it, it comes thru to your computer, where the firewall stops it).

Whaddayou think, Birdman? Are you familiar with cable connections like this?

LM

LM, no I can’t say that I’m familiar with those connections. I do think the “ipconfig/all” check is a good idea ( 10.x.x.x = DHCP server perhaps ?)

Innerpeace, the traffic you’re blocking could be other IP requests being served. There are also other things going on like IP lease renewals.

Also you can add another Block Rule to keep your logs clean (see previous post). After thinking about it I don’t think you’ll miss much by doing this. I suspect several of us are doing this (block w/o log) already for outbound attempts that we don’t want to see logged (ports 123 & 1900 for example). Just make sure the rule is low enough in the list that you don’t block the responses to your DHCP requests.

AJB

Hi LM, here is my ipconfig info. It could be a problem with my isp, but that wouldn’t explain why it didn’t show with ver. 2.3

[attachment deleted by admin]

innerpeace,

Two things I would suggest at this point:

  1. Contact your ISP, and see if they have an explanation for the 10.x.x.x IP addresses showing up in your logs.

  2. File a ticket with Comodo Support, and see if they have an explanation for the 10.x.x.x IP address, and why it hasn’t shown up in v 2.3 (it is always possible this traffic is a new thing, too).

By the ipconfig info, I would not expect to see that IP address showing up. That’s weird. I’d expect to see traffic from the 65.x.x.x and 67.x.x.x, given that’s from your ISP, for updating/maintaining your IP address.

On the plus side, you know that CFP is blocking the traffic; your computer is secure in the event that it is something shady. If no answers/solutions are forthcoming, you can certainly do as Birdman suggested, and create and Block and don’t log rule in the Network Monitor, specific to that IP address, so that it’s not cluttering your logs. I’d wait until I checked with ISP & Comodo Support, before doing so (simply because if you block & don’t log, you don’t have an easy reference for info they may need).

LM

Hi LM, For now I made a rule as suggested by Birdman. It is right above the Comodo default block rule.

BLOCK UDP IN FROM IP [Any] TO IP [Any] WHERE SOURCE PORT IS [Any] AND DESTINATION PORT IS IN [67,68,]

Does this look right? Your right about the support ticket, it would be a good idea. I just thought of something, I am using Avast AV and only use the Standard and Web Shields. I know that there have been problems with Avast. I guess the Web Shield is a HTML Filter or a proxy of sorts. I wonder if the compatibility fix in 2.4 for Avast is causing the logged entries. I have been using Avast since first installing Comodo 2.3.

Thank you for your time and help, innerpeace :slight_smile:

I wouldn’t block the ports, innerpeace, as you need those for your DHCP lease renewal, and thus IP address.

My approach would be blocking the IP addresses.

The rule would look like:

Block (no logging) UDP In, From IP Range 10.17.5.1 - 10.18.48.1 (or whatever range you’ve seen so far; I’d pick the outermost), to IP Any, Source/Destination Port Any.

Placement above the bottom block rule is fine, with the following in mind: There cannot be a rule prior to that in placement, which would allow UDP In in a general sense. There shouldn’t be anyway, but for example if for some reason you had a rule to Allow UDP In from Any/Any/Any/Any, then it would fire first, and allow the 10.x.x.x traffic. I don’t know why anyone would want to add a rule like that, but sometimes stuff gets inadvertently messed up… :wink: Thus, I have to bring it up.

LM