[LEDE-DEV] [PATCH] dropbear: make syslog support configurable

David Lang david at lang.hm
Sat Nov 4 11:39:52 PDT 2017


On Sat, 4 Nov 2017, Hans Dedecker wrote:

> On Sat, Nov 4, 2017 at 10:14 AM, Petr Štetiar <ynezz at true.cz> wrote:
>> Hans Dedecker <dedeckeh at gmail.com> [2017-11-03 13:46:14]:
>>
>> Hi,
>>
>>> By default dropbear logs to syslog which discloses info about account names
>>> when doing connection attempts (e.g. "Bad password attempt for 'engineer'
>>> from x.x.x.x:y")
>>
>> I don't get it, syslog discloses this information to whom and how?
> One case is different accounts being defined configured on a router
> like user/engineer/administrator/root each having access to logread.
> People using an account should not be able to find out the the other
> defined accounts eg by simple using logread

anyone on the system can read /etc/passwd and get a list of valid accounts.

if you are worried about data in the logs, change the permissions so that only 
some people can read the logs, don't eliminate them.

>>
>>> As this facilitates brute force attempts against account names;
>>
>> So instead of preventing this brute force attempts, you'll just ignore them
>> now? I'm wondering how is the brute forcing easier with syslog logging.
>>
>>> make syslog support configurable in order not to leak sensitive info via
>>> syslog.
>>
>> I think, that those are nice warning messages, reminding you, that you're
> Visions differ about these being nice warning messages dependant on
> whom you're talking to; after the latest dnsmasq CVE and Krack
> vulnerabilities people/ISPs have become worried and want to have the
> knobs not to leak sensitive info. Classifying info as sensitive is
> again another matter of discussion and differs from person to person.

leaking sensitive information to who? Why do you have your logs readable by 
people you don't trust?

if you really want full control of what is logged and where the logs go, enable 
rsyslog of syslog-ng and you won't have to worry about the logread command

disabling all logging is going to cripple any secuity ork.

Yes, logs contain sensitive information, anytime you log a failed login, you are 
guaranteed that someday someone will get out of sync with the login prompt and 
type their password in the userid field for example. But the fix for this is not 
to disable all logging, but rther to log so that only people you trust can see 
the logs.

While LEDE is a linux system, it's designed for very specialized systems, and as 
such, it has not focused on maintaining a safe multi-user environment, it's 
designed as a gateway or a server where only administrators are logging in to 
the define directly. If you are going to have untrusted people getting shell 
access on the device, thereare probably a LOT of things that you need to worry 
about a lot more than 'logread', I'll start with the uci command for example

David Lang


More information about the Lede-dev mailing list