Debian defaults

Just keeping track of some stumbling blocks encountered (knowing that much might be intentional to keep the system "lean" or as an incentive for "learning" ;-) - but best solutions everyone needs anyway could of course be listed here by many contributors, as well as deep-linked to in other threads they've popped up in)...

Installing various distributions (ARM and Intel/AMD) within a few days, I've noticed some defaults could be added (looking at Debian-3.16.0-kirkwood-tld-2-rootfs-bodhi for the examples below) where things take inordinately long to search & set up otherwise:

Neither /usr/bin/tzselect nor dpkg-reconfigure tzdata, even when they have been found, say they set the TZ for more than the current user (even recommending to add exports to the ~/.profile) - this could be prompted for system-wide, have one recommended way of setting it (possibly as simple as echo 'Continent/Capital' >/etc/timezone ?), or be preset to a usable default for root (all the more since ntpdate seems to be installed already) - which one is the intended "standard approach"?

Several key components (incl. Perl needed all the time as part of package management) complain with respect to locale/lang settings - not sure how this is best avoided (not by setting everything I guess, as LC_ALL for instance is discouraged):

root@debian:~# man
man: can't set the locale; make sure $LC_* and $LANG are correct
What manual page do you want?
root@debian:~# perl -v
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
	LANGUAGE = (unset),
	LC_ALL = (unset),
	LC_PAPER = "de_DE.UTF-8",
	LC_ADDRESS = "de_DE.UTF-8",
	LC_MONETARY = "de_DE.UTF-8",
	LC_NUMERIC = "de_DE.UTF-8",
	LC_TELEPHONE = "de_DE.UTF-8",
	LC_IDENTIFICATION = "de_DE.UTF-8",
	LC_MEASUREMENT = "de_DE.UTF-8",
	LC_TIME = "de_DE.UTF-8",
	LC_NAME = "de_DE.UTF-8",
	LANG = "C"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

This is perl 5, version 14, subversion 2 (v5.14.2) built for arm-linux-gnueabi-thread-multi-64int
(with 88 registered patches, see perl -V for more detail)

Shouldn't the LED go dark (echo 0 >/sys/class/leds/status:green:health/brightness) on halt, to signal when it's safe to pull the plug (or light up then if it was off during normal operation?), cf. http://midnight-coder.blogspot.de/2013/12/pogoplug-e02-configure-leds.html ?

Curiously there is no default /etc/crontab nor an apparent process that would use it, according to ps aux|grep cron and dmesg|grep which also returns empty while I'd expect something like "Starting periodic command scheduler: cron." - as per http://forum.doozan.com/read.php?2,12096,16414#msg-16414 it should be there?

There's no "less", easily installed no less. ;)

Surprisingly the barrage of ssh hacking attempts (several per second especially from high-bandwidth Asian netblocks) I've always seen on Arch (and Ubuntu) as soon as port 22 has to be exposed beyond the LAN has started much later&lighter according to logread Debian @ 3.16 - just a lucky coincidence, or is there any more aggressive filtering/greylisting in place on this one (and which settings can long-term users recommend for a public ssh port) ?
On the other hand there are dire warnings on regular connects from within the LAN (where the provider's crappy router admittedly is a poor resolver that requires clients to keep their local peers on /etc/hosts or fixed IPs):

Mar 23 00:03:01 debian auth.info sshd[5465]: Address 192.168.2.101 maps to localhost, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT![/quote]



Edited 2 time(s). Last edit at 03/25/2015 03:16PM by TEN.

TEN,

> Neither /usr/bin/tzselect nor dpkg-reconfigure
> tzdata, even when they have been found, say they
> set the TZ for more than the current user (even
> recommending to add exports to the ~/.profile) -
> this could be prompted for system-wide, have one
> recommended way of setting it (possibly as simple
> as echo 'Continent/Capital' >/etc/timezone ?), or
> be preset to a usable default for root (all the
> more since ntpdate seems to be installed already)
> - which one is the intended "standard approach"?
>
> Several key components (incl. Perl needed all the
> time as part of package management) complain with
> respect to locale/lang settings - not sure how
> this is best avoided (not by setting everything I
> guess, as LC_ALL for instance is discouraged):

This one is hard to decide. My rootfs has been used by users worldwide (I'm very honored), so I'm hesitate to add any locale to it. I could add more suggestion in the instruction about what to do about this after the system running the first time.

> Shouldn't the LED go dark (echo 0
> >/sys/class/leds/status:green:health/brightness)
> on halt, to signal when it's safe to pull the plug
> (or light up then if it was off during normal
> operation?),

It should. See /etc/init.d/halt. It turns off the LED, not just going dark. And it turns on Green in /etc/rc.local.

> Curiously there is no default /etc/crontab nor an
> apparent process that would use it, according to
> ps aux|grep cron - but per
> http://forum.doozan.com/read.php?2,12096,16414#msg
> -16414 it should be there?
>

I'll take a look at this one. I thought it's there.

> Surprisingly the barrage of ssh hacking attempts
> (several per second especially from high-bandwidth
> Asian netblocks) I've always seen on Arch (and
> Ubuntu) as soon as port 22 has to be exposed
> beyond the LAN has started much later&lighter
> according to logread Debian @ 3.16 - just a lucky
> coincidence, or is there any more aggressive
> filtering/greylisting in place on this one (and
> which settings can long-term users recommend for a
> public ssh port) ?

:) I think it might have something to do with this rootfs using Debian security repo in apt sources (could you check if is it there?)

> On the other hand there are dire warnings on
> regular connects from within the LAN (where the
> provider's crappy router admittedly is a poor
> resolver that requires clients to keep their local
> peers on /etc/hosts or fixed IPs):
> Mar 23
> 00:03:01 debian auth.info sshd[5465]: Address
> 192.168.2.101 maps to localhost, but this does not
> map back to the address - POSSIBLE BREAK-IN
> ATTEMPT!

This is weird. I think it might be specific to yours. I set my nameserver to 8.8.8.8, I don't even have the router IP (192.168.0.1) in /etc/resolv.conf. UPDATE: is your MAC address set to the real value or to the locally random addr in the u-boot default envs?

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 3 time(s). Last edit at 03/22/2015 07:01PM by bodhi.

Quote
bodhi

Quote
TEN
Neither /usr/bin/tzselect nor dpkg-reconfigure tzdata, even when they have been found, say they set the TZ for more than the current user (even recommending to add exports to the ~/.profile) - this could be prompted for system-wide, have one recommended way of setting it (possibly as simple as echo 'Continent/Capital' >/etc/timezone ?),
or be preset to a usable default for root (all the more since ntpdate seems to be installed already) - which one is the intended "standard approach"?

