How to disable logs

Hello.

I am building private repeater (on RPI4 base) and i am trying not to record even most harmless data.

Can someone help me, how to disable all logging?

for every log line find the source and minimize log level? come back with what is still left?

I suppose you could try /etc/init.d/log disable. I don't know about long-term implications, though, and naturally this does not disable the kernel log (dmesg).

Out of curiosity, what is your attack vector? To read the logfiles one would have access to the device, for OpenWrt that inherently implies root access, at which point anything and everything is compromised and compromisable. If it's any consolation, OpenWrt keeps logfiles (both syslog and kernel log) only in memory, noone can just grab your device and run and look at the logfiles later.

5 Likes

I'm also curious about the attack vector and the intent behind:

What is the definition of said data? For example, if the goal is to ensure that logging is not happening for a client device's traffic destination or type, that's not captured by default anyway.

However, if the intent here is to prevent even the logging of let's say a wifi association or even boot logs of the device itself, it starts to get a bit harder insofar as most processes will log these activities so that you can actually see that the OpenWrt device itself is actually working and/or troubleshoot if issues arise.

Another thing to consider is that the logs are all stored in RAM. Nothing is persistent unless you actively change the logging behavior to write to a non-volatile storage media. Therefore, logs are limited in the 'scrollback' (only a small amount of RAM is allocated for logs; when that space fills up, old entries are flushed as new entries come in). Pull the power or reboot the device and all the logs go poof.

My goal to create paranoid mode device. For now it is like in development. But i wanna start making custom builds for public with security and privacy pushed far more than just "rational"

So yeah, it is not about "why". I just experimenting and trying what i can harmlessly strip/disable to know on what i want to work for builds.

P.S: i didn't publish anything yet (and will not anytime soon, i want to make really good quality builds, so i am just learning now)

I think that there is a point at which the value of a 'paranoid mode' operating mode becomes severely diminished if you can't even tell if it is working properly and, critically, if not, what is wrong. For example, let's use a simple but practical example of DHCP... if you remove all of the logging of DHCP and then for some reason you're not getting a DHCP address on your client device, how would you know if the DHCP server was even participating in the DORA process and/or where things are broken?

Beyond that, it is a good idea to really think through what the threat model is. By completely (or nearly so) preventing logging on this device, what is gained in terms of privacy/security? Keep in mind that the upstream network(s)/servers/services and even the downstream clients may still have logs or insight that you can't easily defeat or 'misdirect' even if your local router lacks logs. And who do you think might gain access to the logs if they were to exist on your device? (when I refer to "who", answer in terms of: family/roommates/etc with easy physical proximity to the device? hackers who might try to randomly attack your devices/networks? hackers who specifically target you? government agencies?). And how (over the local network? over the internet? gaining physical access?)?

Guessing here, but I think that the process of eliminating all the log may be non-trivial. Some packages may have configuration/run-time options that are exposed, but others may be hardcoded and thus require edits to the source code and subsequent recompiles.

You could try one other thing...
in /etc/config/system you'll find this line by default:

	option log_size '64'

You could set that to 0 and see what happens.

3 Likes

You need some logs for operational purposes, like sdcard got bad sector.....

You have the point. But my idea to make something like Tails but for routers. It is not about mine threat model. It is about to hide whatever possible to hide. I wanna make it as secure as possible even against targeted attacks.

For now I am on this status: no web interface (GUI only via ssh), force drop of anything not HTTPS or DoT, force identifiers spoof via script (on reboot new MAC + BSSID assigned).

Regarding upstream logs, i am planning to force Tor.

What i plan to add next: ephemeral guest network (temp random SSID + pass that autodeletes after N time), NTS and DOH enforcement, ICMP block (even in LAN), noise generator (random requests to spoof users activity time) but not more that 5mb/day, port knocking to make it harder to scan even in LAN

Once more, it is only draft, so i am only trying to understand what exactly should i do and what i should not to make really good build.

Something like no-logs vpn keeps all in memory. You need a real ninja-hacker to unsolder powered RAM and dump it.....

1 Like

Obviously security is important, but you need to seriously consider the actual threats you anticipate. Just like physical security, the risks very much depend on how valuable/notable the target is and how determined (and possibly how well funded) the adversary is. If you're a powerful politician or business exec on the world stage vs a city council member vs a 'rank and file' member of the public, your risk profiles are quite different and therefore so are your security considerations/requirements. Obviously there are standard best practices that everyone should have as a baseline, but as you ramp up security, you also compromise usability/practicality. For example, one obvious method of physical security is to have multiple physical barriers. You have car doors, and those doors lock. So that makes it less likely that a truly opportunistic thief (one who is not going to pick the locks and/or damage property) is unlikely to steal stuff from your car. But maybe you want to prevent your car from being stolen from someone who might pick the lock, so you add a steering wheel lock... and then you add an electronic immobilizer. Now, you decide to park it inside your garage. But then you add a gate to keep people out of your garage. And you add another gate to keep people from even getting close to the garage. And you put all of the keys/remotes for these things in a super secure physical jewelry safe inside your house in a really hard to access location. Now, with all these barriers in place, you feel secure. But when you want to run out to the grocery store for a few bananas, now it is quite a process in order to get your car out of your garage and onto the street.

And from the sounds of it, you're aiming for something that is likely to become more of a hassle than a benefit, especially if/when things don't work quite as expected.

If you're a really high value target (say the head of a major government's intelligence division or a major political candidate) that is likely to attract the most persistent/skilled/well-funded hackers, yeah -- the highest level of security may be warranted. But for most people (likely including yourself), it's really not necessary...

For example... take this:

How is this going to improve your security posture more than simply correctly setting the firewall rules. Changing your guest network password becomes an inconvenience not just for your guests, but also for you since you'll, at a minimum, need to be part of the loop for your guests to login. And if your guests are so untrusted, maybe they shouldn't be in your home in the first place.

1 Like

Have a read:

If i put in LuCi -> logs -> log file -> /dev/null

What do you think? Is it safe? Or bad idea?
I am ok to loose troubleshooting info though, since it is test stand.

Try it. Worst case you need to use failsafe to recover.

I am not sure if that would have impact on the actual system log ring buffer in RAM, or would it just additionally try log write it to the file. (Check ubox sources, if you want to clarify that https://github.com/openwrt/ubox/tree/master/log )

Why do that, when you have been already given advice how to disable the logging service itself?

Or you could edit the log service init script to be a co-op.

Other approach could be to configure the system log ring buffer to be just 1 kB, so that it only contains last few items.

Categorical ICMP block sounds problematic. Most low-level internet protocols need at least some ICMP messages.

Not really understanding, what you mean here (or how you aim to accomplish that). Large part of traffic from applications has nothing to do with http/https. "Only HTTPS" is relevant in context if a web server, but not with pass-through traffic in a router.

Can you give some examples? I wanna test it more carefully

Close all ports and allow only 123, 853, 443.

Just so that it is clear, this will break a lot of functionality. Web will work, but many other things will not (including things like email applications that are not browser based, and probably almost everything else that's not done in the browser).

All types of "destination unreachable" including packet fragmentation notifications (due to path MTU differing from local), "time to live" = max packet hop count, etc. messages would be blocked. Depending on the ISP architecture and also the variety in LAN devices, you might be crippling yourself quite easily.

You might read a bit from https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol

You are probably thinking about "ping" type of fucntionality, but that is just a small part of the whole ICMP message universe. Especially with IPv6, the ICMPv6 messages are crucial in negotiating the path MTU etc.

Ever heard of rate limits?