Type 3 & Code 3

Booting the pc in de morning, I am getting this entries in de log.
Type 3 + Code 3 (Using a Modem\Router)

Is it safe to right click the entry, and make a rule to allow ICMP Type 3 code 3 ?

Thx

 

Hi De Hollander

You have 2 kind of packets:

1 ) IGMP

IGMP from your router to your PC:
D-4 'All other packets ' 192.168.2.1 IGMP Data:17 100 238 155

IGMP packet have to be authorised between the PC and the router.


2 ) ICMP


D-5 'ICMP : All ICMP types (n' 192.168.2.1 ICMP Type:3 Code:3

type 3 code 3 = port unreachable

It's possible that these ICMP c3 t3 are related to the IGMPs blocked packets.
Try first to authorised IGMP ...

This is in LOCAL only and not related to communications between your PC and Internet.

The only Type codes allowed between your system and Internet are:

Type 8 code 0 Echo : outgoing only
Type 0 code 0 Echo reply: incoming only -> reply to your PC echo only
Type 11 code 0 Timeout: incoming only

All the other type / code must be blocked for Internet.
You may create rules to block and log these various type / code if needed like
type 3 code 0 Network unreachable,
type 3 code 1 Host unreachable,
type 3 code 2 protocol unreachable,
type 3 code 3 ( the code/ type we're talking about), and so on...

Hope this help. Let us know.

 

After a couple of hours, reading and trying for my self, I'am still not able to "authorised IGMP" I wood not be suprise if it's something simple.

After making a rule for Type 3 and Code 3, those are going. But that's not the way to do it

 

Hi De Hollander

Try this IGMP rule.

Download the file
Rename it by removing the trailing .TXT
import in LnS
Save and apply. (and reboot to be sure...)

 

Thank you Climenole

I have edit the rule for the right Mac router address.
But as you can see, now I,am getting some other entry's to.

 

Hi De Hollander


OUPS!

delete that rule and use the corrected one:

(with in and out packets this time...)

 

Thank You so much, this works.

 

Hi De Hollander


Good news.

(Thank you for the animated picture too )

 

Why,.. I would prefer to be given "error" on such as a network/host unreachable. Your concerns are based on what you think, and the shortfalls of firewalls not to filter such comms.
My own setup sends out "Host unreachable" to any scans.

I know the change to IPV6 will enance ICMP, but will firewalls then take time to filter this fully as possible?

ICMP (error messages) are there for a reason (for possible errors).

 

Hi Stern

Yes my concerns are based on this ...

I had checked with a setup allowing such ICMP type/code to get out and
the opposite and found no difference in the remote responding to such signals. (or the opposite).

BTW: the problem here was local (between the PC and the router) not between the PC and Internet. By allowing IGMP packets between the PC and the router the ICMP type 3 code 3 issue was resolved. Isn't ?

An ICMP setup limited to ...:

Type 8 code 0 Echo : outgoing only
Type 0 code 0 Echo reply: incoming only -> reply to your PC echo only
Type 11 code 0 Timeout: incoming only

... keep The PC stealth and have to side effects as far as I know.

Best regards.

_

 

Hello,

Sorry if maybe OT, but is related.

So, do you not think it is about time that firewall vendors started to take time in filtering packets, as with ICMP, conditions (such as limited SPI) put in place? rather than left to "allow/block",... as with echo replies,.. this should be filtered and only allowed after an echo request.

We see many firewall vendors taking so much time with "leak prevention", and the packet filtering remains the same.


By the way,... my user name is SteM,... not SteRN

 

Hi Stem

(and not "SteRN: sorry for this...)

Yes sure! Allow/block filtering is a very basic one and somethings must be done to have filtering based on much more criterias than this.

In the example of ICMP type 3 code 3 it's possible but not easy to do much more by allowing this kind of ICMP signal to some Ips and deny the other ones but, as you know, this is far from a filtering based on a equivalent of SPI...

May be the next step in rules based firewall may included some data and format filtering (the "Application layer" of the TCP-IP) and conditional rules instead of the simplified logic used in rules based FW...

The same things is also possible with the HIPS and HIPS feature founded in many recent FW. And other possibility is to add some "bayesian" filtering which is more flexible than an "Allow/Block" ...

There's a lot of insteresting possibilities to be explored ...
Is there a developper ready to look further and open these possibilities?
I have no idea.

Best regards.

 

Hi all

About the ICMP type 3 code 3:


Top Ten Tips to Make Attackers’ Lives Hell

Quote:

" 3. Filter Outbound ICMP Type 3 Messages

ICMP type 3 (unreachable) messages are used during a UDP port scan to identify closed UDP ports, and therefore work out which UDP ports are open (as no ICMP "destination port unreachable" messages are seen for the open ports). The messages are also used by other security testing tools, including firewalk, to assess policies and rulesets of border routers and firewalls.

By filtering outbound ICMP type 3 messages, UDP port scanning is very difficult to undertake, and peripheral network testing techniques are also impeded. "

 

This is just one of many types of scans/ probes. As I mentioned, firewall vendors should be producing firewalls to better filter packets, not make users block outbound. You have to look at this as with any unsolicited inbound, it should simply be dropped by a firewalls default settings, not responded to.

 

Hi Stem,

Do you mean some firewalls are not providing a stealth/invisible protection against scans ?
This is normally the basic requirement.

Most of the time (except for TCP), having only an allow/block ability is sufficient to be stealth. Or do you know some cases this is not true ? (and in that case I guess Look 'n' Stop doesn't provide a stealth protection ).

Of course I understand SPI could be added for some other protocols like ICMP, and could for instance detect unsollicited Echo replies, but for me, this kind of detection doesn't improve the stealth protection, as the Windows stack will anyway drops the packet without sending a new packet.

Any comment welcome, so I can improve Look 'n' Stop if needed

Thanks,

Frederic

 

Hello Frederic,

This would depend on the definition of a firewalls "stealth/invisible". The majority of users believe that only TCP~SYN scans take place,.. well they must, to believe that a result of "Stealth" from such a simple scan actually makes them invisible.

I was actually responding to the posts made by "Climenole", which, after "Climenole" put forward a need to block outbound ICMP port unreachable, then posted info(link) to state that this blocking of ICMP port unreachable is needed due to UDP port scans. I would then presume that L`n`S does respond to such a scan?

The scans mentioned are based on (mainly empty) UDP packets sent against a firewall, results determined on response from a closed port (ICMP port unreachable),.. a firewall simply should not do this (IMHO), such an unsolicited inbound UDP packet to a closed port should be silently dropped, if the firewall does allow a response, I cannot class such a firewall as giving this so called "firewall stealth/invisible".

Regards,
Stem

 

Ok, thanks for the clarification.

Most of the UDP are blocked by default, so a scan won't generate an ICMP Type3/Code3.
The problem is some UDP ports need to be open, typically the DNS one.
So, for this port it is true that blocking ICMP Type3/Code3 is important to be stealth.
Now, I understand the discussion about having something else that just allow/bock, as the solution is to have an UDP SPI feature (or even DNS SPI), so an incoming UDP packet on port 53 will be accepted only if there was a first UDP packet sent on port 53.
Hopefully this will be added in a future release.

Frederic

 

Sorry to be back ( But the problem is not gone. I made a "big" mistake by not logging the rule ( ! The rule allows to look at packets. If one data packet matches the rule, it will be displayed by Look 'n' Stop in the log)

But there is a positive development (I hope) . The Type 3 and Code 3 are gone. I took another close look at the log, and it reported there where 3 ports closed. Going true all the rules I saw three entries related to sharing.rie. with a subnet mask entry of 255.255.0.0. I changed that to match the subnet mask on this pc (255.255.255.0) and there are no Type 3 and Code 3 reports.


edit: log

Picture NR 1 contains Mac adress from Router and Nr 2 from NIC.

Thx