Several key components (incl. Perl needed all the time as part of package management) complain with respect to locale/lang settings - not sure how this is best avoided (not by setting everything I guess, as LC_ALL for instance is discouraged)

This one is hard to decide. My rootfs has been used by users worldwide (I'm very honored), so I'm hesitate to add any locale to it. I could add more suggestion in the instruction about what to do about this after the system running the first
time.

Congratulations on the well-deserved following. :) So whatever the solution (e.g. just what you do first yourself for your locales&TZ), will make it easier for many...

Quote
bodhi

Quote
TEN
Shouldn't the LED go dark (echo 0 >/sys/class/leds/status:green:health/brightness) on halt, to signal when it's safe to pull the plug (or light up then if it was off during normal operation?)

It should. See /etc/init.d/halt. It turns off the LED, not just going dark. And it turns on Green in /etc/rc.local.

echo none  > /sys/class/leds/status:green:health/trigger

...seems instantaneous in normal operation, but could it take a few ms for the trigger to be picked up before the halt (and could brightness as above be faster) ?
I'll test with a sleep 5 inserted, as it always stayed on here.

Quote
bodhi

Quote
TEN
Curiously there is no default /etc/crontab nor an apparent process that would use it, according to ps aux|grep cron - but per http://forum.doozan.com/read.php?2,12096,16414#msg-16414 it should be there?

I'll take a look at this one. I thought it's there.

I recall it had already gone missing around kernel 3.14 as I reported last year.

> > is there any more aggressive filtering/greylisting [against ssh-breaking bots] in place on this one
> > (and which settings can long-term users recommend for a public ssh port) ?

> might have something to do with this rootfs using Debian security repo in apt sources (could you check if is it there?)

This is what it's using:

root@debian:~# cat /etc/apt/sources.list
deb http://ftp.us.debian.org/debian wheezy main
deb http://security.debian.org/ wheezy/updates main contrib non-free

> > On the other hand there are dire warnings on
> > regular connects from within the LAN (where the
> > provider's crappy router admittedly is a poor
> > resolver that requires clients to keep their local
> > peers on /etc/hosts or fixed IPs):
> > Mar 23
> > 00:03:01 debian auth.info sshd[5465]: Address
> > 192.168.2.101 maps to localhost, but this does
> not
> > map back to the address - POSSIBLE BREAK-IN
> > ATTEMPT!
>
> This is weird. I think it might be specific to
> yours. I set my nameserver to 8.8.8.8, I don't
> even have the router IP (192.168.0.1) in
> /etc/resolv.conf. UPDATE: is your MAC
> address set to the real value or to the locally
> random addr in the u-boot default envs?

Yes, the MAC address is always set to the physical one to give me uBoot access already, and because the LAN peers have no way of resolving local names to DHCP-assigned IP addresses - so besides /etc/hosts on every (even visiting) machine, the only way is to make the router's DHCP assign fixed IPs for certain MAC addresses such as Pogo and printer as well as the netconsole's peer.
It does become annoying with mobile devices that do present a name in DHCP negotiation and could be addressed by that rather than by an IP address that changes every day in the absence of further precautions.
Arcadyan & friends however are quite (unreasonably IMHO) insistent about not allowing a router to be a resolver for local requests regarding names to non-world-routable IPs (though their provider-prescribed box does hold that table of course and bug reports requesting this expected feature have been around for years) - but then again they in particular have had worse things to fix as a priority...

TEN,

> ...seems instantaneous in normal operation, but
> could it take a few ms for the trigger to be
> picked up before the halt (and could brightness as
> above be faster) ?
> I'll test with a sleep 5 inserted, as it always
> stayed on here.

It should finish before the actual halt command can even start. Should check the box /sys/class/leds to see if you have the same named trigger in the /etc/init.d/halt script.

> This is what it's using:
> root@debian:~# cat /etc/apt/sources.list
> deb http://ftp.us.debian.org/debian wheezy main
> deb http://security.debian.org/ wheezy/updates
> main contrib non-free

I think it is enough to get the benefits from Debian security.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Quote
TEN

Quote
bodhi

Quote
TEN
Shouldn't the LED go dark
(echo 0 >/sys/class/leds/status:green:health/brightness)
on halt, to signal when it's safe to pull the plug (or light up then if it was off during normal operation?)

It should. See /etc/init.d/halt. It turns off the LED, not just going dark. And it turns on Green in /etc/rc.local.

echo none  > /sys/class/leds/status:green:health/trigger

...seems instantaneous in normal operation, but could it take a few ms for the trigger to be picked up before the halt (and could brightness as above be faster) ?
I'll test with a sleep 5 inserted, as it always stayed on here.

Probably changes to the file (after which the script proceeds to halt) aren't directly mapped to the GPIO pins, but need some process (with too little time to still run) to pick them up.

Quote
TEN

Quote
bodhi

Quote
TEN
Curiously there is no default /etc/crontab nor an apparent process that would use it, according to ps aux|grep cron - but per http://forum.doozan.com/read.php?2,12096,16414#msg-16414 it should be there?

I'll take a look at this one. I thought it's there.

I recall it had already gone missing around kernel 3.14 as I reported last year.

root@debian:/# ps aux|grep systemd
root      2196  0.0  0.5   2020  1376 pts/0    S+   18:58   0:00 grep systemd
root@debian:/# ps aux|grep cron
root      2193  0.0  0.5   2020  1372 pts/0    S+   18:55   0:00 grep cron
root@debian:/# find -name *cron*
./etc/cron.weekly
./etc/cron.daily
./usr/share/doc/passwd/examples/passwd.expire.cron
./lib/modules/3.16.0-kirkwood-tld-2/kernel/drivers/hid/hid-zydacron.ko

I.e. no anacron etc. either, q.e.d., but it doesn't seem to be running systemd instead either though /etc/systemd/system has a definition for avahi.

> > > > is there any more aggressive filtering/greylisting [against ssh-breaking bots] in place on this one
> > > > (and which settings can long-term users recommend for a public ssh port) ?
> > > might have something to do with this rootfs
> > > using Debian security repo in apt sources (could you check if is it there?)
> > root@debian:~# cat /etc/apt/sources.list
> > deb http://ftp.us.debian.org/debian wheezy main
> > deb http://security.debian.org/ wheezy/updates
> > main contrib non-free

> I think it is enough to get the benefits from Debian security.

On kernel 3.13+ this should hence be nftables, though with nft not even installed, I can't see any particular defenses yet, but e.g. nmap can't OS-probe it and a good deal of packets to port 22 get dropped after short nagging, so the botnets probably focus on identifiable lower-hanging fruit first.



Edited 1 time(s). Last edit at 03/23/2015 02:21PM by TEN.

TEN,

> I'll test with a sleep 5 inserted, as it always
> stayed on here.

Is the echo command located before the halt command in /etc/init.d/halt?

