Block single IP address

Help for v2
21

Hey egemen and pandlouk!

OK, been trying the rules you suggested egemen and it’s working 100%! No leechers for over an hour now - and they aren’t even appearing in my Emule list as being On Queue! Perfect. Thanks so much to you both - we finally got there :slight_smile: :slight_smile: :slight_smile: I’m a happy bunny now!!

22

Hey egemen,

Thanks for your detailed explanation. It will undoubtedly be referenced continually in the future.

Would it be an idea to have a sticky note at the top of the forum containing high level / low level notes on common connection blocking scenarios?

The wording and layout you used is very simple to follow for the average user and still contains enough nuts and bolts to satisfy the dweebs.

Thanks in advance,
Ewen :slight_smile:

23

Hey Egemen
You were perferctly clear.
I have a question. I thought in asking you by PM but maybe others are interesting in this so I post here:
I came across during the tests that if someone uses an allow IN rule for TCP or TCP/UDP at a specific port (for p2P programs), then this port is not being stealthed when the program does not run. And this can be a security hole especially when users leave the default ports of those programs.
Is there a way for stealthing it with CPF? For the time being I have not figured out how to do it. (The only way for doing this is to leave activated Windows Firewall, but this isn’t really a solution)

pandlouk

24

Hi Pandlouk,

Yes when some ports are allowed incoming traffic, Windows TCP/IP stack sends some sort of port closed message to the remote host that is trying to connect to the port. This “port closed” reply will make port scanners to think that it is “Closed” instead of “Stealth”. But while under attack or something serious, CPF will adaptively secure the host even if you allow the traffic to all ports in the network rules. So currently it does not pose a serious risk.

Nonetheless, we have added this issue to our list and it will be implemented to make better inbound protection.

Thnk you all for the cooperation,

Egemen

EDIT : We have changed this behavior and the fix will be available in the next update which is expected to be in a couple of days - 23/05/2006

25

Is this similar to the way ZoneAlarm adaptively stealths ports dependant upon user activity?

ewen :slight_smile:

26

Hi Ewen,

I dont exactly know how ZA does this but CPF stealths the ports according to the attacker behavior. For example if it detects that an attack is in progress, it may temporarily block the attacker’s access or it may block the inbound traffic temporarily(emergency mode).

Egemen

27

Hi, egemen & others -

I appreciated your explanation - this cleared up some confusion for me.

Could I please make a suggestion? Could you consider renaming the “Remote” field to “Destination”? I believe that having a Source / Destination pair makes more sense to the user than having a Source / Remote pair.

Cheers,

dooplex

28

Egemen,

From what you say, I would conclude that

(1) “Block” in network monitor rules implies “block only unsolicitated attempts to connect”

(2) “solicitated”=connections of SYN/ACK or ACK type

(3) “unsoliciated”=connection of SYN type

Did I get this right?

By the way, this would be perfect example for “library of examples” we discussed on the other post

https://forums.comodo.com/index.php/topic,828.msg5269.html#msg5269

It would be really good idea to have FLOW CHART of how CPF processes information!!!

Zoran

29

Hey Zoran,

(1) - Correct

(2) - Solicited means the data packet is being received by us as a response toa arequest we sent out.
Example:
If we ping a server, the return packets are a solicited response.

(3) - Insolicited means a data packet arrived at our PC that was not a response to a request sent by us.
Example:
If someone “out there” pings us, this is an unsolicited request.

Hope this helps,
Ewen :slight_smile:
(WCF3) (WCF3) (WCF3)

30

Okay, to play a devil’s lawyer (just for my own understanding):

A: some server (e.g. local) that sends message to me regulary informing me on updates

B: my computer

(1) A —SYN–> B (“hi there, I want to connect”)

At this stage packet (1) is unsolicitated, I did not ask for it. But, I accept it (e.g. having some network monitor rules that does this).

(2) B —SYN/ACK —> A (“okay, you’ve got my ear”)

(3) A—ACK—>B (“good let’s talk”)

now connection is established

(4) A—(data)–>B (“I have some updates for you, here they are”)

Okay, now at this stage, I haven’t really asked for (data) but it gets in. Is(4) solicitated or unsolicitated package?

Zoran

31

Direction field must be “IN” and SOURCE IP and REMOTE IP must be exchanged. Please have a look at the following message

https://forums.comodo.com/index.php/topic,193.msg1458.html#msg1458 to solve this problem.

Egemen

32

(4) is solicited because (2) said “OK, come on in”. That and the fact that you had an explicit rule that allowed the initial SYN in.

Ewen :slight_smile:

33

A question, Egemen.
How do I implemented this with my non-direct connection (Sock 5) ?

*. I use Putty to tunnel my way “in/out” the Net
*. I’ve tried using IP instead of TCP/UDP… still no luck

…am I “special” case here, or do CPF Dev’s forgot about this type of connection?

34

If attackers’ IP addresses remain the same, i.e. if your proxy does not change the remote IP addresses no difference.

35

Ah, I see…
Thanks, Egemen.

36

Hmmm… I see now. Happily jumping around filled with joy of life and a little extra understanding.

Many thanks!!!

Zoran

37

LOL. Doesn’t take much to float your boat, Zoran. :wink: