My PC is the only computer direct connected to a Cable-Modem Motorola Surfboard SBV5120 (ADSL-PPPoA), without router. Details at my sig.
When I boot my PC I have seen too many incoming connections from 10.XXX.XXX.XXX range to 255.255.255.255.
I know… this is only “garbage” from my ISP (or should be…) but I want to block them and CIS MUST block them. And here it goes:
Created GLOBAL RULES for blocking those unwanted connections (tried more than one, for blocking incoming from 10.xxx.xxx.xxx, and for blocking incoming TO 255.255.255.255):
8- With these rules and conditions, everytime I boot my PC the firewall accept incoming connections to 255.255.255.255, from 10.XXX.XXX.XXX range. As you can see at the rules pic’s, I have created both rules for (a) blocking incoming from 10.XXX.XXX.XXX range AND (b) to block incoming connections TO 255.255.255.255 BUT THESE RULES DOESN’T WORK as they should until some manual intervention. Here are the log’s for CIS and PeerBlock that I get right after boot:
The ONLY way to start blocking these unwanted, are doing this: set the Firewall Security Level to BLOCK ALL MODE for at least 3 minutes, and then go back to CUSTOM POLICY MODE. After this, CIS obeys the rules, PeerBlock log is clean, and everything else works very well. If I don’t do this procedure, CIS doesn’t block / doesn’t obey the rules!
Well for the DHCP request’s you are seeing, that’s because you are on a Cable network that uses a 10.x.y.z network probably with a /8 or 255.0.0.0 subnet. You will see all the broadcast requests for all hosts connected to the same LAN switch from your provider, first of all there is no need to see these, except for your own DHCP request at should still be allowed in/out, otherwise your DHCP renew request will fail and you internet connection will “drop”.
10.x.y.z udp 67 → 255.255.255.255 udp 68
I would create a restrictive rule like this on global rules:
Block
In
UDP
Source = netmask 10.0.0.0 / 255.0.0.0
Source Port = 67
Destination = 255.255.255.255
Destination Port = 68
It could be that peerblock is interfering the firewall process, maybe you can try this with peerblock uninstalled and see if that makes any difference.
Thank’s for those explanations, but I have some knowledge about how DHCP works (I’m NOT an expert like you) and I’m taking care to don’t block outgoing to broadcast (svchost and global).
I did uninstall PB (“new” PeerGuardian) and created that blocking rule you suggested (very similar to those I had), re-started and… still no-go.
The same situation: CIS only blocks AFTER setting “Block All” for 3 minutes and then return to normal.
Weird… and annoying. Besides this, CIS IS WORKING VERY WELL.
This is happening for a long time and was posted before. I remember when CIS was in 3.0 series this wasn’t happening in all start-up’s - sometimes, on it’s own, CIS 3.0 did block.
!ot! I know I will say something not true, but it feels like when DHCP works to get an IP (at boot time) it leaves one door open, like a connection or a channel wich was stablished until FW came on and can’t be managed… (only using metaphor!).
I think I’m almost certain that this is caused because the traffic is allowed outgoing, therefore it allows it back in, in a non cable modem situation this won’t show because you don’t see all the broadcasts from the other users.
Do you always get the same 10.x ip address from your provider ? what’s the lease time ?
You could try to set the ip fixed for testing and then see if that makes any difference, i think that if there is no outgoing dhcp request allowed outgoing it will block incoming like it should.
Ronny is pretty much on the mark here. I believe I’m correct when I say that, all SPI firewalls will allow traffic that is a a direct response to a request or for which you have explicitly made an exception. Everything else will be dropped.
With most client/server traffic, such as accessing a web server, the client chooses a port above 1023 for itself and then connects to the server on port 80. During the connection set-up, the client tells the server that when it responds, it should respond to the port the client chose.
With DHCP things are slightly different. In this scenario the client doesn’t select an ephemeral port for use, it, instead. uses a well known port (68) and will listen to broadcasts and unicasts on that port.
In the screen shots you posted, we can see the inbound connections being picked up by the Windows Operating System (WOS) object. This usually happens when inbound requests cannot be handled by any other appliction.
I’m guessing a little here, but I imagine that because your client is listening on port 68, it still sees all traffic destined for that port, but because the packets are not explicitly destined for your client, they are not used and so passed to WOS.
I have seen this in the past with other kinds of traffic and the only way to remove it from the logs is to create an explicit rule that blocks without logging for WOS.
Every rule that I create to block those 10.x incoming doesn’t work.
I tried a lot, Ronny’s choice too and NONE worked (see my rules, global and for WOS/svchost - they are set to block all incoming to 255.255.255.255 too - of course I don’t log them in normal operation).
The ONLY way to get those rules working good is leaving CIS at “Block All” for at least 3 minutes and then go back to Custom Police.
After this procedure, all 10.x incoming to 255.255.255.255 are blocked (otherwise, not) as long as the machine stays ON, no matter lease time/renew.
I think this is quite strange, and annoying, unless I’m missing something…
I will do some extra tests that involves forcing IP change, re-starting, plug my modem only after CIS is up, etc… but I can’t neither turn off or break my connection right now.
I think there are a few conditions where Limited Broadcasts are not “visably” blocked.
I’m not sure if CIS doesn’t block them, or just not logs them, i have seen a post of this before somewhere on the board.
You can try to install a packet sniffer like wireshark and see if that pics up the broadcast, the firewall driver is before the capture driver so blocked traffic should not show up in the capture.
Beware that for outgoing traffic this is reverse, so if it shows in the capture it’s not so that it will leave the system because the firewall driver can still block it before it reaches the wire/wave.
I’m really not sure what to tell you, I simply cannot recreate you situation.
My network environment is not dissimilar to your own, although I have a direct Ethernet connection to my ISP’s network, which uses the 172 .16.0.0/12 address space. If I don’t create block rules, I too see the DHCP broadcasts similar to those in your screen shots. However, once the rules have been created to block those I don’t wish to see, that’s the end of it.
My rules for this are really quite simple. To allow my PC to obtain an IP address I have an Application Rule for svchost:
Allow UDP OUT
Source Address = Any
Destination Address = 255.255.255.255
Source Port = 68
Destination Port = 67
To block the other DHCP broadcasts I don’t wish to see, I have a Global Rule:
Block UDP IN
Source Address = Any
Destination Address = 255.255.255.255
Source Port = 68 (you can use ANY here too)
Destination Port = 67
This works for me. I don’t have any rules for WOS. I do use Peerblock but I don’t use the IANA list, as I find it useless. I use Level 1, 2 and 3, I also use the spyware and Ads list
I really don’t know what to do from here on. Lost many hours investigating this wierd behavior and couldn’t see where is the lack (if any).
This is happening on my own machine and 2 others (from friends, different systems with XP-Pro-SP3 and connection from the same ISP) wich, in this case, I also did some tests. Rules works only after that “3 minutes procedure”, not “on the fly”.
Doesn’t seem so, it might be an bug.
If your able to provide a complete bug report and possibly a session with someone from Staff to see if they can reproduce it might be fixed.
