- What I did
Configure sshd to close all SSH connetions after 15 minutes of inactivity.
- How I did it
Set ClientAliveInterval to 900 (900 seconds = 15 minutes) and ClientAliveCountMax to 0
in /etc/ssh/sshd_config using augtool in build_debian.sh. In the process, I refactored the existing augtool command for sshd_config so as to add comments and empty lines to file for readability.
- How to verify it
Log into device via management port. Wait 15 minutes without sending a keystroke -- you should be automatically logged out.
2) Install debug tools in every debug docker image
3) Install available debug symbols in debug docker image
4) Provide additional host/docker mapping for host dirs /src & /debug
4.1) The one-image will have source code under /src
4.2) /debug is mapped as rw. User can put his core file there and use this dir to
collect debug session logs too.
5) Build debug image using debug dockers
6) Source code is archived into /src of debug image
7) The welcome banner is extended to display these additional facilities in debug image.
* [submodule] update sonic-linux-kernel (#2985)
* Fix many version strings
* Update minor version
* Update arista-drivers submodule (#9)
* Rebuild SDK on new kernel (#10)
- What I did
Currently when the system is under memory pressure, the OOM killer kicks in and kills a rogue process. Killing a rogue process can cause the device to be un-healthy leading to blackholing of the traffic.
To avoid this, configure the OOM to do a kernel panic which will cause the device to reboot and come back up healthy.
- How I did it
Added the sysctl variable panic_on_oom and set the value to 2.
Setting it to 2 will ensure OOM killer to always do a kernel panic.
- Add ebtables package, and install some filter rules:
1. ebtables -A FORWARD -d BGA -j DROP
2. ebtables -A FORWARD -p ARP -j DROP
Basically, we let the ARP packets in the VLAN being forwarded by the ASIC,
kernel gets a copy of these ARP packets and the forwarding from Kenerl gets
dropped. So there is always only one copy of ARP/response in the VLAN.
Signed-off-by: Ying Xie <ying.xie@microsoft.com>
When rebooting without the platform_reboot plugin, systemd takes a few
minutes to properly shutdown. It's blocking on some docker cleanup
operation.
As described by https://github.com/docker/for-linux/issues/421 there
is a race between docker.service and containerd.service.
docker needs containerd to properly stop the containers.
* [security kernel] Upgrade kernel from 4.9.110-3+deb9u2 to 4.9.110-3+deb9u6
short version: 4.9.0-7 to 4.9.0-8
See changelogs for security fixes:
https://tracker.debian.org/media/packages/l/linux/changelog-4.9.110-3deb9u6
Signed-off-by: Zhenggen Xu <zxu@linkedin.com>
* Update sonic-linux-kernel submodule after it was merged
Signed-off-by: Zhenggen Xu <zxu@linkedin.com>
* [baseimage] set default locale en_US.UTF-8
Signed-off-by: chenhu <chenhu@didichuxing.com>
* [baseimage]set default locale to en_US.UTF-8, clean all other unused
* [baseimage] update-locale after locale-gen
* correct update-locale command line
Signed-off-by: Guohan Lu <gulv@microsoft.com>
* [baseimage]: install picocom 3.1 in base image
Signed-off-by: Guohan Lu <gulv@microsoft.com>
* add picocom to stretch build
Signed-off-by: Guohan Lu <gulv@microsoft.com>
* fix slave.mk bug
Signed-off-by: Guohan Lu <gulv@microsoft.com>
stretch docker-engine in base image is not started by default
in the build process. Need to create empty /var/lib/docker
Signed-off-by: Guohan Lu <gulv@microsoft.com>
* Fix potential blackholing/looping traffic and refresh ipv6 neighbor to avoid CPU hit
In case ipv6 global addresses were configured on L3 interfaces and used for peering,
and routing protocol was using link-local addresses on the same interfaces as prefered nexthops,
the link-local addresses could be aged out after a while due to no activities towards the link-local
addresses themselves. And when we receive new routes with the link-local nexthops, SONiC won't insert
them to the HW, and thus cause looping or blackholing traffic.
Global ipv6 addresses on L3 interfaces between switches are refreshed by BGP keeplive and other messages.
On server facing side, traffic may hit fowarding plane only, and no refresh for the ipv6 neighbor entries regularly.
This could age-out the linux kernel ipv6 neighbor entries, and HW neighbor table entries could be removed,
and thus traffic going to those neighbors would hit CPU, and cause traffic drop and temperary CPU high load.
Also, if link-local addresses were not learned, we may not get them at all later.
It is intended to fix all above issues.
Changes:
Add ndisc6 package in swss docker and use it for ipv6 ndp ping to update the neighbors' state on Vlan interfaces
Change the default ipv6 neighbor reachable timer to 30mins
Add periodical ipv6 multicast ping to ff02::11 to get/refresh link-local neighbor info.
* Fix review comments:
Add PORTCHANNEL_INTERFACE interface for ipv6 multicast ping
format issue
* Combine regular L3 interface and portchannel interface for looping
* Add ndisc6 package to vs docker
some platform drivers install blacklist.conf in /etc/modprobe.d.
Those configuration should be proprogated into initramfs to avoid
loading those blacklisted driver.
* [slave.mk]: Fix displaying username and password in build summary
We display contents of DEFAULT_USERNAME and DEFAULT_PASSWORD, while
image can be build with USERNAME and/or PASSWORD given on make(1)
command line. For example:
$ make USERNAME=adm PASSWORD=mypass target/sonic-broadcom.bin
Fix by displaying USERNAME and PASSWORD variables in build summary.
Signed-off-by: Sergey Popovich <sergey.popovich@ordnance.co>
* [baseimage]: Improve default user account handling
There are couple of issues with current implementation of default
user account management in baseimage:
1) It uses DES to encrypt accounts password. Furthermore this
effectively limits password length to 8 symbols, even if more
provided with PASSWORD or DEFAULT_PASSWORD from rules/config.
2) Salt value for password is same on all builds even with different
password increasing attack surface.
3) During the build process password passed as command line parameter
either as plain text (if given to make(1) as "make PASSWORD=...")
or DES encrypted (if given to build_debian.sh) can be seen by
non-build users using /proc/<pid>/cmdline file that has group and
world readable permissions.
Both 1) and 2) come from:
perl -e 'print crypt("$(PASSWORD)", "salt"),"\n"')"
that by defalt uses DES if salt does not have format $<id>$<salt>$,
where <id> is hashing function id. See crypt(3) for more details on
valid <id> values.
To address issues above we propose following changes:
1) Do not create password by hands (e.g. using perl snippet above):
put this job to chpasswd(8) which is aware about system wide
password hashing policy specified in /etc/login.defs with
ENCRYPT_METHOD (by default it is SHA512 for Debian 8).
2) Now chpasswd(8) will take care about proper salt value.
3) This has two steps:
3.1) For compatibility reasons accept USERNAME and PASSWORD as
make(1) parameters, but warn user that this is unsafe.
3.2) Use process environment to pass USERNAME and PASSWORD variables
from Makefile to build_debian.sh as more secure alternative to
passing via command line parameters: /proc/<pid>/environ
readable only by user running process or privileged users like
root.
Before change:
--------------
hash1
-----
# u='admin'
# p="$(LANG=C perl -e 'print crypt("YourPaSs", "salt"),"\n"')"
^^^^^^^^
8 symbols
# echo "$u:$p" | chpasswd -e
# getent shadow admin
admin:sazQDkwgZPfSk:17680:0:99999:7:::
^^^^^^^^^^^^^
Note the hash (DES encrypted password)
hash2
-----
# u='admin'
# p="$(LANG=C perl -e 'print crypt("YourPaSsWoRd", "salt"),"\n"')"
^^^^^^^^^^^^
12 symbols
# echo "$u:$p" | chpasswd -e
# getent shadow admin
admin:sazQDkwgZPfSk:17680:0:99999:7:::
^^^^^^^^^^^^^
Hash is the same as for "YourPaSs"
After change:
-------------
hash1
-----
# echo "admin:YourPaSs" | chpasswd
# getent shadow admin
admin:$6$1Nho1jHC$T8YwK58FYToXMFuetQta7/XouAAN2q1IzWC3bdIg86woAs6WuTg\
^^^^^^^^
Note salt here
ksLO3oyQInax/wNVq.N4de6dyWZDsCAvsZ1:17681:0:99999:7:::
hash2
-----
# echo "admin:YourPaSs" | chpasswd
# getent shadow admin
admin:$6$yKU5g7BO$kdT02Z1wHXhr1VCniKkZbLaMPZXK0WSSVGhSLGrNhsrsVxCJ.D9\
^^^^^^^^
Here salt completely different from case above
plFpd8ksGNpw/Vb92hvgYyCL2i5cfI8QEY/:17681:0:99999:7:::
Since salt is different hashes for same password different too.
hash1
-----
# LANG=C perl -e 'print crypt("YourPaSs", "\$6\$salt\$"),"\n"'
^^^^^
We want SHA512 hash
$6$salt$qkwPvXqUeGpexO1vatnIQFAreOTXs6rnDX.OI.Sz2rcy51JrO8dFc9aGv82bB\
yd2ELrIMJ.FQLNjgSD0nNha7/
hash2
-----
# LANG=C perl -e 'print crypt("YourPaSsWoRd", "\$6\$salt\$"),"\n"'
$6$salt$1JVndGzyy/dj7PaXo6hNcttlQoZe23ob8GWYWxVGEiGOlh6sofbaIvwl6Ho7N\
kYDI8zwRumRwga/A29nHm4mZ1
Now with same "salt" and $<id>$, and same 8 symbol prefix in password, but
different password length we have different hashes.
Signed-off-by: Sergey Popovich <sergey.popovich@ordnance.co>
* Support OS9 -> SONiC fast-reboot migration
* Address review comments. Update NOS mac in EEPROM and net.rules for eth0
* Address review comments. Update sonic-platform-modules-dell to fac81d...
* Fix script for POSIX compliance