[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