Suggestion to improve grsecurity (( Vs Ettercap ))

[Sharky]

Hi there to all those putting their effort to to guide grsecurity to it's perfection stage.
as you know recently one of the most dangerous networking tools threatining is ettercap. to be more precise the subject of "arp poisening" and spoofing.
I'm wondering if in the future grsecurity would develop such a tool to detect arp poisening ( by monitoring arp for dupilcate MAC/IP ).
note that lots of ettercap functions can be capped when arp is statically mapped.
Regards!

[TGKx]

Wouldn't be more in grsecurity's scope to restrict the sending of arp packets that do not match valid nics' mac addresses? Also an option to monitor someone else sending arp packets out with our mac(s) that didnt come from us?

It seems any other sort of detection is more appropraite for a NIDS.

as you know recently one of the most dangerous networking tools threatining is ettercap. to be more precise the subject of "arp poisening" and spoofing.
I'm wondering if in the future grsecurity would develop such a tool to detect arp poisening ( by monitoring arp for dupilcate MAC/IP ).
note that lots of ettercap functions can be capped when arp is statically mapped.

[spender]

Not to mention that this problem can be solved in several ways. If you want to detect the attacks, run arpwatch. If you want to prevent the attacks, use the MAC module for iptables, static arp...etc etc.

-Brad

[TGKx]

After doing a little more reading you can stop someone from sending out malicious arp packets from your box by using ACL's to restrict raw binding correct?

[spender]

Yes, restricting outgoing packets is possible in grsecurity.

-Brad

[Sharky]

I did not know that iptables MAC module could help stoppign ettercap, and i still dont know how.
the ways of stopping ettercap found so far is static ARP but it requires YOu as a member on the network to statically map your ARP + your gateway admin to static mac on his side.
if one side only statically arp his hosts it wont work

[TGKx]

if one side only statically arp his hosts it wont work

This is incorrect. By statically mapping your side you will be preventing a MitM attack and limiting the amount of character injection and sniffing of your outbound packets. The attacker would probably end up causing a DoS to you if he attempted to use ettercap to sniff your machine since he would be receiving all the packets but none of the packets you are sending out would go to him.

Combine the statically mapped arp entries with arpwatch and the usage of encrypted protocols when transfering password information, and you should not worry too deeply about ettercap.

*edit

The only conceivable way I can think of that an attacker could get around this would be for him to overflow the arp table of the switch he was on so it went into broadcast mode. Once it was in broadcast mode he could technically MitM your connection by redirecting all of your received data and sniffing all of your outbound data.

The caveat of this is that overflowing arp tables these days would be very obvious to a sysadmin who watches and your arp watch would definately pick this up.

[Sharky]

Hi Again
Commenting on the subject of one Side static mapping.
In my home network Linux Box ( A ) acting as a router to do NAT, connected to a switch of course, other 4 pc's are running Linux as well.
On PC (B) running Slack Linux I did statically mapped the MAC address of my gateway and the other pc's.
PC (C) using Linux as well, was able to ARP poisen and sniff all the packets of PC (B )
the way the mapping was Done was using arp -f /etc/etters where that file contained HOST MAC.
Maybe the way i statically mapped was wrong ? is there any way of static mapping besides than this one ?

[TGKx]

The way ettercap performs a MiTM attack is it convinces the host that it is the gateway and that the gateway it is the host, then performs translation between these two with raw sockets after its done its sniffing. If the ettercap box cant convince the host that it is the router, any packets the host is sending out will not be intercepted/read (unless the switch is forced into broadcast mode).

If the ettercap is able to convince the gateway that it is the host, it can sniff/modify/forward whatever it wants to the host, but cant see what is going the other direction.

The ettercap forums are probably a better place to discuss this if ya want and they are more familiar w/ current capabilities. I havent messed w/ ettercap since early .6's.

The attacker would probably end up causing a DoS to you if he attempted to use ettercap to sniff your machine since he would be receiving all the packets but none of the packets you are sending out would go to him.

Depending on the type of mitm attack and injection this statement may not be entirely correct (sorry). If a person was trying to inject entire packets they would be unable to do so because they couldnt watch all of the sequence packets in a tcp connection. To modify/sniff packets destined to the host though should not be a problem unless the connection in question is using a symmetric or public/private key encryption.

Hardcoding all of the mac's into the switch in question is the best solution to this issue. If you cant do that, encryption, hardcoding your hosts mac list, and arpwatch will limit the impact of the 'half' MiTM attack.