Hints on using Online Armor FW-a Learning Thread 4

OK. I can manage up to 10 PC for the task. Will report later if be lucky to find this "killer"

 

I'm back.

This actually works I must admit for one. But ..

This works in very limited manner. Nobody noticed that this kind of attacks works only for the computers with the same gateway and so attacker can be immediately revealed and deactivated by the simple administrative means. This is how it works in our lan and this is how it should work everywhere.

But, I should agree, it would be "cool" if my FW could prevent it. I could then brag before my friends

Now seriously. Do you really connected to the lan where such cryminal activity is possible ?

 

Internet Cafe.
Wireless Network.

 

Do they provide completely anonimous access ? Even in case they do, they just _must_ to have appropriate hardware device at their router which doesn't allow such activity. It is their obligation and their commercial interest. Though, I have already complied that theoretically it is possible. I still insist that practically this brings no more risk than probability to get accidental break to hit one's head.

 

The DOS is simply an "Spoofed ARP request", unless these are going through a managed/filtered gateway, it is easy to DOS anyone on LAN, and works effectivly (You could also look at DHCP poisoning, but you would need to create the packets)

I am on an ISP LAN,.. I was scanned with such tools, so there is a possibility of attack, but as my own gateway drops all inbound ARP, then no one on my ISP LAN can actually see my IP.
But I do know many users who are on untrusted LANs, and are at risk from this, and many other forms of inbound attack.

 

Just going back to this.

You have run this tool, and cut off one of the PC`s on LAN (which you must of done to say it works), then how is your gateway filtering this, it isnt. You did say you are on a LAN of thousands, so who Admins the gateway?
Also, as the packet sent is spoofed, there is no header info to actually trace this back to origin.

 

I have at least the two different lans. Huge home lan and tiny and friendly office lan. I have tested it in my tiny, friendly, office lan which can be called fully trusted

 

BTW, do you think it is possible in general case to prevent ARP spoofing taking in account that attacker can spoof your gateway with your fake mac address and no personal firewall can resist it ?

 

For ARP it does not matter about the gateway. It is just a need for your PC to have a correct binding of your Gateway IP/MAC

 

Yes, I agree, but this does not solve the ill effect. The only effective way to resist it is a LAN architecture. I'd say this is not a computer attack, this is LAN attack, and thus it is beyond the personal firewall scope. Though, personal firewall can filter poisoned requests in some extent. But .. as long as there is no reliable way to identify which packet is true and which is faked, all these ways are not a complete resolution in any case, they are just some "workarounds". And every one can be spoofed by changing spoofing algorythm. Don't you think "arp -s" is a better solution ?

 

You could place a static ARP entry into the cache. But it is simpler to have firewall rules to bind the gateway IP/MAC. Any spoofed attempt will be filtered out/blocked.
Have a look at Jetico2

At the end of the day, a firewall should be filtering ALL packets.

 

Do you mean FW should have an ability to bind IP-mac relations manually ?

 

For me personally yes. I believe it is needed, certainly as I see more and more on large ISP LAN`s. Yes, I know, most do state about having a router, but should a software firewall Vendor assume that a user does or should have a router?

From your own setup, on a very large LAN (with thousands), do you disable un-needed windows services? I ask, for as you should know, OA will currently "Trust" the LAN, so all comms will be allowed over your LAN. Maybe you have, but as OA is put forward as software easy for "mum" to use, would "mum" disable services when on such a LAN?

 

OK, our points with ARP are clear now.

As for the LAN, I create the rules for my netbios manually, or I can set global restrictions. It depends on my mood mainly in what particular way I protect my PC from the LAN. But the best way is to not share the critical resourses

 

Hi Stem: Well said, FWIW, I agree 101%. Vendors ( and not just OA) should never assume the user has a router, this would be particularly valid for a "mum" oriented product.

Well in my own case yes, but I learned that here from you and other security guys! Is "mum" is a member here? So with all due respect to all the "mums", I seriously doubt that more that 1% of users even know what a windows service is let alone how to disable the unneeded ones.


It is a no brainer that FW vendors should provide the trust/ no trust option a list of the competitive FW's to OA 2 that do provide this security basic staple would be conclusive.

I think Mike Nash has already committed to provide this?

http://support.tallemu.com/forums/viewtopic.php?t=1432&highlight=

 

Whatever restictions (rules) you put in place for such as netbios, these will currently be bypassed on LAN, due to the fact that the LAN is fully trusted. Even global restrictions are currently bypassed for LAN.

I think MikeNash now understands the possible problems of this, so I believe this will be changed.

 

Hi Pete,

There are quite a lot of users on Private IP LAN`s, that are possibly not fully trusted. So caution is needed.

To a certain point, I can understand the LAN being made trusted. But, is this really needed?, with default OA setup, trusted applications, such as SVChost will be allowed needed LAN comms anyway (auto allow trusted, auto config rules for trusted), so even if the LAN was "not trusted", the LAN comms would be allowed and restricted (with the restricted ports list).

 

Hi Escalader,

Yes, and that was 4 months ago, with how many OA builds within that time period? It is time to put this forward again.

I know there may of been other priorities, such as leak prevention. Certainly users of OA, on an untrusted private LAN will more than likely need leak prevention.

 

If the LAN was classed as internet (not trusted), then setting such a program as trusted should then allow it all the comms it needs (with default OA setup)

 

Exactly. The issue is the system ports for things like file/network sharing.

 

Mike/Stem:

Are we saying:

.....when the lan is classed as untrusted (internet) and this same user wants to share files, printer's etc over that network he must either trust the applications doing the "sharing" or the particular ip's/ users he wants to share with?

Poor wording I know, in my case I have 2 PC's on the world's smallest lan, thing is the other PC is a gaming pc and I don't want to share anything with it other than the isp service.

 

You should look at the "Restricted ports" as a single rule. If the LAN is trusted, then these ports are allowed over private IP LAN (only to following endpoints~ 192.* / 10.* etc). If the LAN is not trusted, then these ports are blocked (to any endpoints except following 0 - 255.255.255.255 [0.0.0.0/0])

 

Stem:

Is there any practical way I can put in FW rule(s) to do this in OA 2 as it currently stands? I don't want to trust the gaming PC sharing the router.

What would OA 2 rule look like?