echo none  > /sys/class/leds/status:green:health/trigger
halt -d -f $netdown $poweroff $hddown

If it is, then something is wrong if it's stay on like that. Perhaps the machine settings are not consistent. Please take a look at these:

dmesg | grep -i machine | cut -c16-120
fw_printenv arcNumber
fw_printenv machid

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Quote

I.e. no anacron etc. either, q.e.d., but it doesn't seem to be running systemd instead either though /etc/systemd/system has a definition for avahi.

This rootfs is default to sysvinit as before with 3.17. It was dist-upgrade to jessie, so systemd was automatically installed. I've put it back to sysvinit as the default init, but left systemd installed so that users can choose to run systemd by adding a parameter (in bootargs) to the kernel command line in u-boot env.

usb_set_bootargs=setenv bootargs console=$console root=$usb_root rootdelay=$usb_rootdelay rootfstype=$usb_rootfstype $mtdparts init=/bin/systemd

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

> Is the echo command located before the halt command in /etc/init.d/halt?

It is, and actually sleep 5 in between just before the log_action_msg "Will now halt" does the trick:
Then the LED has time to be turned off - while I can't trace the code path from the file change to settting GPIO, this looks like a race condition of the harmless kind.
FWIW these look OK to me:

Machine: Pogoplug E02
arcNumber=3542
machid=dd6

There's another one about the mceusb BTW:
Once the lirc package has been installed, after every reboot this dongle has to be pulled and replugged once for irw to work (irsend does all the time), even though the detection in dmesg looks exactly as on boot, and so does:

root@debian:~# lsmod|grep mceusb
mceusb                  8283  0 
rc_core                13793  13 ir_sharp_decoder,lirc_dev,ir_lirc_codec,ir_rc5_decoder,ir_nec_decoder,ir_sony_decoder,mceusb,ir_mce_kbd_decoder,ir_jvc_decoder,ir_rc6_decoder,ir_sanyo_decoder,rc_rc6_mce
root@debian:~# rmmod mceusb
root@debian:~# modprobe mceusb

I've found it could also be made work again by unloading and reloading the driver through the last 2 lines and will be detected more reliably (i.e. both irw and irsend working "OOTB") on reboot if the following line 24 is added to /etc/init.d/lirc before the modprobe:

                        rmmod $mod 2> /dev/null

> This rootfs is default to sysvinit as before with 3.17
> so systemd was automatically installed. I've put it back to sysvinit as the default init

That might explain how cron got removed, and I know to replicate it by calendar timers in systemd , but I'm not exactly keen to go down in history as the first who volunteered to use it bleeding-edge new ;) and with the much more verbose files required in comparison to /etc/crontab.

Experiences on nft (in particular against the ssh brute-bots) appreciated for the same reason...

TEN,

> It is, and actually sleep 5 in between just before
> the log_action_msg "Will now halt" does the
> trick:
> Then the LED has time to be turned off - while I
> can't trace the code path from the file change to
> settting GPIO, this looks like a race condition of
> the harmless kind.

Something is not right. The halt command can't be executed that fast. I've never seen my boxes fail to turn off the LED while shuttingdown! But if it works with a few extra seconds shutting down, so be it :)

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Quote
bodhi
Something is not right. The halt command can't be executed that fast. I've never seen my boxes fail to turn off the LED while shuttingdown! But if it works with a few extra seconds shutting down, so be it :)

Now there we have it; you've exposed a Secret Agency skunkworks project building a Beowulf cluster of nitrogen-cooled Pogoplugs overclocked to 4+GHz each, computing for World Domination. ;)

But seriously, this one isn't a LAMP, MiniDLNA, Samba or anything of the kind yet, i.e. no DB/FS commits etc. do be completed, but used to expose mceusb infrared I/O and a VFD via lcdproc to the network, besides some minor control tasks (all permitting instant shutdown).

Very useful as is already at just 4 Watts approx., but it'll get much busier (also as a pound gateway to various other applications and appliances) once I have some clarity on automating SSH defences through nftables, and a cron - BTW found what happened to that and what users should (re)install?

I have had another one (Dockstar) running a DVB-T streaming VDR nicely, and some fairly sophisticated domotics code (integrating RF and X10 powerline besides IR, as well as an MP3 jukebox with a 4-button remote & audio-only interface) to port to Regina from a system old enough to have been running OS/2 (like ATMs do) 24/7 for 18 years and counting.



Edited 1 time(s). Last edit at 03/25/2015 03:19PM by TEN.

TEN,

> some clarity on automating SSH defences
> through nftables, and a cron - BTW found what
> happened to that and what users should
> (re)install?

I have not looked at the differences in defaults for nftables and sshd config. I'd guess there were changes in the default setup for latest versions of those capabilties. I did not explicitly change the defaults at all in the basic rootfs (I left it up to individuals to tailor their rootfs).

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Quote
bodhi
I'd guess there were changes in the default setup for latest versions ... I did not explicitly change the defaults at all in the basic rootfs (I left it up to individuals to tailor their rootfs).

It seems https://wiki.debian.org/nftables has been retracted even on jessie.
Not sure what is firewalling actually in your 3.16 release, as there's no iptables binary either.
So I'll just apt-get install cron for now.

TEN,

If you look at the release thread, I described:

Quote

- Installed packages: nano, avahi, ntp, busybox-syslogd (log to RAM), htop, isc-dhcp-client, dialog, bzip2, nfs server/client, iperf, ethtool, sysvinit-core, sysvinit, and sysvinit-utils.

That's exactly what were installed on top of a Debian debootstrap rootfs from mainline.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Here's the experience with FDT jessie on kernel 3.18.5 so far, after hours of apt-get update && apt-get upgrade:

Quote

Preparing to unpack .../tzdata_2015b-1_all.deb ...
Unpacking tzdata (2015b-1) over (2015a-1) ...
Setting up tzdata (2015b-1) ...
locale: Cannot set LC_ALL to default locale: No such file or directory

Current default time zone: 'SystemV/PST8PDT'
Local time is now: Sat Mar 28 14:38:05 PDT 2015.
Universal Time is now: Sat Mar 28 21:38:05 UTC 2015.
Run 'dpkg-reconfigure tzdata' if you wish to change it.

So that's what we'll have to do for TZ since most of us can't be in California.
For locale I'm not too sure what should be the canonical approach (certainly not setting LC_ALL which is a testing override only) to stop perl etc. from nagging.

jessie already has u-boot-tools and runs a systemd-udevd (no more need nor room for cron?), so I'll leave it at these:
apt-get install netcat mtd-utils mc lirc less lcdproc

Something new appears on the latter (I thought cme was still experimental?):

Quote

lcdproc configuration can be merged automatically by cme during package upgrade. This process will keep your configuration customization, apply maintainer's changes
and write back the configuration files.

