On Sat, 4 Nov 2017, Hans Dedecker wrote:
On Sat, Nov 4, 2017 at 10:14 AM, Petr Štetiar <yn...@true.cz> wrote:
Hans Dedecker <dedec...@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
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
