nf_conntrack on edison?

[idata]

Hello All - Has anyone had luck getting nf_conntrack to work in poky? I am trying to set limits in IPTables (gotta stop the Mirai botnet )

Here is some troubleshooting:

root@ed-wr1:~# uname- a

Linux ed-wr1 3.10.98-poky-edison+ # 1 SMP PREEMPT Mon Jun 6 14:32:08 PDT 2016 i686 GNU/Linux

wr1:~# opkg install conntrack-tools

Installing conntrack-tools (1.4.0-r0) on root.

root@ed-wr1:~# iptables -L -n

Chain INPUT (policy ACCEPT)

target prot opt source destination

ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED

ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0

ACCEPT all -- 0.0.0.0/0 0.0.0.0/0

ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22

ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:80

ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:443

REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT)

target prot opt source destination

REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT)

target prot opt source destination

root@ed-wr1:~# opkg install conntrack-tools

Installing conntrack-tools (1.4.0-r0) on root.

root@ed-wr1:~# iptables -A INPUT -p tcp --syn --dport 22 -m connlimit --connlimit-above 3 -j REJECT

iptables: No chain/target/match by that name.

I beleive the module exists:

some file system proof:

/sys/module/nf_conntrack

/proc/1/net/nf_conntrack

/proc/1/net/stat/nf_conntrack

root@ed-wr1:~# cat /proc/1/net/nf_conntrack

ipv4 2 tcp 6 431999 ESTABLISHED src=10.0.1.5 dst=10.0.1.18 sport=52316 dport=22 src=10.0.1.18 dst=10.0.1.5 sport=22 dport=52316 [ASSURED] mark=0 use=2

Trying to load the module gives no erorrs(but not showing in lsmod)

root@ed-wr1:~# modprobe nf_conntrack

root@ed-wr1:~# lsmod

Module Size Used by

usb_f_acm 14335 1

u_serial 18582 6 usb_f_acm

g_multi 70924 0

libcomposite 39238 2 usb_f_acm,g_multi

bcm_bt_lpm 13708 0

bcm4334x 587105 0

I'd appreciate any help.

Cheers,

-Joe

PS If you want to get started with a firewall for the edison I put a basic config here: https://github.com/joemcmanus/edisonFW https://github.com/joemcmanus/edisonFW

https://github.com/joemcmanus/edisonFW GitHub - joemcmanus/edisonFW: A basic firewall config for the Intel Edison (Poky)

[idata]

I *believe* the conntrack module is statically compiled in to the kernel:

root@ed-wr1:~# cat /lib/modules/3.10.98-poky-edison+/modules.builtin | grep conntr

kernel/net/ipv4/netfilter/nf_conntrack_ipv4.ko

kernel/net/netfilter/nf_conntrack.ko

So I should just be able to use the limit function of iptables. No luck there yet.

-Joe

[idata]

Hi Joe,

Thank you for reaching out.Let me investigate this case a little bit more. I'll try to build from source the conntrack-tools package to see if I get different results, I just tried doing what you showed in your post and got the same results.Kind regards,-Pablo

[idata]

Thanks Pablo. I tried recompiling libnetfilter_conntrack and iptables...

I tried the following:

Compile from source libnetfilter_conntrack 1.0.6

https://www.netfilter.org/projects/libnetfilter_conntrack/files/libnetfilter_conntrack-1.0.6.tar.bz2

Compile from source iptables 1.6.0

ftp://ftp.netfilter.org/pub/iptables/iptables-1.6.0.tar.bz2

Compile from source conntrack-tools 1.4.4

http://www.netfilter.org/projects/conntrack-tools/files/conntrack-tools-1.4.4.tar.bz2

Then again I tried iptables -A INPUT -m limit -j DROP and the same error.

I can't wait to see what you com up with! Thanks for the help.

Cheers,

-Joe

[idata]

Hi Joe,

I already have some updates on your case. I was able to build conntrack-tools from source (after having to install a lot of dependencies), however, I'm not getting different results.I'm wondering if you've ran the same command in a different Linux system, maybe your personal computer, do you get the same results? Also, have you tried to test if the command is indeed working? I don't know if the message you're getting is just a warning and not exactly an error.Kind regards,-Pablo

[idata]

Hi Joe,

Do you have updates on this issue? Were you able to check what I suggested last week? Regards, Pablo

[idata]

Hello Pablo - Yes those commands work on Fedora and OpenWRT. I verified on Fedora 24 in a VM and the Arduino Yun running OpenWRT.

The nf_conntrack tools are user space tools. I believe this error is from the kernel IP Tables runs at the kernel level.

I downloaded and compiled IPTables 1.6.0 and had no different behavior. Which makes me think the kernel was not compiled with full nf_conntrack support.

Cheers,

-Joe

[idata]

Hi Joe,

In that case, you might want to give it a try to a newer kernel version (vanilla Linux kernel). This is a project from a user, but you can try it yourself if you have the time. Take a look at this link https://edison.internet-share.com/wiki/Using_a_vanilla_Linux_kernel_with_Intel_Edison https://edison.internet-share.com/wiki/Using_a_vanilla_Linux_kernel_with_Intel_Edison.This is another useful thread from the Intel Community /thread/75472 https://communities.intel.com/thread/75472.Regards,-Pablo

[idata]

Hi Joe,

We are wondering if you have any other question on this case, let us know and we'll be happy to help you.Kind regards,-Pablo

[idata]

Hey Pablo - I did not try... I use this board to teach a graduate course on securing the internet of things. So I don't want to make them load an "off-brand" OS.

But if I may make a suggestion; with the rise in attacks on the IoT it would be great if Intel did not ship an OS with a crippled firewall. With attacks like the Mirai Bot Net on the rise security should be paramount on a dev platform. With the IoT security starts with the developer. If the developer is aided by having a things like a default firewall, disabled root login, no default passwords etc you'll be making it harder for the adversary.

Just my wish list

Cheers,

-Joe

[Pablo_M_Intel]

Hi Joe,

I totally understand your point. We are aware of the potential risks this implies. We will pass your feedback to the Development team, hopefully they will come up with something to improve or change this.

Kind regards,

Pablo