You can later edit lcdproc configuration with the command 'sudo cme edit lcdproc'.

If you decline this option, your configuration file will not be managed by the package manager.

Perform automatic configuration upgrade ?

< Yes > < No >

Selecting previously unselected package libgpm2:armel.
(Reading database ... 12473 files and directories currently installed.)
Preparing to unpack .../libgpm2_1.20.4-6.1+b2_armel.deb ...
Unpacking libgpm2:armel (1.20.4-6.1+b2) ...


Setting up mc (3:4.8.13-3) ...
update-alternatives: using /usr/bin/mcview to provide /usr/bin/view (view) in auto mode
Setting up lcdproc (0.5.7-2) ...
locale: Cannot set LC_ALL to default locale: No such file or directory
Fixing lcdproc configuration...
Can't exec "/usr/bin/dpkg-architecture": No such file or directory at (eval 122) line 1, <F> line 5.
cannot run dpkg-architecture at (eval 122) line 2, <F> line 5.
Use of uninitialized value $triplet in scalar chomp at (eval 122) line 3, <F> line 5.
Use of uninitialized value $triplet in concatenation (.) or string at (eval 122) line 4, <F> line 5.
Warning in 'server DriverPath' value '/usr/lib//lcdproc/': missing DriverPath dir (code is: ' defined $_ ? -d : 1')
Can't exec "/usr/bin/dpkg-architecture": No such file or directory at (eval 126) line 1, <F> line 5.
cannot run dpkg-architecture at (eval 126) line 2, <F> line 5.
Use of uninitialized value $triplet in scalar chomp at (eval 126) line 3, <F> line 5.
Use of uninitialized value $triplet in concatenation (.) or string at (eval 126) line 4, <F> line 5.
Can't exec "/usr/bin/dpkg-architecture": No such file or directory at (eval 128) line 1, <F> line 5.
cannot run dpkg-architecture at (eval 128) line 2, <F> line 5.
Use of uninitialized value $triplet in scalar chomp at (eval 128) line 3, <F> line 5.
Use of uninitialized value $triplet in concatenation (.) or string at (eval 128) line 4, <F> line 5.
Can't exec "/usr/bin/dpkg-architecture": No such file or directory at (eval 131) line 1, <F> line 5.
cannot run dpkg-architecture at (eval 131) line 2, <F> line 5.
Use of uninitialized value $triplet in scalar chomp at (eval 131) line 3, <F> line 5.
Use of uninitialized value $triplet in concatenation (.) or string at (eval 131) line 4, <F> line 5.
update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
Starting LCDd: LCDd.
Setting up lirc (0.9.0~pre1-1.2) ...
[ ok ] No valid /etc/lirc/lircd.conf has been found..
[ ok ] Remote control support has been disabled..
[ ok ] Reconfigure LIRC or manually replace /etc/lirc/lircd.conf to enable..
Setting up mtd-utils (1:1.5.1-1) ...
Processing triggers for libc-bin (2.19-15) ...

Just don't you believe it: service LCDd starts without error to console, but won't work for reasons visible via logread instead (and "start and stop actions are no longer supported" may indicate a move to systemd stuck midway):
The contents of /etc/LCDd.conf are no good:

Quote

## This file was written by cme command.
## You can run 'cme edit <application>' to modify this file.
## Run 'cme list' to get the list of applications available on your system
## You may also modify the content of this file with your favorite editor.


[server]
DriverPath=/usr/lib/lcdproc/
NextScreenKey=Right
PrevScreenKey=Left
ReportToSyslog=yes
ToggleRotateKey=Enter

[menu]
DownKey=Down
EnterKey=Enter
MenuKey=Escape
UpKey=Up

First, in jessie there has been a change not reflected by the above, to DriverPath=/usr/lib/arm-linux-gnueabi/lcdproc/ that needs to be adjusted manually - and the file's minimal contents can't drive any display there is, so google for a good one, be sure to change Custom-Characters from a comment to the display's physical properties, and Bind from 127.0.0.1 to the NIC IP as PogoPlug is probably supposed to expose the display to other machines on the LAN, then service LCDd restart into some usable configuration.

