Re: [OpenWrt-Devel] RFI: OpenWRT for #DisasterRelief: LoRA: ClusterDuck, LTE, 5G, Mesh, Throttling
Bump. On Wed, Apr 8, 2020 at 7:32 PM Wes Turner wrote: > A thread for discussing OpenWRT for #DisasterRelief: LoRA: ClusterDuck, > LTE, Mesh > > (cc'ing and re-formatting from > https://twitter.com/westurner/status/1238859774567026688 ) > > Please LMK if the forums are the appropriate place for these questions. > > ## Project OWL ClusterDuck > Homepage: http://clusterduckprotocol.org/ > GitHub: https://github.com/Code-and-Response/ClusterDuck-Protocol > > The Linux Foundation > Code and Response: > https://www.linuxfoundation.org/projects/code-and-response/ > GitHub: > https://github.com/code-and-response > > > Project OWL (Organization, Whereabouts, and Logistics) creates a mesh > network of Internet of Things (IoT) devices called DuckLinks. These > Wi-Fi-enabled devices can be deployed or activated in disaster areas to > quickly re-establish connectivity and improve communication between first > responders and civilians in need. > > > > In OWL, a central portal connects to solar- and battery-powered, > water-resistant DuckLinks. These create a Local Area Network (LAN). In > turn, these power up a Wi-Fi captive portal using low-frequency Long-range > Radio (LoRa) for Internet connectivity. LoRA has a greater range, about > 10km, than cellular networks. > > [...] > > You don't actually need a DuckLink device. The open-source OWL firmware > can quickly turn a cheap wireless device into a DuckLink using the -- I > swear I'm not making this up -- ClusterDuck Protocol. This is a mesh > network node, which can hook up to any other near-by Ducks. > > > > OWL is more than just hardware and firmware. It's also a cloud-based > analytic program. The OWL Data Management Software can be used to > facilitate organization, whereabouts, and logistics for disaster response. > > ## LoRa + OpenWRT: ClusterDuck, ChirpStack > A ClusterDuck opkg would make it possible to use WiFi/LTE routers with a > LoRa transmitter/receiver connected over e.g. USB or Mini-PCIe. > > Is there anything special that would need to be done to create an opkg for > ClusterDuck? > > > OpenWRT uses opkg packages: > https://openwrt.org/docs/guide-user/additional-software/opkg > > I searched for "Lora" in OpenWRT/packages: > > - lora-gateway-hal opkg package: > https://github.com/openwrt/packages/blob/master/net/lora-gateway-hal/Makefile > - lora-packet-forwarder opkg package (w/ UCI integration): > https://github.com/openwrt/packages/pull/8320 > - lora-feed: https://github.com/xueliu/lora-feed : > > > Semtech packages and ChirpStack [(LoRaserver)] Network Server stack > for OpenWRT > > ## Mesh architectures: ClusterDuck // B.A.T.M.A.N > How does ClusterDuck compare to BATMAN and other mesh routing approaches? > > Is there a reference implementation with WiFi, LTE, and LoRa and IDK link > prioritization? > > >> [In addition to providing node2node/2net connectivity, #batman-adv can > bridge VLANs over a mesh (or link), such as for “trusted” client, guest, > IoT, and mgmt networks. It provides an easy-to-configure alternative to > other approaches to “backhaul”, […]] > https://openwrt.org/docs/guide-user/network/wifi/mesh/batman > > ## LTE Routers, LTE Tethering > LTE is useful for disaster relief scenarios. > > Tethering an OpenWRT router to an LTE phone over WiFi/USB/Bluetooth is one > alternative to buying a router with an LTE modem, external LTE antennas, > and one or more SIM card slots. > > I have no affiliation with either of these manufacturers. I have a few > different [quad-core, MIMO] ARM devices without 4G. TIL about routers with > LTE modems in them (and cell providers that allow adding additional SIMs > that just draw from a shared bandwidth quota). > > > TIL that the @GLiNetWifi devices ship with OpenWRT firmware (and a > mobile config app) and some have 1-2 (Mini-PCIe) 4G LTE w/ SIM slots. > https://twitter.com/GLiNetWiFi > > > Also, @turris_cz has OpenWRT w/ LTE and LXC in the kernel build. > https://t.co/Rz0Uu5uHJQ > https://twitter.com/turris_cz > > Are there other [OpenWRT-compatible] devices with LTE and/or LoRa that > would be useful for disaster relief? > > "Table of Hardware: LTE Modem supported" > https://openwrt.org/toh/views/toh_lte_modem_supported > > ## 5G > Are there any 5G-compatible OpenWRT devices yet? > Presumably, devices with Mini-PCIe are theoretically compatible given > built modules. > > ## Throttling > In a disaster relief scenario, burning through the limited available > bandwidth for certain media-heavy sites can be problematic. > > Is there a recommended way to e.g. throttle / traffic shape individual > clients so that no one user can exhaust the bandwidth resources? AFAIU, SQM > can be configured for individual VLANs, but that would require an SSID per > user? > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] How am I supposed to change settings in /etc/config/network of default root file system of OpenWRT?
Would it make sense to integrate support for a wwan interface and zone that just no-ops when there's no wwan interface defined? The case of a 4G/5G modem will likely be more popular in the future. "[OpenWrt-Devel] RFI: OpenWRT for #DisasterRelief: LoRA: ClusterDuck, LTE, 5G, Mesh, Throttling" https://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg52055.html > Are there other [OpenWRT-compatible] devices with LTE and/or LoRa that > would be useful for disaster relief? > > "Table of Hardware: LTE Modem supported" > https://openwrt.org/toh/views/toh_lte_modem_supported > > ## 5G > Are there any 5G-compatible OpenWRT devices yet? > Presumably, devices with Mini-PCIe are theoretically compatible given built modules. How would you name interfaces / zones when there's also at least one LoRA interface? wan wwan wan0 wwan0 lora0 (?) On Wed, May 20, 2020 at 8:12 PM Jeonghum Joh wrote: > Hello Magnus Kroken, > > Thank you for clarifying the license. > I will use this one in the github gist. > > Thank you so much! > Jeonghum > > 2020년 5월 21일 (목) 오전 2:13, Magnus Kroken 님이 작성: > >> Hi >> >> On 20.05.2020 02:01, Jeonghum Joh wrote: >> > Hello Magnus Kroken, >> > >> > Thank you so much! >> > Your script works like a charm! >> > >> > I'd like to use this script in our board. This board would be our >> > customer's new product - 5G router. >> > We are Telesquare Inc. (www.telesquare.co.kr < >> http://www.telesquare.co.kr>) >> > >> > I'd like to write copyright to your name. >> > And I'd like you to clarify the license of this script. >> > >> > Please let me know your opinion. >> > >> > Thank you very much! >> > Jeonghum >> >> Appreciate the consideration, although I'm not sure this snippet is >> substantial enough to be copyrightable. No matter I suppose - if it is >> copyrightable I can license it, if it is too simple to be copyrightable >> any claim of copyright is invalid and it can safely be used by anyone. >> >> I have put a slightly clarified version as a Gist: >> https://gist.github.com/mkrkn/4ba4bef3f0d541aa1180bef4156b340c >> >> Regards >> Magnus Kroken >> > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Ubus based service watchdog?
FWIW, k8s has Liveness, Readiness and Startup Probes https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/ :: > The kubelet uses startup probes to know when a container application has started. If such a probe is configured, it disables liveness and readiness checks until it succeeds, making sure those probes don’t interfere with the application startup. This can be used to adopt liveness checks on slow starting containers, avoiding them getting killed by the kubelet before they are up and running. On Thu, May 14, 2020, 1:01 PM Jo-Philipp Wich wrote: > Hi, > > I like the ubus watchdog ping/pong idea. > > ~ Jo > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Possible security issue
Maybe it should be something like:
```bash
groupadd ubus
for user in "root ..."; do
usermod -a -G ubus "${user}"
done
chgrp ubus /sbin/uci /var/run/ubus.sock
chmod g+rw /var/run/ubus.sock
chmod g+rwx /sbin/uci
chmod o-rwx /sbin/uci /var/run/ubus.sock
```
What would this break?
https://openwrt.org/docs/techref/ubus
...
Better sandboxing in procd than chroot could be an objective. IDK where the
previous discussions are?
https://openwrt.org/docs/techref/procd
cgroups without systemd:
https://wiki.archlinux.org/index.php/cgroups#With_libcgroup
Notes re: SELinux (and containers)
https://github.com/rancher/k3s/issues/1372#issuecomment-581797716
https://blog.openshift.com/securing-kubernetes/
>
> The main thing to understand about SELinux integration with OpenShift
>> is that, by default, OpenShift runs each container as a random uid and is
>> isolated with SELinux MCS labels. The easiest way of thinking about MCS
>> labels is they are a dynamic way of getting SELinux separation without
>> having to create policy files and run restorecon.
>>
>> If you are wondering why we need SELinux and namespaces at the same
>> time, the way I view it is namespaces provide the nice abstraction but are
>> not designed from a security first perspective. SELinux is the brick wall
>> that’s going to stop you if you manage to break out of (accidentally or on
>> purpose) from the namespace abstraction.
>>
>> CGroups is the remaining piece of the puzzle. Its primary purpose
>> isn’t security, but I list it because it regulates that different
>> containers stay within their allotted space for compute resources (cpu,
>> memory, I/O). So without cgroups, you can’t be confident your application
>> won’t be stomped on by another application on the same node.
>>
>
Everybody's doing it:
https://en.wikipedia.org/wiki/Seccomp#Software_using_seccomp_or_seccomp-bpf
On Sat, Apr 18, 2020 at 10:22 PM Joel Wirāmu Pauling
wrote:
> I'm sorry for wading into this. As with any security related discussion
> strawpeople can be made to support any particular thread pulling into
> infinity.
>
> Would I love to see namespaces used as part of the base Openwrt
> architecture; absolutely. It's been discussed in the past; routing in
> particular would benefit immensely from this ; use of different routing
> table ID's is a step towards that, but complications like passing device
> id's in and out of namespaces however for the switch side of things is
> problematic and adds additional overhead as will it introduce issues at the
> expense of separation and flexibility.
>
> That potentially could mitigate some of your concerns, but I feel the
> preposition for me is openwrt is not multi-user by default OOTB for most
> (if not all) targets; and if you want it to be you can.
>
> So fiddling inode bitmasks is not addressing anything IMNSHO because of
> that fact.
>
>
>
>
>
>
> On Sat, 18 Apr 2020 at 00:50, Wes Turner wrote:
>
>> From a least privileges perspective:
>>
>> - chmod o-rwx /var/run/hostapd-phyX.conf
>> - chmod o-x uci # setfacl?
>>
>> Compromise of a service running as a different user should not result in
>> disclosure of sensitive keys only necessary for different services.
>>
>> https://openwrt.org/docs/guide-user/security/security-features mentions
>> procd jail / chroot?
>>
>> AFAIU, LXC is not available in the default kernel builds in any router?
>> LXC would be an additional layer of defenses over and above chroot, which
>> isn't seccomp
>>
>> On Fri, Apr 17, 2020, 5:13 AM Joel Wirāmu Pauling
>> wrote:
>>
>>> No. If you have physical access to the node and/or a valid login as
>>> Admin then any form of PSK is vulnerable.
>>>
>>> If you are concerned about PSK's being exposed then you have the option
>>> to run 802.1x auth and issue issues tokens out of radius/IDM that is
>>> secured elsewhere than on the AP itself.
>>>
>>> On Fri, 17 Apr 2020 at 20:16, e9hack wrote:
>>>
>>>> Hi,
>>>>
>>>> the configuration files for hostapd (/var/run/hostapd-phyX.conf) are
>>>> readable for everyone. This means everyone can read the wifi passwords. If
>>>> a non privileged user calls 'uci show wireless', he will also get all wifi
>>>> passwords. This possible e.g. for user nobody and dnsmasq.
>>>>
>>>> Is this a a security issue?
>>>>
>>>> Regards,
>>>> Hartmut
>>>>
>>>> ___
>>>> openwrt-devel mailing list
>>>> openwrt-devel@lists.openwrt.org
>>>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>>>>
>>> ___
>>> openwrt-devel mailing list
>>> openwrt-devel@lists.openwrt.org
>>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>>>
>>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Possible security issue
>From a least privileges perspective: - chmod o-rwx /var/run/hostapd-phyX.conf - chmod o-x uci # setfacl? Compromise of a service running as a different user should not result in disclosure of sensitive keys only necessary for different services. https://openwrt.org/docs/guide-user/security/security-features mentions procd jail / chroot? AFAIU, LXC is not available in the default kernel builds in any router? LXC would be an additional layer of defenses over and above chroot, which isn't seccomp On Fri, Apr 17, 2020, 5:13 AM Joel Wirāmu Pauling wrote: > No. If you have physical access to the node and/or a valid login as Admin > then any form of PSK is vulnerable. > > If you are concerned about PSK's being exposed then you have the option to > run 802.1x auth and issue issues tokens out of radius/IDM that is secured > elsewhere than on the AP itself. > > On Fri, 17 Apr 2020 at 20:16, e9hack wrote: > >> Hi, >> >> the configuration files for hostapd (/var/run/hostapd-phyX.conf) are >> readable for everyone. This means everyone can read the wifi passwords. If >> a non privileged user calls 'uci show wireless', he will also get all wifi >> passwords. This possible e.g. for user nobody and dnsmasq. >> >> Is this a a security issue? >> >> Regards, >> Hartmut >> >> ___ >> openwrt-devel mailing list >> openwrt-devel@lists.openwrt.org >> https://lists.openwrt.org/mailman/listinfo/openwrt-devel >> > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] RFI: OpenWRT for #DisasterRelief: LoRA: ClusterDuck, LTE, 5G, Mesh, Throttling
A thread for discussing OpenWRT for #DisasterRelief: LoRA: ClusterDuck, LTE, Mesh (cc'ing and re-formatting from https://twitter.com/westurner/status/1238859774567026688 ) Please LMK if the forums are the appropriate place for these questions. ## Project OWL ClusterDuck Homepage: http://clusterduckprotocol.org/ GitHub: https://github.com/Code-and-Response/ClusterDuck-Protocol The Linux Foundation > Code and Response: https://www.linuxfoundation.org/projects/code-and-response/ GitHub: https://github.com/code-and-response > Project OWL (Organization, Whereabouts, and Logistics) creates a mesh network of Internet of Things (IoT) devices called DuckLinks. These Wi-Fi-enabled devices can be deployed or activated in disaster areas to quickly re-establish connectivity and improve communication between first responders and civilians in need. > > In OWL, a central portal connects to solar- and battery-powered, water-resistant DuckLinks. These create a Local Area Network (LAN). In turn, these power up a Wi-Fi captive portal using low-frequency Long-range Radio (LoRa) for Internet connectivity. LoRA has a greater range, about 10km, than cellular networks. > [...] > You don't actually need a DuckLink device. The open-source OWL firmware can quickly turn a cheap wireless device into a DuckLink using the -- I swear I'm not making this up -- ClusterDuck Protocol. This is a mesh network node, which can hook up to any other near-by Ducks. > > OWL is more than just hardware and firmware. It's also a cloud-based analytic program. The OWL Data Management Software can be used to facilitate organization, whereabouts, and logistics for disaster response. ## LoRa + OpenWRT: ClusterDuck, ChirpStack A ClusterDuck opkg would make it possible to use WiFi/LTE routers with a LoRa transmitter/receiver connected over e.g. USB or Mini-PCIe. Is there anything special that would need to be done to create an opkg for ClusterDuck? > OpenWRT uses opkg packages: https://openwrt.org/docs/guide-user/additional-software/opkg I searched for "Lora" in OpenWRT/packages: - lora-gateway-hal opkg package: https://github.com/openwrt/packages/blob/master/net/lora-gateway-hal/Makefile - lora-packet-forwarder opkg package (w/ UCI integration): https://github.com/openwrt/packages/pull/8320 - lora-feed: https://github.com/xueliu/lora-feed : > Semtech packages and ChirpStack [(LoRaserver)] Network Server stack for OpenWRT ## Mesh architectures: ClusterDuck // B.A.T.M.A.N How does ClusterDuck compare to BATMAN and other mesh routing approaches? Is there a reference implementation with WiFi, LTE, and LoRa and IDK link prioritization? >> [In addition to providing node2node/2net connectivity, #batman-adv can bridge VLANs over a mesh (or link), such as for “trusted” client, guest, IoT, and mgmt networks. It provides an easy-to-configure alternative to other approaches to “backhaul”, […]] https://openwrt.org/docs/guide-user/network/wifi/mesh/batman ## LTE Routers, LTE Tethering LTE is useful for disaster relief scenarios. Tethering an OpenWRT router to an LTE phone over WiFi/USB/Bluetooth is one alternative to buying a router with an LTE modem, external LTE antennas, and one or more SIM card slots. I have no affiliation with either of these manufacturers. I have a few different [quad-core, MIMO] ARM devices without 4G. TIL about routers with LTE modems in them (and cell providers that allow adding additional SIMs that just draw from a shared bandwidth quota). > TIL that the @GLiNetWifi devices ship with OpenWRT firmware (and a mobile config app) and some have 1-2 (Mini-PCIe) 4G LTE w/ SIM slots. https://twitter.com/GLiNetWiFi > Also, @turris_cz has OpenWRT w/ LTE and LXC in the kernel build. https://t.co/Rz0Uu5uHJQ https://twitter.com/turris_cz Are there other [OpenWRT-compatible] devices with LTE and/or LoRa that would be useful for disaster relief? "Table of Hardware: LTE Modem supported" https://openwrt.org/toh/views/toh_lte_modem_supported ## 5G Are there any 5G-compatible OpenWRT devices yet? Presumably, devices with Mini-PCIe are theoretically compatible given built modules. ## Throttling In a disaster relief scenario, burning through the limited available bandwidth for certain media-heavy sites can be problematic. Is there a recommended way to e.g. throttle / traffic shape individual clients so that no one user can exhaust the bandwidth resources? AFAIU, SQM can be configured for individual VLANs, but that would require an SSID per user? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Configuration management for OpenWrt
/etc in git + Shell script + Ansible
I wrote a shell script that drops lock files in /etc/setup when that
function has successfully run without error.
If the lock file exists (test -f "/etc/setup/${lockname}"), the function
doesn't run again whenever I re-run the shell script.
I include /etc/setup/ and /etc/bin/ in /etc/sysupgrade.conf.
I haven't yet hooked post-upgrade somehow so that the setup shell script
runs automatically after upgrading OpenWRT firmware.
I could probably check /etc/openwrt_release and /etc/openwrt_version to
determine whether the version has changed.
https://openwrt.org/docs/techref/sysupgrade
https://github.com/gekmihesg/ansible-openwrt
> Manage OpenWRT and derivatives with Ansible but without Python
This runs an OpenWRT docker container with an interactive shell that IDK
how to kill without killing the PID or various incantations of
Ctrl-C/Ctrl-D/Ctrl-Z:
docker image pull openwrtorg/rootfs
docker run --rm -it --name=openwrt1 -h hostname --cap-add NET_ADMIN -v
$(readlink -e ./setup_openwrt.sh):/setup_openwrt.sh:ro -v $(readlink -e
./entrypoint.sh):/entrypoint.sh:ro openwrtorg/rootfs
On Wed, Apr 8, 2020 at 5:08 PM Paul Spooren wrote:
> Hi all,
>
> I was wondering if there are some best practices for configuration
> management of OpenWrt devices. I understand that it is fairly easy to
> get/restore a backup of the etc/config folder, but though maybe there
> are some smarter ways.
>
> Ideally a local state (e.g. git repository) would deploy multiple
> devices and automatically update them via a command (or even cron).
>
> Other projects came up with solutions which seem to heavy for common
> WiFi routers. Ansible[0] is great and all, however requires plenty of
> Python to work conveniently. Then cloud-init[1] is Python as well, I
> think even heavier on the client side than Ansible and also doesn't
> seem to be the right use case.
>
> Some time ago I came up with a MAC based init system[2] but that's not
> really to keep things up to date.
>
> Last thing I know of is the approach to convert folders into opkg
> install-able packages[3], so whenever there is a new configuration all
> pre-configured routers would install it via opkg. However this would
> require an opkg cron on client device and building the config-packages
> appear to be quite some overhead. On the other side it handles
> authentication via usign keys.
>
> Anyway, please recommend me a better way which I'm not aware of!
>
> Best,
> Paul
>
> [0]: https://www.ansible.com/
> [1]: https://cloud-init.io/
> [2]: https://github.com/openwrt/packages/pull/6071
> [3]: https://github.com/libremesh/network-profiles-builder
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/1] netifd: add pre-up/down post-up/down callback handling
What is the reason that creating a script in /etc/hotplug.d/iface/ that checks $ACTION and $DEVICENAME doesn't solve for this use case? https://openwrt.org/docs/guide-user/base-system/hotplug On Fri, Mar 20, 2020, 11:02 AM Felix Fietkau wrote: > On 2020-03-20 15:21, Florian Eckert wrote: > > network > >>> With this change we can decide if this is a user interaction with > >>> CLI/LuCI, > >>> because with the new callback mechanism I can set/delete a uci config > >>> flag so > >>> that the connection should really disconnected. And so does not > >>> restart on a > >>> failed connetion tracking again because the uci config flag is not > >>> set. > >>> > >>> Signed-off-by: Florian Eckert > >> netifd already tracks for every interface if the user requested it to > >> be > >> enabled or not via the 'autostart' flag, which you can query via ubus. > > > > I know this is done wit the uci option auto for this interface. > > But if I disable this flag, then on the next boot this interface does > > not start > > on boot anymore. I have to start this manual. So I think this is not an > > option. > No, I'm talking about the internal per-interface 'autostart' variable, > which gets set to false if the user does a manual ifdown of an interface > (but not if it just failed to start up). > It's not backed by configuration and you can query it via ubus. > (e.g. ifstatus wan) > > - Felix > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH uhttpd] client: allow keep-alive for POST requests
On Fri, Mar 13, 2020, 12:39 PM Jo-Philipp Wich wrote: > Hi Wes, > > > Are there *new* security implications of allowing keep-alive? > > I don't see any immediate concerns. You can trigger resource intensive > calls > via GET, HEAD, PATCH, PUT or DELETE as well, all of them were allowed for > keep-alive previously, only POST was filtered for unknown reasons. > > > Slowloris DoS comes to mind: > > https://en.wikipedia.org/wiki/Slowloris_(computer_security) > > The DoS susceptibility should be same with or without this patch. > > > Older devices are likely somewhat trivially DoS-able without this patch; > but > > maybe include a config option to disable keep-alive? > > Disabling keep-alive has always been supported, either use > uci set uhttpd.main.http_keepalive=0 or alternatively uhttpd -k 0 > Thanks > > What happens to RAM and CPU usage when there are multiple tabs open with > > keep-alive on? > > Testing with 6 open browser tabs, all refreshing the main status page: > > With POST keep-alive:uhttpd VSZ 4316K, CPU 5% usr, 6% sys > Without POST keep-alive: uhttpd VSZ 4756K, CPU 11% usr, 8% sys > > Thats not a scientific benchmark though. In general you trade CPU (TLS > setup, > TCP connects) for memory (resident established connections). > > In case of non-malicious clients (like normal browser tabs background > refreshing data) the memory resource consumption seems to be even lower > because there's less active TLS sessions at every point in time. And > almost no > TLS connection attempts once all requires sessions are established. > That sounds ideal. Is this with or without the "[OpenWrt-Devel] [PATCH ustream-ssl] ustream-openssl: clear error stack before SSL_read/SSL_write" patch? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH uhttpd] client: allow keep-alive for POST requests
Are there *new* security implications of allowing keep-alive? Slowloris DoS comes to mind: https://en.wikipedia.org/wiki/Slowloris_(computer_security) And the article mentions a number of tools. Older devices are likely somewhat trivially DoS-able without this patch; but maybe include a config option to disable keep-alive? What happens to RAM and CPU usage when there are multiple tabs open with keep-alive on? On Fri, Mar 13, 2020, 8:20 AM Jo-Philipp Wich wrote: > Allow POST requests via persistent connections to improve performance > especially when using HTTPS on older devices. > > After this change, average page load times in LuCI improve significantly > once the TLS connections are initiated. > > When testing an ar71xx 19.07.2 build on an ethernet connected TL-WR1043nd > using luci-ssl-openssl and the ustream-openssl backend, the average page > load time for the main status page decreased to 1.3s compared to 4.7s > before, the interface and wireless configuration pages loaded in 1.2s > seconds each compared to the 4.2s and 4.9s respectively before. > > Signed-off-by: Jo-Philipp Wich > --- > client.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/client.c b/client.c > index 92f7609..2a2393f 100644 > --- a/client.c > +++ b/client.c > @@ -194,8 +194,7 @@ static int client_parse_request(struct client *cl, > char *data) > > req->method = h_method; > req->version = h_version; > - if (req->version < UH_HTTP_VER_1_1 || req->method == > UH_HTTP_MSG_POST || > - !conf.http_keepalive) > + if (req->version < UH_HTTP_VER_1_1 || !conf.http_keepalive) > req->connection_close = true; > > return CLIENT_STATE_HEADER; > -- > 2.25.1 > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] RFI: OpenWRT Upgrade System; ENH,SEC suggestions
Thanks for clarifying.
How can a user add a usign EdDSA ed25519 key for e.g. a self-hosted package
set?
https://openwrt.org/docs/guide-user/security/release_signatures links to
https://openwrt.org/docs/guide-user/security/keygen which describes how to
generate release signing keys with GPG and usign.
https://git.openwrt.org/project/usign.git
I would imagine that a firmware update check script would download a signed
JSON file; possibly with an ed25519 ld-signatures signature within the
record. You just just pop the proof key from the JSON before
[canonicalizing/sorting keys and] checking the hash and signature.
https://w3c-dvcg.github.io/ld-signatures/
It could just parse
https://downloads.openwrt.org/releases/ , but would that require semver to
sort and identify release candidates.
Ideally, it would link directly to the latest firmware download URLs for
the given target architecture.
YAML-LD that may be over-normalized:
releases:
- version:
security_release:
archs:
- architecture: x86
models:
- name: model105
sysupgrade_url:
firmware_url:
proof:
type: Ed25519Signature2018
proofPurpose: assertionMethod
created: "2019-08-23T20:21:34Z"
verificationMethod: "did:example:123456#key1"
domain: "example.org"
jws: "eyJ0eXAiOiJK...gFWFOEjXk"
It could be run as a periodic cron task that logs to syslog and caches to
/tmp for display with LuCI.
Config options:
updater.enabled: bool (True/False?)
updater.time_between_checks: cron ("24h"?)
updater.notify_webhook: URL ("")
updater.notify_email: email address ("")
updater.consider_nightlies: bool
IDK how much trouble it would be to generate such (ed25519 ld-signatures
JSON-LD) release manifests as a new step in the release workflow? Or how to
return target-specific firmware URLs for the LuCI notification.
People that are already considering testing nightlies may not be as likely
to be as out of date as folks with regular releases installed.
Thanks again for clarifying that there are ed25519 package signing public
keys baked into the firmware releases.
On Sat, Feb 1, 2020, 12:25 PM Jo-Philipp Wich wrote:
> Hi Wes,
>
> > It's definitely an issue that the sha256 checksum check was broken.
> > But, can someone explain why a person who is MITM'ing ipk downloads
> > would change the package and not the checksum?
>
> the repository index files containing the SHA256 checksums are signed using
> usign, which is a derivate of the ECDSA based OpenBSD signify utility. The
> public ECDSA key is built into the firmware image and used to check the
> signify-signed repository index. Forging the index itself is not possible
> without possession of the secret key.
>
> > Are there GPG signatures of the package checksums signed with a key
> > that ships with the release?
>
> There are usign (signify) ECDSA ones.
>
> > Are package repos downloaded over HTTPS? Is there a CA bundle in the
> > release with which repo x.509 certs are validated?
>
> No since so far the required storage footprint for a functional SSL stack
> (library plus certs etc.) exceeded the available space on a large fraction
> of
> supported models.
>
> > The OpenWRT firmware couldn't access https sites without installing
> > multiple packages first. Then they had me install all the root certs
> > over an unencrypted connection. The opkg repos and install files are
> > all downloaded over http.
>
> Yes but they are (assuming fixed SHA256 issue) verified using preshared EC
> keys.
>
> 1) opkg downloads Packages.gz and Packages.sig, if either of these fail,
>the repo is ignored
> 2) opkg verifies that the uncompressed contents of Packages.gz match the
>Packages.sig signature using EC keys built into the image, if the
> signature
>cannot be verified, the downloaded lists are deleted and the repo is
>ignored
> 3) opkg translates package names to actual file names using the verified
>package index information and downloads these .ipk files
> 4) opkg verifies that the size of the downloaded .ipk files match the size
>mentioned in the verified package index information, if not the
> downloaded
>package is deleted and the installation aborted
> 5) opkg computes the sha256 sums of the downloaded .ipk files and verifies
>that they match the ones specified in the verified package index
>information, if not the downloaded package is deleted and the
> installation
>aborted [this step has been fixed]
> 6) opkg unpacks and installs the .ipk
>
> > With full seriousness, I really hope nobody expects operational
> > security using these routers.
>
> Depends on the thread model of course but without an encrypted transport
> channel, there'll be no confidentiality about the packages being installed,
> but [assuming a fixed opkg] it is not possible to modify the contents
> in-flight.
>
> > Side note: something like these would be great to have; IDK which
> > repos are appropriate for possible new issues to be owned by
[OpenWrt-Devel] RFI: OpenWRT Upgrade System; ENH,SEC suggestions
Saw this post and thought I'd forward it along here. https://news.ycombinator.com/item?id=22208557 """ It's definitely an issue that the sha256 checksum check was broken. But, can someone explain why a person who is MITM'ing ipk downloads would change the package and not the checksum? Are there GPG signatures of the package checksums signed with a key that ships with the release? Are package repos downloaded over HTTPS? Is there a CA bundle in the release with which repo x.509 certs are validated? """ """ I installed newest version OpenWRT on a popular brand, recently manufactured wireless router last week. The OpenWRT firmware couldn't access https sites without installing multiple packages first. Then they had me install all the root certs over an unencrypted connection. The opkg repos and install files are all downloaded over http. With full seriousness, I really hope nobody expects operational security using these routers. """ There's likely some misunderstanding here. Is there a wiki page or similar describing how package repo catalogs, packages, and firmware image updates are built, checksummed, signed, distributed, and signed-checksum-checked? - https://en.wikipedia.org/wiki/The_Update_Framework_(TUF) is a great read. - https://theupdateframework.io/ - https://github.com/theupdateframework/specification/blob/master/tuf-spec.md re: "Thandy" - "PEP 458 -- Secure PyPI downloads with package signing" https://www.python.org/dev/peps/pep-0480/ - "PEP 480 -- Surviving a Compromise of PyPI: The Maximum Security Model" https://www.python.org/dev/peps/pep-0458/ Side note: something like these would be great to have; IDK which repos are appropriate for possible new issues to be owned by someone who knows what is going on: ENH: CDN for package repos and latest version file ENH,SEC: firmware update check script ENH,SEC: send an email when the firmware is out of date ENH,SEC: luci: display firmware update check result and link to latest firmware ENH,SEC: add package repo (and firmware?) signing key to keyring ENH,SEC: include ca-certificates and/or openwrt-certificates in builds? Thought I'd forward this along, It seemed deserving of review for something with time to review ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
