About ICMP, ARP and one block port

About ICMP, ARP and one block port (SOLVED)

I group,

For ICMP Rule:
I saw, it's better do not reply to Ping for do not let trace of our PC.

All rules into Jetico v1 on ICMP protocol
Accept, type: Echo Reply (0), code: any
Accept, type: Echo (, code: any <<<<<<< HERE: I don't check it
Accept, type: Destination Unreachable (3), code: any
Accept, type: Time Exceeded (11), code: any
Reject, type: any, code:any

Which rule should I reject or uncheck, the first one0) or the second (?

One port block
I come just make a port test for firewall and the test say the 113 port is block, however I never use this port from anywhere into my firewall (for block it or allow it)?
What can I do with this?

About ARP
For solve psychical address.
On the same test I just told before, during the test "around 30min., the test have passed perhaps 20 min. on this rule: Allow ARP requests, direction:any.

Is this protocol ARP in all direction is a possible weak spot, where some spyware can come from?

Thank.

 

For ICMP:
The first, (0) is echo reply. Allowing outbound lets your system reply to someone elses ping. Allowing inbound lets your system receive pings sent from your system.
The second should read ( 8 ), which is echo request. Inbound lets you receive echo request from others. Outbound is for pings sent from your system.

For (3) and (11), your choice.

If being hidden or stealthed is important to you, do not allow:
outbound echo reply (0)
inbound echo request ( 8 )

If you use echo or ping, you need to allow:
inbound echo reply (0)
outbound echo request ( 8 )

Port 113.
Rarely used. OK to block. In some cases, stealthing port 113 can cause connection problems with specific servers, not common.

ARP can be used on local networks to spy on others on that network. On home networks, it's not a problem. I may be wrong about ARP. Hopefully someone will correct this if I am.
Rick

Editied to add spaces to echo request type. Forum translates 8 inside of () to (.

 

Hello Mido.

Did you do grc test perhaps? If you did, and if you are behind a router (and I assume you are), than it's your router that replied to pings. Setting Jetico rules won't help much in this case, you need to change the ICMP settings for your router (following the advice Herbalist gave). Note that some ISPs use ping reply to check on your status, availability, etc, so you may run into some problems with connection if you disable it.

For port 113 -
Again, this would be the router. You could try to forward this port to a non-existent IP on your LAN in your router config (look for 'port forwarding', 'virtual server' or something similar). This will stealth it.

ARP is a touchy subject on Wilders. There are very few who fully understand it, and I am not one of them...

Lastly, I wouldn't bother with any of this issues if I were you.

Cheers,

 

herbalist,
Seer,

Ok, thank for your support!

When I'am gone on Shield Up! with the default setup, every ports were stealth and the test say:"Your system ignored and refused to reply to repeated Pings (ICMP Echo Requests)".

I have seen that thing (reject the Ping reply) somewhere.
I was not sure if the default setup of Jetico 1 was enough strong, even if the test show something good.

I had uncheck the second ICMP rule, but I will replace the default setup "if it's good with Shield Up!"

I will let a pic of default ICMP setup, because herbalist told about incoming/outgouing. If never.

I don't have router.

Thank.

 

The 2nd rule in your pic above just allows outgoing ICMP 8, which let's you ping others. That's fine to enable that one. That goes along with the rule above it for accepting a ping reply from that outbound ping (ICMP 0 in). Both are ok.

 

Re: About ICMP, ARP and one block port (SOLVED)

Kerodo,
Group,

That mean everything is ok, it's solved.

Thank.

 

Why would you say that?

I would agree that most may not look at this layer, but there is actually little to understand. ARP as a packet is very simple,.. it is what actaully makes it so open to possible attack. I have mentioned this before,.......

 

From this Anatomy of an ARP Poisoning Attack article it would seem the typical home user with a single pc or a few networked pc's with trusted family members would have nothing to worry about? Or since ISP's are lumping large groups of their customers into LAN segments, should we be concerned?

 

For a home user on a home network, no,. But I look at what is past this with what you ask next:-

Yes, you should be/ You will find most users are now on ISP LAN`s

With respect, the shorcut you show,... well.... lol. This actually shows nothing on actual attacks against ARP.

 

Thank you. That answers my question.

Sorry, I chose it because it looked like something I could understand

 

Understanding may seem possibly easy, it it bybass of this that can be complicated. Please dont worry,... we need to put together a full explanation.

 

Ignore that comment, wording was not accurate (english is not my native language). Perhaps I meant 'mysterious'?
A few times in the last couple of months, I have seen only your replies on topic.

Vast majority is looking primarily at their setups (I do too). It is the main reason home users do not look at ARP.
Your perspective is slightly different...

This link may shed some light to the op's question regarding ARP SPI

 

Yes, and one that I have seen, too. My main question was whether or not a typical home user needs to be concerned about ARP attacks, and Stem confirmed that it is something not to be disregarded. As for what, exactly, it all means...well, I have some reading to do

Otherwise, I agree Jetico is an excellent firewall. It just does not appeal to the masses because of its spartan look and configuration options that present a considerable challenge for most to set up. Personally, I hope Nail doesn't add a bunch of silly bells and whistles to it.

 

Hi wat0114,

ARP (Address Resolution Protocol) Link for some info

Basically what we are looking at is one of the main base for comms over LAN, without this (or incorrect use) there would be no connections over LAN (or through gateway to internet)
You would of seen DHCP, which basically obtains your IP / Gateway / DNS servers,.. but comms cannot be made untill the hardware MAC is known for the IP in use.

So as simple example:
When booting the PC on LAN, you will have DHCP boot, this will obtain your IP etc. When you attempt to connect, there will then be ARP to first obtain the MAC of the Gateway (without this, or with incorrect info, then no internet), your gateway will then check your MAC /IP to confirm.

 

Thank you for the info Stem. At least I understand it better now. If you have test results of firewall's ability to circumvent ARP attacks, please do let us know

 

This is just impossible i'm afraid. You can protect your computer against your gateway (other computer) MAC address spoofing, but you can do nothing against gateway been spoofed with your false MAC address. Fortunately, modern switches and routers can deal with this. If not then fixed MAC addresses can help. But any personal firewall is powerless in a general case just because it cannot protect _other_ computer.

 

From your description, you are saying that false info can be placed into the router cache to give incorrect binding of a PC IP/MAC which would then DOS that PC. This would not work, as the PC itself would update the router ARP cache on connection attempt.

If we look at the simplest form of spoofed ARP DOS, this is made via an ARP request, where info given is incorrect, the PC ARP cache is updated with the router IP with non-existant MAC, this then leads to DOS.
Now if we look at your example, a node on LAN sends a spoofed ARP request to the router, this will update the router cache with that info, but, as soon as the PC attempts to connect, it will make a request itself with correct info, again the router ARP cache will be updated, so DOS would not take place,... only if the router was to be flooded with spoofed packets would the PC have major connection problems, but so would other PC`s on LAN due to flooding of gateway.

Looking at spoofed ARP against the gateway from external LAN, this is certainly debatable, as this would depend on what protection the router has, but as with most, I doubt that such a spoofed ARP request DOS will be blocked with most home type routers (I have never taken time to check, as I do not use a router as gateway on my setup)

 

Yes, I mean exactly the case when a router is flooded. Once "answer" arrives after spoofed packet it is routed to the false MAC. The only way to avoid is to send "answer" exactly to the MAC request came from. But this depends on the router, not on the requestor. This is why I say it is impossible to resist it in a _general_ case, by a mean of only ARP policy of a single computer.

 

Hello alex_s,

Although I can see this as probable within an internal LAN, I have not actually come across this, and certainly cannot see why an attacker would take such a path, as this would be seen easily via all other nodes on LAN.
I will try and find time to look at this type of attack against one of the home type routers, to see what bandwidth would be needed from the attacker to impliment such an attack.
Certainly any form on LAN attack needs to be looked at,.. but if such an attack also give the attacker problems, then I cannot see this as viable,.. but, as I said, I will try and find time to look at this.

Regards,


Merry christmass to you,

Steve

 

Hi wat0114,

There are actually very few firewalls that allow any form of rule creation for ARP, some do impliment "Options" for ARP. such as blocking unsolicited replies,.. limiting inbound requests,.. but none "out of the box"(that I know) will prevent all ARP DOS.

I will find time to go through the firewalls (new versions) to see what is implimented (but spare time is short, so will take a while).

As example (from previous checks), outpost pro does have a number of options for filtering of ARP, but the option to prevent ARP spoofing did actually cause problems. What I mean is: Setting OP to prevent ARP spoofing, then sending a spoofed ARP request packet to OP actually caused OP to block all ARP from the gateway, so DOS was actualyl implimented by OP itself.

I know Comodo was to impliment better ARP filtering, but due to lack of spare time, I have not yet been able to look at this implimentation (earlier versions had very little protection).

The new ARP SPI by Jetico does give some protection, but it default rule will not block spoofed request (there is a need to create rules)

L`n`S does show options to block ARP spoof, but I have not fully checked this.

Merry Christmass

Steve

 

Gents...

...Not sure about this. You might want to try ARP poisoning as implemented by Cain or NetCut. These will DOS a LAN target in no time, without flood.
WAN should'n work - in general - because of ARP subnet switching issues.

 

"Netcut" performs DOS by spoofed ARP request (the DOS I mentioned earlier).

Cain does have options for ARP poison, to use replies/requests (I have still not seen one of these tools use ARP announce to poison/DOS). As I mentioned above, the firewalls that do impliment some form of ARP protection do put in place a block of unsolicited replies.
edit
From my setup with Jetico2 (user ARP rules in place), it does prevent ARP poison/DOS from both netcut and Cain.(actually, on my setup, neither can actually see the PC to be able to poison/DOS it)

 

Thank you for the clarification Stem. If you ever test the latest version of Outpost, please let us know, though I know you are very busy, so there are no expectations

Merry Christmas!

 

Have just looked at the latest release (6.0.2225.232.0465) to check the ARP protection.

Out of the box, the settings are:-



The above default settings will not protect against netcut.

If you enable the "Block host when it enumerates other computers on LAN", this will drop ARP scans, but the alert for this appears to be buggy,... out of 4 scans, I was only alerted to one (but as mentioned, the actual scans where dropped).

To block the spoofed ARP request used by Netcut to DOS, you must enable the "Block sniffer if gateway network adapter MAC was changed", on an attempt to send such a single spoofed packet, a warning is shown:-

(ARP packet to DOS not sent by Netcut,


This does now appear to work correctly.

I will make further checks when I have more time. But, OP pro 2008 will block Netcut when all ARP protection options are enabled.

Regards,

 

Group,

I'am really not sure if this discussion fragment can bring something on your argumentation.

If we have access to a ARP file/table where are input ARP request.

A kind of little programme who could make a count of each request for each remote address and if the number of request = n-1 (n=potential attack) then delete or reset the ARP table.