Sadly, LIRC (given a valid configuration that had been reported missing above, e.g. mine from http://ubuntuforums.org/showthread.php?t=2270362) with mceusb manages to crash the Plug:
You can e.g. "irsend -a 192.168.2.94:8765 send_once I44 KEY_POWER" one single time, and even that (while working once) responds with an "irsend: timeout".
It works again once you "rmmod mceusb;modprobe mceusb" but unfortunately on most attempts this hangs your ssh root shell on the rmmod, and from another one you get to see the following minutes later:

Mar 29 09:19:51 debian user.err kernel: [30960.293473] INFO: task lircd:1713 blocked for more than 120 seconds.
Mar 29 09:19:51 debian user.err kernel: [30960.299866]       Not tainted 3.18.5-kirkwood-tld-1 #1
Mar 29 09:19:51 debian user.err kernel: [30960.305362] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Mar 29 09:19:51 debian user.info kernel: [30960.313232] lircd           D c0553a4c     0  1713      1 0x00000001
Mar 29 09:19:51 debian user.warn kernel: [30960.319858] [<c0553a4c>] (__schedule) from [<c0553ec4>] (schedule_preempt_disabled+0x14/0x20)
Mar 29 09:19:51 debian user.warn kernel: [30960.328686] [<c0553ec4>] (schedule_preempt_disabled) from [<c055575c>] (__mutex_lock_slowpath+0xd4/0x180)
Mar 29 09:19:51 debian user.warn kernel: [30960.338345] [<c055575c>] (__mutex_lock_slowpath) from [<bf0d008c>] (rc_close+0x18/0x50 [rc_core])
Mar 29 09:19:51 debian user.warn kernel: [30960.347525] [<bf0d008c>] (rc_close [rc_core]) from [<bf10e778>] (lirc_dev_fop_close+0x64/0xe8 [lirc_dev])
Mar 29 09:19:51 debian user.warn kernel: [30960.357177] [<bf10e778>] (lirc_dev_fop_close [lirc_dev]) from [<c00fe8c4>] (__fput+0xd4/0x1f0)
Mar 29 09:19:51 debian user.warn kernel: [30960.366087] [<c00fe8c4>] (__fput) from [<c0034aa0>] (task_work_run+0x94/0xac)
Mar 29 09:19:51 debian user.warn kernel: [30960.373293] [<c0034aa0>] (task_work_run) from [<c0010b14>] (do_work_pending+0xc4/0xe0)
Mar 29 09:19:51 debian user.warn kernel: [30960.381500] [<c0010b14>] (do_work_pending) from [<c000e2bc>] (work_pending+0xc/0x20)
Mar 29 09:19:51 debian user.err kernel: [30960.389307] INFO: task rmmod:1824 blocked for more than 120 seconds.
Mar 29 09:19:51 debian user.err kernel: [30960.395920]       Not tainted 3.18.5-kirkwood-tld-1 #1
Mar 29 09:19:51 debian user.err kernel: [30960.401085] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Mar 29 09:19:51 debian user.info kernel: [30960.409182] rmmod           D c0553a4c     0  1824   1647 0x00000001
Mar 29 09:19:51 debian user.warn kernel: [30960.415617] [<c0553a4c>] (__schedule) from [<c0553ec4>] (schedule_preempt_disabled+0x14/0x20)
Mar 29 09:19:51 debian user.warn kernel: [30960.424422] [<c0553ec4>] (schedule_preempt_disabled) from [<c055575c>] (__mutex_lock_slowpath+0xd4/0x180)
Mar 29 09:19:51 debian user.warn kernel: [30960.434071] [<c055575c>] (__mutex_lock_slowpath) from [<bf10ea10>] (lirc_unregister_driver+0x5c/0x138 [lirc_dev])
Mar 29 09:19:51 debian user.warn kernel: [30960.444634] [<bf10ea10>] (lirc_unregister_driver [lirc_dev]) from [<bf114020>] (ir_lirc_unregister+0x14/0x6c [ir_lirc_codec])
Mar 29 09:19:51 debian user.warn kernel: [30960.456042] [<bf114020>] (ir_lirc_unregister [ir_lirc_codec]) from [<bf0d2420>] (ir_raw_event_unregister+0x64/0xa4 [rc_core])
Mar 29 09:19:51 debian user.warn kernel: [30960.467660] [<bf0d2420>] (ir_raw_event_unregister [rc_core]) from [<bf0d0788>] (rc_unregister_device+0x34/0x94 [rc_core])
Mar 29 09:19:51 debian user.warn kernel: [30960.478717] [<bf0d0788>] (rc_unregister_device [rc_core]) from [<bf1820b0>] (mceusb_dev_disconnect+0x28/0x68 [mceusb])
Mar 29 09:19:51 debian user.warn kernel: [30960.489723] [<bf1820b0>] (mceusb_dev_disconnect [mceusb]) from [<c04302e4>] (usb_unbind_interface+0x70/0x250)
Mar 29 09:19:51 debian user.warn kernel: [30960.499727] [<c04302e4>] (usb_unbind_interface) from [<c03c5288>] (__device_release_driver+0x7c/0xc4)
Mar 29 09:19:51 debian user.warn kernel: [30960.509239] [<c03c5288>] (__device_release_driver) from [<c03c5a74>] (driver_detach+0xec/0x118)
Mar 29 09:19:51 debian user.warn kernel: [30960.518011] [<c03c5a74>] (driver_detach) from [<c03c5128>] (bus_remove_driver+0x64/0x90)
Mar 29 09:19:51 debian user.warn kernel: [30960.526385] [<c03c5128>] (bus_remove_driver) from [<c042f528>] (usb_deregister+0x58/0xfc)
Mar 29 09:19:51 debian user.warn kernel: [30960.534632] [<c042f528>] (usb_deregister) from [<c0077f5c>] (SyS_delete_module+0x124/0x18c)
Mar 29 09:19:51 debian user.warn kernel: [30960.543030] [<c0077f5c>] (SyS_delete_module) from [<c000e280>] (ret_fast_syscall+0x0/0x2c)

Also the E02 can't be rebooted after this: It only does terminate sshd but then gets stuck somewhere on the way down and has to be power-cycled.

In summary: I'll have to stay at kernel 3.16 for now.



Edited 2 time(s). Last edit at 03/29/2015 05:42AM by TEN.

TEN,

Reminder: you can go back to wheezy and run kernel 3.18.5. It does not have to be jessie. I think wheezy will last a while, hopefully what ever problem with mceusb will be fixed by the time you upgrade to jessie.

BTW, this is the best we can do on the Pogo V3 OXNAS, since I have to build new kernel version for the Pogo V3 to transition to jessie because of systemd dependencies (if users want to go systemd on their jessie rootfs)

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 2 time(s). Last edit at 03/29/2015 05:18AM by bodhi.

TEN,

> locale: Cannot set LC_ALL to default locale: No
> such file or directory

> For locale I'm not too sure what should be the
> canonical approach (certainly not setting LC_ALL
> which is a testing override only) to stop perl
> etc. from nagging.

Below was what I did to set locale. Note that everything in locale.gen should be commented out, except your location. My example is for US locale:

apt-get install locales

- change locale.gen
cat /etc/locale.gen | grep ‘en_US.UTF-8 UTF-8’
en_US.UTF-8 UTF-8

- generate locale
locale-gen

cat ~/.utf8
export LANG=en_US.UTF-8

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

bodhi Wrote:
> you can go back to wheezy and run kernel 3.18.5.

The cause of crashes being reproducible in a LIRC module moved to kernel, I may rather not want to upgrade to the bug though. ;-)

Can't tell whether 3.19.1 handles mceusb any better, since there's little interest at http://archlinuxarm.org/forum/viewtopic.php?f=6&t=8652 which is using that kernel already.



Edited 1 time(s). Last edit at 03/29/2015 05:56AM by TEN.

bodhi Wrote:
-------------------------------------------------------
> > > locale: Cannot set LC_ALL to default locale: No such file or directory
>
> > For locale I'm not too sure what should be the
> > canonical approach (certainly not setting LC_ALL
> > which is a testing override only) to stop perl etc. from nagging.
>
> Below was what I did to set locale. Note that
> everything in locale.gen should be commented out,
> except your location. My example is for US locale:
> apt-get install locales

So one uncomments the required locale(s) from /etc/locale.gen,
> en_US.UTF-8 UTF-8
then runs locale-gen followed by update-locale LANG=en_US.UTF-8

Contrary to much of the information still out there (e.g. http://serverfault.com/questions/17118/how-do-i-set-the-date-format-to-iso-globally-in-linux), for reasonable unambiguous ISO-8601-compliant date display in Europe the proper locale isn't en_DK.UTF-8 anymore (so usually don't build that), cf. http://unix.stackexchange.com/questions/62316/why-is-there-no-euro-english-locale

However, adding a line of TIME_STYLE=long-iso into /etc/default/locale helps (update-locale above also accepts it as a further parameter), except for missing seconds (full-iso would be too long):

root@debian:~# ls -l /boot/v*
-rwxr-xr-x 1 root root 2755976 2014-09-01 07:29 /boot/vmlinuz-3.16.0-kirkwood-tld-2

Entering e.g. Umlaut or accent marks seem to require building a European locale such as de_DE.UTF-8, though that does not need to be set as LANG.



Edited 4 time(s). Last edit at 03/29/2015 07:19AM by TEN.

TEN Wrote:
-------------------------------------------------------
> bodhi Wrote:
> > you can go back to wheezy and run kernel
> 3.18.5.
>
> The cause of crashes being reproducible in a LIRC
> module moved to kernel, I may rather not want to
> upgrade to the bug though. ;-)
>

