in reply to ARP poisoning and redirection

$ sysctl net.ipv4.conf.all.arp_accept
net.ipv4.conf.all.arp_accept = 0

$ grep -A5 arp_accept linux/Documentation/networking/ip-sysctl.txt
arp_accept - BOOLEAN
        Define behavior for gratuitous ARP frames who's IP is not
        already present in the ARP table:
        0 - don't create new entries in the ARP table
        1 - create new entries in the ARP table

And did you verify that the attacking machine is receiving the frames? It may depend on the switching equipment and configuration, things like port binding, mac filtering. I doubt this whole approach might hold much promise.

Sharing the login credentials could make sense if it is to provide terminal access, but to have open remote logins... Sounds like the security in your playground is fundamentally broken, perhaps it is by choice.

Replies are listed 'Best First'.
Re^2: ARP poisoning and redirection
by QuillMeantTen (Friar) on Feb 13, 2016 at 09:49 UTC

    Well thank you, those ideas will be used in the next round of testing today. Once its all over I'll put a completed module targeted for that (rare) kind of broken playground in CUFP :)
    With a list of limitations of course... Update:
    this change solved part of the problem and the code should run without issues on a hub, now it seems that the router is blocking gratuitous arp replies, directed or not. This will require more investigation but I suppose a simple hub instead of a router/switch would let those through.

    One possible explanation that I would love anyone in the know to confirm or deny is the following:<br
    Even though arp is stateless the router keeps tracks of arp requests and replies and will only let a reply through if it has been preceded by a request AND|OR is agreeing with its own arp table

      I don't see what the ultimate goal is here. Are you trying to set up a DoS or an ARP hijack? If the latter, you probably want to enable ip_forward also. You haven't elaborated on the network topology, either. Protocol/flow description with the "usual suspects" Alice, Bob, Celia would no doubt be enlightening.

      If you want to work a trick in the classroom, you've plenty of alternatives. For example: scripted login to plug the holes and harden all hosts. In any case, please refrain from posting script-kiddie tools.

        I will quote my first post and explain it since it seems it was not clear enough:
        First, in bold:

        I do not intend to use on any network that is not mine to own and rule other as I see fit meaning made of machines I own as in paid for.
        Since the networking workshop is not made of machines that I own as stated in the first post I fail to see where I implied I would use my script in that setting.

        Next thing, if you had taken the time to read the code in said first post as well as that sentence:
        The idea came to me after other students told me that during the networking workshops at uni great pranks were to be played on unsuspecting marks : since all computers shared the same login and password one could decide to log into someone else's computer and either eject the legitimate user or reboot the machine.
        You would have understood that I am not trying either a DoS or an ARP hijacking (which is quite obvious if you just read the arp part of my code) but hey lets clarify that too.
        I am trying to tell a potential attacker that my machine has someone else's mac address. It is the opposite of an arp hijacking. The goal is to have their frames sent somewhere else in such a way that they will not be able to cause harm.

        Now onto the next thing, I would be most grateful if you were to explain to me in what way this is <q>script-kiddie code</q>. I am only a neophyte when it comes to network protocols or perl and I know I have a lot of things to learn but I fail to see where this code could be used to either DOS or arp hijack without so much of rewriting it would be equivalent to start from scratch. But do enlighten me so I do not make the same mistake again.