Programming

Hello,

I need help on how to "access" or manipulate the Linux ARP Cache in C, here is the description of the project i'm working in:

There are a lot of tools that analize ARP frames and send an e-mail to the sysadmin, that's easy. What i want to do is to inspect every ARP frame that arrives to my network interface and, if it "passes the tests", then, and ONLY THEN apply the changes in the ARP cache.

I'm able to analize every field of the ARP frame that i capture, but not to avoid the malicious frame to take effect over the cache because i can't stop the kernel.

So, how can i do that? how could i check the frame and if it's a valid one THEN apply it to the cache, just before the kernel does it?

Any help will be appreciated,
Thank you!

I had to use strace on the arp utility to see what it was doing. It opens /proc/net/arp to see the current state, and uses ioctl calls to add or delete items. See here for details; I did the testing on linux, but HP seems to at least document those ioctls. May differ slightly across systems.

As for filtering arp packets, arptables sounds like the way to go.

Hey Corona688!,
Thank you for your reply,

Yes, i want to implement something like arptables, but i need to filter also ethernet frame fields, so i can't use arptables.

I was thinking that it would be necessary to code a kernel module, but, for what i see, arptables does it and it's a user space aplication, so, what i need is the way to do it, i'll try arptables source code.

Thank you.

---------- Post updated at 11:45 AM ---------- Previous update was at 11:35 AM ----------

Ohhh no,
here's what i thought...

Code:

  if (!*handle) {
                arptables_insmod("arp_tables", modprobe);
                *handle = arptc_init(*table);
                if (!*handle) {

arptables uses a kernel module to block the arp table and allow data to it... Does anybody has a way better to to this?

To prevent the kernel from doing kernel level things, you must modify the kernel. That's the only place where you can get the kind of raw, exclusive I/O you want.

Really, though, what is the goal here? Maybe there's a better way than hacking nonstandard behavior into your entire networking stack.

Or if you really want 100% raw access, just disable TCP/IP support in your kernel. No more TCP, no more ARP, no more kernel automatically managing either. You'd have to do it all yourself.

What i need is simply avoid the kernel's action in the cache when receiving an arp frame, i don't think i must disable the entire TCP/IP stack for that.

i've been reading arptables code, but there's nothing that could give me a clue... only that i need to code a lkm to access to the kernel space and kinda "intercept" the frames before the kernel does, but not HOW.

The question always is how...

ARP sits very near the base of that stack. Without it, not much else will work. To reiterate, what is your goal? The answer is not "intercepting arp". The answer is whatever the ultimate purpose of this venture is. I suspect there might be a much, much better way to accomplish what you're thinking of since intercepting ARP is such an odd problem but without knowing your goal its hard to help.

Certainly you'll be causing a lot more problems for yourself than you'd ever solve by trying to hack your own backdoors into the kernel networking code. Bugs in kernel code have far more dire consequences than bugs in user code, for one thing. There's few to none of the niceties programmers have grown to expect over the last few decades either. For another you'll have to reinvent your code every time a kernel upgrade breaks compatibility -- that could be up to several times a year -- and installing your software on any other computer would be tantamount to reinstalling the OS with your own custom one. You'd be compatible with nothing else in the world but your own custom computing environment, not even other computers of the same distribution. And not all distributions take kindly to having their kernels arbitrarily replaced.

IMO - you need to state what you are hoping to do - not merely "intercepting" - WHY are you intercepting - what are you trying to stop? You are where you are probably becuase you are unaware that other people had the same problem years ago. And there are solid solutions out there.