Right :))

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

TL;DR: Thwart about 95% of logging & load from ssh brute-force attacks (mainly from mainland China at present):
/etc/network/if-up.d/iptables (chmod 755) of

#!/bin/sh

iptables-restore < /etc/iptables/rules.v4

with the contents below for the latter file

*filter
:INPUT ACCEPT [52:3440]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [36:5048]
:SSHbrute - [0:0]
-A INPUT -i eth0 -p tcp -m tcp --dport 22 -m recent --update --seconds 7200 --reap --name SSHbrute --rsource -j DROP
-A INPUT -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name SSHknown --rsource
-A INPUT -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 15 --hitcount 2 --name SSHknown --rsource -j SSHbrute
-A SSHbrute -m recent --set --name SSHbrute --rsource -j LOG --log-prefix "SSHbrute "
COMMIT

or via apt-get install iptables-persistent. Commands below won't just work in startup script (then setting no ACCEPT rules).
YMMV, at your own risk of locking yourself out along with the zombies if settings are too aggressive for your use (then undo on USB media from PC/rescue system).

Quote
bodhi

Quote
TEN

Quote
bodhi
I'd guess there were changes in the default setup for latest versions ... I did not explicitly change the defaults at all in the basic rootfs (I left it up to individuals to tailor their rootfs).

It seems https://wiki.debian.org/nftables has been retracted even on jessie.
Not sure what is firewalling actually in your 3.16 release, as there's no iptables binary either.

Quote
release thread
- Installed packages: nano, avahi, ntp, busybox-syslogd (log to RAM), htop, isc-dhcp-client, dialog, bzip2, nfs server/client, iperf, ethtool, sysvinit-core, sysvinit, and sysvinit-utils.

That's exactly what were installed on top of a Debian debootstrap rootfs from mainline.

To keep the onslaught of botnets from saturating our little ARMs (especially where irresponsible mobile providers obstruct SSH ports than 22, that would put these assaults at least a portscan further out of reach), which can reach the point of getting the legitimate admin locked out by sheer load, we'll need apt-get install iptables in both wheezy and jessie.

For the greater good ;) as well as my own systems' sake, I have taken the time to sort out what works well as of Q1/2015.

Limiting the number of password attempts per ssh logon to 2 (i.e. allow for 1 human typo) rather than 5 would also be helpful, if anyone knows where this should best be set.

pam_abl hasn't been updated in years, and pam_tally(2) is to auto-lock user accounts under attack, which isn't what we want for a "headless" server, possibly even many hours away.
pam_shield let alone fail2ban might have a little more automation than anyone and their ARMs would want to handle in this setting.

ufw is just an Ubuntu frontend to netfilter/iptables really (rather than a full-fledged firewall in its own right), trading flexibility for ease of use that makes the most appropriate setup for the issue at hand hard to find (if at all achievable through its simplified options).

For iptables itself though, you'll mostly find recommendations of crude rules simply dropping everything from e.g. the 4th connection within a 1-minute interval, for just as long after attempts cease.

