On 2014-10-31, David Coppa wrote:
> Or you can log every command issued on the system...
> Your management would be very happy! ;) ;)
>
> http://pastebin.com/FZw4rT3T
That adds an easy DoS on a machine with serial console ;)
On November 1, 2014 12:49:51 PM CET, skin...@britvault.co.uk wrote:
>On 2014-10-31 Fri 11:52 AM |, Alexander Hall wrote:
>>
>> However, for the purpose of indicating password changes, this is
>pretty
>> useless anyway, since:
>>
>> - You can change to the same password
>> - logger(1) is available
On 2014-10-31 Fri 11:52 AM |, Alexander Hall wrote:
>
> However, for the purpose of indicating password changes, this is pretty
> useless anyway, since:
>
> - You can change to the same password
> - logger(1) is available for anyone to use (AFAIK)
>
> $ while sleep $((3600*24*7)); do logger "I c
On Fri, Oct 31, 2014 at 12:05 PM, Vijay Sankar wrote:
> Hi David,
>
> Thank you very much!! I am going to try the passwordcheck idea suggested by
> Stuart since that allows me to keep using -stable. But will definitely try
> your very interesting diff for sure.
Not mine at all. It's just a link
Quoting David Coppa :
On Thu, Oct 30, 2014 at 3:07 PM, Vijay Sankar wrote:
Quoting trondd :
The second problem I have is that when I change password, out of habit, I
do a passwd instead of mypasswd.
Why not call the script passwd and put it in the path ahead of the real
one?
What is the
On Fri, Oct 31, 2014 at 08:44:02AM +, Stuart Henderson wrote:
> On 2014-10-30, Vijay Sankar wrote:
> > Unfortunately that won't work because the objective is to just log any
> > (successful or failed) attempts to change passwords.
>
> I would probably try to abuse passwordcheck in login.con
On Thu, Oct 30, 2014 at 3:07 PM, Vijay Sankar wrote:
> Quoting trondd :
>
>>> The second problem I have is that when I change password, out of habit, I
>>> do a passwd instead of mypasswd.
>>
>>
>>
>> Why not call the script passwd and put it in the path ahead of the real
>> one?
>>
>> What is the
Quoting Stuart Henderson :
On 2014-10-30, Vijay Sankar wrote:
Unfortunately that won't work because the objective is to just log any
(successful or failed) attempts to change passwords.
I would probably try to abuse passwordcheck in login.conf to do this..
Thank you very much, I will try
On 2014-10-30, Vijay Sankar wrote:
> Unfortunately that won't work because the objective is to just log any
> (successful or failed) attempts to change passwords.
I would probably try to abuse passwordcheck in login.conf to do this..
On Oct 30 10:39:29, tro...@gmail.com wrote:
> Also check passwd(5), master.passwd holds
> expiration and last change information
No, that's something else:
The change field is the number in seconds, GMT, from the Epoch, until the
password for the account must be changed. This field may
On 10/30/14 17:19, Peter J. Philipp wrote:
I think I found something and Vijay found it but is being modest. Let
me show you:
> your script didn't work for me with /bin/sh so I modified it, and
> changed the logger's to echos so that I don't pollute my logs. I have
> found a small race in your
On 10/30/14 13:56, Vijay Sankar wrote:
> Quoting Alexander Hall :
>
>> On October 30, 2014 1:26:25 PM CET, Vijay Sankar
>> wrote:
>>> I have been using a simple script
>>>
>>> # mypasswd.sh
>>> /usr/bin/passwd -l
>>> if [[ $? != 0 ]]; then
>>> /usr/bin/logger "Unsuccessful attempt to chan
A setuid wrapper around passwd would prevent normal (non-root, non-sudo)
users from running passwd directly:
-r-sr-xr-x 1 auditor bin 10240 Oct 30 11:47 passwd
-r-x-- 1 auditor bin 28376 Oct 30 11:46 passwd.orig
The only catch is it can't be a shell script, which adds another (trivial)
Take the original passwd command and rename it to "passwd.orig" and
rename your script into its place (without the .sh ending) and have
your script call "passwd.orig". Still not perfect since someone who
knows the difference can still call the orig directly.
The alternative would be to dig into t
Only other thing I could think of is monitoring the right file access or
system calls or the like and logging that. But the script is probably the
simplest and if anyone circumvents the script by calling passwd directly,
it only means their password is newer than expected, which isn't as much of
a
Quoting trondd :
Also check passwd(5), master.passwd holds expiration and last change
information (I don't have in enabled anywhere, so I am not sure what it
looks like) that maybe you could generate a report from if you are
enforcing password expiry that way.
Tim.
Unfortunately that won't
Also check passwd(5), master.passwd holds expiration and last change
information (I don't have in enabled anywhere, so I am not sure what it
looks like) that maybe you could generate a report from if you are
enforcing password expiry that way.
Tim.
Quoting trondd :
The second problem I have is that when I change password, out of habit, I
do a passwd instead of mypasswd.
Why not call the script passwd and put it in the path ahead of the real one?
What is the goal? Are there users on the system trying to brute force
change a password?
> The second problem I have is that when I change password, out of habit, I
> do a passwd instead of mypasswd.
Why not call the script passwd and put it in the path ahead of the real one?
What is the goal? Are there users on the system trying to brute force
change a password? Or are you just t
Quoting Alexander Hall :
On October 30, 2014 1:26:25 PM CET, Vijay Sankar wrote:
I have been using a simple script
# mypasswd.sh
/usr/bin/passwd -l
if [[ $? != 0 ]]; then
/usr/bin/logger "Unsuccessful attempt to change password"
else
/usr/bin/logger "Changed login password"
fi
On October 30, 2014 1:26:25 PM CET, Vijay Sankar wrote:
>I have been using a simple script
>
># mypasswd.sh
>/usr/bin/passwd -l
>if [[ $? != 0 ]]; then
> /usr/bin/logger "Unsuccessful attempt to change password"
>else
> /usr/bin/logger "Changed login password"
>fi
>
>to get syslog
21 matches
Mail list logo