However, even brute bots aren't as simple as that:
Their herders have taught them to adjust and come back nagging, seconds after the time it took their target to start blocking (we're talking about serious organized crime after all).
I.e. the more sensitive (short time and low number of attempts) your first line of defense, the earlier they'll retry in turn.

So contrary to netfilter defaults with the recent module, we'll have to make the unblocking much longer than the interval that gets them listed for DROPs in the first place.

While even then you might be inclined to unblock a few minutes after the bot goes away, note that most will keep coming back after increasing intervals of e.g. 10 or even 60 minutes.

In fact the old approach http://la-samhna.de/library/brutessh.html#4 described for linking sshd to /etc/hosts.deny for an hour of blocking is what makes bots give up in the end.

This way we can more thoroughly keep them from bothering sshd, consuming our precious CPU cycles and spamming the syslog with alerts for fake passwords.

The commonly recommended LOGDROP chains would re-log the same bot address repeatedly though.

So upon bot strategies observed hitting several live hosts this week, and to balance the logon load taken off our little boxen without adding too much for a long list of exclusions to parse, I propose a rather aggressive ban after the second hack connect within 15 seconds (indicative of automated attempts; possibly, if you're sure it'll never get in the way of your own needs e.g. for scp, complemented by a 4th INPUT rule to be triggered by "3+ hits within 60-120 seconds" to also catch less patently & more patiently obnoxious bots; Chinese BTW reminiscent of Neuromancer, how could Gibson have known?), not to be lifted until 3 hours later:

iptables -N SSHbrute
iptables -A SSHbrute -m recent --set --name SSHbrute -j LOG --log-prefix "SSHbrute "
iptables -I INPUT 1 -p tcp --dport ssh -i eth0 -m recent --update --seconds 7200 --reap --name SSHbrute -j DROP
iptables -I INPUT 2 -p tcp --dport ssh -i eth0 -m state --state NEW -m recent --set --name SSHknown
iptables -I INPUT 3 -p tcp --dport ssh -i eth0 -m state --state NEW -m recent --update --seconds 15 --hitcount 2 --name SSHknown -j SSHbrute

Inspiration comes from the above URL as well as http://www.netfilter.org/documentation/HOWTO/de/netfilter-extensions-HOWTO-3.html#ss3.14, http://serverfault.com/questions/273324/how-to-make-iptables-rules-expire#537382, https://www.tty1.net/blog/2007/iptables-firewall_en.html#brutessh and http://www.thegeekstuff.com/2012/08/iptables-log-packets/.
The --reap option is supposed to be available contrary to http://unix.stackexchange.com/questions/76271/iptables-recent-module.
https://www.debian.org/doc/manuals/securing-debian-howto/ is considered useful background.

Actually the bots' behaviour of often only probing the port without a password before they reconnect immediately for rounds of guesses works in our favour, giving them 5 tries less by default (3 out of which would be fully logged) at our passwords before the DROPs kick in.

cat /proc/net/xt_recent/SSHbrute will show you how like a hornet's nest, the blacklisted drones will soon send a hive mate from a netblock nearby to sting in their stead.
If some src IP addresses stand out (especially with the seconds diagnostically extended to days) as particularly annoying from a netblock (IP range) none of your legitimate users can possibly ever be in, this might give you ideas for permanent manual blacklists (e.g. one for 115.23?.*.* and 183.136.*.* would stop 90% of the unhealthy interest in systems under my control, though the chance of someone who should get access ending up just there years after that is set and forgotten has always made me reluctant to this approach).

Note that all rules but the topmost INPUT kick in on NEW sessions, so the last instances of sshd already started to serve the bot its first few bites at the password will give a little teergrubing to the attacker and unlike the extra lines retained below, won't add much to the syslog after the respective source IP address has been logged for earning itself an entry on the SSHbrute list.

Mar 31 12:04:28 debian authpriv.notice sshd[26533]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=183.136.216.3  user=root
Mar 31 12:04:30 debian auth.info sshd[26533]: Failed password for root from 183.136.216.3 port 45036 ssh2
Mar 31 12:04:33 debian auth.info sshd[26533]: Failed password for root from 183.136.216.3 port 45036 ssh2
Mar 31 12:04:40 debian auth.info sshd[26533]: Failed password for root from 183.136.216.3 port 45036 ssh2
Mar 31 12:04:41 debian auth.info sshd[26533]: Received disconnect from 183.136.216.3: 11:  [preauth]
Mar 31 12:04:41 debian authpriv.notice sshd[26533]: PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=183.136.216.3  user=root
Mar 31 12:04:47 debian authpriv.notice sshd[26565]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=183.136.216.3  user=root
Mar 31 12:04:49 debian auth.info sshd[26565]: Failed password for root from 183.136.216.3 port 55608 ssh2
Mar 31 12:04:52 debian auth.info sshd[26565]: Failed password for root from 183.136.216.3 port 55608 ssh2
Mar 31 12:04:57 debian auth.info sshd[26565]: Failed password for root from 183.136.216.3 port 55608 ssh2
Mar 31 12:04:57 debian auth.info sshd[26565]: Received disconnect from 183.136.216.3: 11:  [preauth]
Mar 31 12:04:57 debian authpriv.notice sshd[26565]: PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=183.136.216.3  user=root
Mar 31 12:05:05 debian authpriv.notice sshd[26594]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=183.136.216.3  user=root
Mar 31 12:05:07 debian auth.info sshd[26594]: Failed password for root from 183.136.216.3 port 53447 ssh2
Mar 31 12:05:09 debian auth.info sshd[26594]: Failed password for root from 183.136.216.3 port 53447 ssh2
Mar 31 12:05:12 debian auth.info sshd[26594]: Failed password for root from 183.136.216.3 port 53447 ssh2
Mar 31 12:05:12 debian user.warn kernel: [165869.765757] SSHbrute IN=eth0 OUT= MAC=00:..:..:..:..:ce:00:..:..:..:..:..:08:00 SRC=183.136.216.3 DST=192.168.2.94 LEN=60 TOS=0x00 PREC=0x00 TTL=50 ID=42814 DF PROTO=TCP SPT=44322 DPT=22 WINDOW=29200 RES=0x00 SYN URGP=0 
Mar 31 12:05:12 debian auth.info sshd[26594]: Received disconnect from 183.136.216.3: 11:  [preauth]
Mar 31 12:05:12 debian authpriv.notice sshd[26594]: PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=183.136.216.3  user=root
Mar 31 12:05:25 debian auth.info sshd[26617]: Received disconnect from 183.136.216.3: 11:  [preauth]

watch -d -n 2 iptables -nvL is a nice way to highlight what happens, securities-trader style - after an uncomfortably short while it should look somewhat like this (or shouldn't actually, if only authorities went after the botnets and spammers (before they turn their tools to even more nefarious ends) at long last! But that's something to take up with your congresscritter, sooner rather than later...):

Every 2,0s: iptables -nvL                                                                                                                                 Tue Mar 31 15:32:46 2015

Chain INPUT (policy ACCEPT 9303 packets, 648K bytes)
 pkts bytes target     prot opt in     out     source               destination
  309 20756 DROP       tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22 recent: UPDATE seconds: 7200 reap name: SSHbrute side: source
  138  8096            tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22 state NEW recent: SET name: SSHknown side: source
   16   960 SSHbrute   tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22 state NEW recent: UPDATE seconds: 15 hit_count: 2 name: SSHknown side: source

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 8401 packets, 3790K bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain SSHbrute (1 references)
 pkts bytes target     prot opt in     out     source               destination
   49  2940 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            recent: SET name: SSHbrute side: source LOG flags 0 level 4 prefix "SSHbrute "

Hope this helps and has been sufficiently exhaustive to adapt to each reader's every need... ;-)

Any improvements and suggested ports to the forthcoming nftables (in spite of its iptables backwards-compatible mode) are of course greatly appreciated.



Edited 10 time(s). Last edit at 03/31/2015 04:22PM by TEN.

> Limiting the number of password attempts per ssh logon to 2 (i.e. allow for 1 human typo) rather
> than 5 would also be helpful, if anyone knows where this should best be set.

It's set in /etc/ssh/sshd_config: "MaxAuthTries 2"

restamp Wrote:
> > Limiting the number of password attempts per ssh logon to 2 (i.e. allow for 1 human typo)
> > rather than 5 would also be helpful, if anyone knows where this should best be set.
>
> It's set in /etc/ssh/sshd_config: "MaxAuthTries 2"

Thanks, :) indeed, followed by service ssh restart, and it won't be long until after just 2 hack attempts per instance now:

Apr  1 11:08:01 debian auth.info sshd[4467]: Disconnecting: Too many authentication failures for root [preauth]

Curiously unlike the other options this wasn't on file even as a comment line, and seems to default to 3 while for some reason the logs suggest bots get more attempts (not sure how, even after setting max. 2):

Mar 31 12:04:57 debian authpriv.notice sshd[26565]: PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=183.136.216.3  user=root
Apr  1 14:33:33 debian authpriv.notice sshd[23017]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=183.136.216.6  user=root
Apr  1 14:33:35 debian auth.info sshd[23017]: Failed password for root from 183.136.216.6 port 46855 ssh2
Apr  1 14:33:38 debian auth.info sshd[23017]: Failed password for root from 183.136.216.6 port 46855 ssh2
Apr  1 14:33:38 debian auth.info sshd[23017]: Disconnecting: Too many authentication failures for root [preauth]
Apr  1 14:33:38 debian authpriv.notice sshd[23017]: PAM 1 more authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=183.136.216.6  user=root
Apr  1 14:33:39 debian user.warn kernel: [56751.659641] SSHbrute IN=eth0 OUT= MAC=00:..:..:..:..:ce:00:..:..:..:..:..:08:00 SRC=183.136.216.6 DST=192.168.2.94 LEN=60 TOS=0x00 PREC=0x00 TTL=50 ID=56397 DF PROTO=TCP SPT=52667 DPT=22 WINDOW=29200 RES=0x00 SYN URGP=0

I should also add that before intense work with scp etc. within the (W)LAN one can temporarily (or permanently if one trusts all systems potentially ever on it and can be sure that no NAT rewrites external requests to apparently originate from internal IPs) exempt one's own subnet (or rather than CIDR an individual external IP one is servicing from), e.g. in the above example:
iptables -I INPUT 1 -i eth0 -s 192.168.2.0/24 -j ACCEPT
iptables -D INPUT 1 to undo.

Conversely with similar syntax, though my rules keep them from cluttering your log for long (and it gets even better the less MaxAuthTries you give them as per restamp above), if according to /proc/net/xt_recent/SSHbrute "you've had it" with say certain Zhejiang Telecom customers from the initial (eek)sample you can blackhole them like:
iptables -I INPUT 1 -i eth0 -m iprange --src-range 115.230.0.0-115.239.255.255 -j DROP
iptables -I INPUT 2 -i eth0 -s 183.136.0.0/16 -j DROP
(the latter expanded from /17 to include several drones as above on the loose from neighbouring MoveInternet Network 183.136.216.0/24)
Tune to the occasion (optional): Enjoy the Silence, Depeche Mode 1989 ;)

Moreover, while nothing has been trying to (ab)use the default FORWARD policy of ACCEPT yet, if your ARM isn't a router you might want to change it to iptables -P FORWARD DROP (as a built-in chain it doesn't need a rule to a target).

Last but not least, to keep seeing every packet even after hours of watch, add -x to the invocation of iptables -L.



Edited 6 time(s). Last edit at 04/01/2015 08:12AM by TEN.

I find the denyhosts package more than adequate for dealing with ssh brute force abuse.

Quote
Frederick Grayson
I find the denyhosts package more than adequate for dealing with ssh brute force abuse.

Sure, quite a useful /etc/hosts.deny IPS approach (requiring Python which is no default either) like the aforementioned http://la-samhna.de/library/brutessh.html#4 - but besides sharing options like yours, the purpose of these posts has been to illustrate how to create customizable, slightly automated defenses & reporting at very minimal resource usage (<1% CPU, and keeping logs short) with simple rules (adjustable even from a cellphone if need be, also when ports & services other than ssh's 22 are affected) for the in-kernel netfilter.

Examples & explanations have been collated for reference & inspiration, but it all boils down to 5 lines of code (cf. TL;DR).



Edited 4 time(s). Last edit at 04/01/2015 09:22AM by TEN.

TEN,

It is difficult to find the right thread because you're not registered so I post here.

I just want to mention this issue about the front USB port on the Pogo E02 or Pogo V3 that people have reported about power problem and crashes. It did happen to me now when I tried to plug in the USB power for an eSATA enclosure :) and the HDD inside this enclosure is a 2.5" HDD. So it is true, I can confirm it first hand. But if you connect it before it's booting then it is OK. So I think some regulator is at fault here.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

bodhi Wrote:
> TEN, It is difficult to find the right thread because you're not registered

Actually I have been for a few weeks now, but it's probably the Reliability thread you're referring to where I'd mentioned this some days after getting myself an account at last: http://forum.doozan.com/read.php?8,20700,20714#msg-20714

> this issue about the front USB port on the Pogo E02 or Pogo V3 that people
> have reported about power problem and crashes. It did happen to me now when I tried to plug in the
> USB power for an eSATA enclosure :) and the HDD inside this enclosure is a 2.5" HDD. So it is
> true, I can confirm it first hand. But if you connect it before it's booting then it is OK.
> So I think some regulator is at fault here.

Given the price tag, probably we won't want to take them to court over this... just yet. ;)

BTW something nasty out of a new HK netblock has been hammering my machines in several locations for the past few days (auto-blacklisted nicely by the above approach).
To stop attacks from the address below through 43.255.191.255 entirely simply add:
iptables -I INPUT 1 -i eth0 -s 43.255.190.0/23 -j DROP

P.S.: Identified by threat report http://blogs.cisco.com/security/talos/sshpsychos:

Quote

Talos and Level 3 started the process to take down... Level 3 worked to notify the appropriate providers regarding the change. On March 30th SSHPsychos suddenly pivoted. The original /23 network went from a huge volume of SSH brute force attempts to almost no activity and a new /23 network began large amounts of SSH brute forcing following the exact same behavior associated with SSHPsychos. The new network is 43.255.190.0/23 and its traffic was more than 99% SSH immediately after starting communication. The host serving the malware also changed

Edited 2 time(s). Last edit at 04/18/2015 08:21AM by TEN.

As the clock wouldn't get updated by default & lag minutes in weeks, I also added this line to /etc/crontab:

30 3	* * *   root	ntpdate ptbtime1.ptb.de

Change server if you're not in Central Europe of course.

I also turn off "the light" overnight (echo 0 > /sys/class/leds/status\:orange\:fault/brightness etc.) & back on in the morning:

55 3	* * *   root	sunwait wait rise 48N 11E;echo 255 > /sys/class/leds/status\:green\:health/brightness

Compiled from http://sourceforge.net/projects/sunwait4windows/ as in http://forum.doozan.com/read.php?2,21050,21084#msg-21084 for home automation, of which the LEDs are simple indicators.

Lately some bots seem to have been taught more patient timing, so I suggest doubling the time frame from 15 to 30 seconds to foil these:

Jan 2 22:13:58 debian sshd[10967]: Received disconnect from 116.31.116.18: 11: [preauth]
Jan 2 22:14:23 debian sshd[10969]: Received disconnect from 116.31.116.18: 11: [preauth]
Jan 2 22:14:48 debian sshd[10971]: Received disconnect from 116.31.116.18: 11: [preauth]
Jan 2 22:15:13 debian sshd[10974]: Received disconnect from 116.31.116.18: 11: [preauth]
...
Jan 2 22:38:23 debian sshd[11207]: Received disconnect from 116.31.116.18: 11: [preauth]
Jan 2 22:38:48 debian sshd[11211]: Received disconnect from 116.31.116.18: 11: [preauth]
Jan 2 22:38:52 debian sshd[11209]: Invalid user user from 91.224.161.88
...
Jan 2 22:39:14 debian sshd[11219]: Received disconnect from 116.31.116.18: 11: [preauth]
Jan 2 22:39:19 debian sshd[11214]: Invalid user user from 91.224.161.88

Note how 116.31.116.18 doesn't even try username&password combinations, so it's either running unreasonably frequent port scans or (more likely) some custom attack code (e.g. attempting to fuzz sshd).

Already an additional rule with a hitcount of 3 within 180 to 200 seconds might be needed for the most patient few of the bots.

Care must be taken to strike a reasonable balance though:
As their numbers and (very literally in the iptables) our lines of defense increase, so does the risk of locking out legitimate access from intermittent (e.g. mobile) connections.

Thanks TEN! good to know.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)