subject:"logging"


On 12/18/2012 06:53 PM, John Hein wrote:

Tim Daneliuk wrote at 17:48 -0600 on Dec  5, 2012:
   On 12/05/2012 05:44 PM, Kurt Buff wrote:
On Wed, Dec 5, 2012 at 3:19 PM, Tim Daneliuk tun...@tundraware.com 
wrote:
I am working with an institution that today provides limited privilege
escalation
on their servers via very specific sudo rules.  The problem is that the
administrators can do 'sudo su -'.
snip
   
   
sudo is misconfigured.
   
man 5 sudoers and man 8 visudo
   
   
   
Kurt
   
  
   I'm sorry Kurt, I'm sort of dense today, I'm not sure what you're
   saying.  Are you suggesting that there is a way to configure
   sudo so that if someone does 'sudo su -' to become an admin,
   sudo can be made to log every command they execute thereafter?

See log_input and log_output in sudoers(5)


Thanks so much John, that's the secret sauce I was looking for...


--

Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: Somewhat OT: Is Full Command Logging Possible?


On 12/18/2012 07:09 PM, Tim Daneliuk wrote:

On 12/18/2012 06:53 PM, John Hein wrote:

Tim Daneliuk wrote at 17:48 -0600 on Dec  5, 2012:
   On 12/05/2012 05:44 PM, Kurt Buff wrote:
On Wed, Dec 5, 2012 at 3:19 PM, Tim Daneliuk tun...@tundraware.com 
wrote:
I am working with an institution that today provides limited privilege
escalation
on their servers via very specific sudo rules.  The problem is that the
administrators can do 'sudo su -'.
snip
   
   
sudo is misconfigured.
   
man 5 sudoers and man 8 visudo
   
   
   
Kurt
   
  
   I'm sorry Kurt, I'm sort of dense today, I'm not sure what you're
   saying.  Are you suggesting that there is a way to configure
   sudo so that if someone does 'sudo su -' to become an admin,
   sudo can be made to log every command they execute thereafter?

See log_input and log_output in sudoers(5)


Thanks so much John, that's the secret sauce I was looking for...




One further question, if I may.  If I do this:

   sudo su -

Will log_input record everything I do once I've been promoted to
root?  I ask because my initial experiments seem to show that all
that's getting recorded is the content of the sudo command itself,
not the subsequent actions...

--

Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: Somewhat OT: Is Full Command Logging Possible?

2012-12-18 Thread Devin Teske


On Dec 18, 2012, at 5:18 PM, Tim Daneliuk wrote:

 On 12/18/2012 07:09 PM, Tim Daneliuk wrote:
 On 12/18/2012 06:53 PM, John Hein wrote:
 Tim Daneliuk wrote at 17:48 -0600 on Dec  5, 2012:
   On 12/05/2012 05:44 PM, Kurt Buff wrote:
On Wed, Dec 5, 2012 at 3:19 PM, Tim Daneliuk tun...@tundraware.com 
 wrote:
I am working with an institution that today provides limited privilege
escalation
on their servers via very specific sudo rules.  The problem is that 
 the
administrators can do 'sudo su -'.
snip
   
   
sudo is misconfigured.
   
man 5 sudoers and man 8 visudo
   
   
   
Kurt
   
  
   I'm sorry Kurt, I'm sort of dense today, I'm not sure what you're
   saying.  Are you suggesting that there is a way to configure
   sudo so that if someone does 'sudo su -' to become an admin,
   sudo can be made to log every command they execute thereafter?
 
 See log_input and log_output in sudoers(5)
 
 Thanks so much John, that's the secret sauce I was looking for...
 
 
 
 One further question, if I may.  If I do this:
 
   sudo su -
 
 Will log_input record everything I do once I've been promoted to
 root?  I ask because my initial experiments seem to show that all
 that's getting recorded is the content of the sudo command itself,
 not the subsequent actions…
 

Correct, sudo is blind to the actions performed once the command requested is 
executed (in this case, su and subsequently a shell followed by more actions).

I've suggested the lrexec module for catching everything, or you can look into 
the auditdistd (distributed auditing collection/collation to a remote/central 
server) approach, the praudit approach, or any of the other pieces of software 
mentions.
-- 
Devin

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: Somewhat OT: Is Full Command Logging Possible?


On 12/18/2012 07:33 PM, Devin Teske wrote:


On Dec 18, 2012, at 5:18 PM, Tim Daneliuk wrote:







One further question, if I may.  If I do this:

   sudo su -

Will log_input record everything I do once I've been promoted to
root?  I ask because my initial experiments seem to show that all
that's getting recorded is the content of the sudo command itself,
not the subsequent actions…



Correct, sudo is blind to the actions performed once the command requested is executed 
(in this case, su and subsequently a shell followed by more actions).



Actually, I just tried this with both log_input and log_output options enabled.
It seems that it *can* see into the promoted shell with a few caveats:

  - Command output is logged immediately, but command inputs appear to only
be written to the log when you exit the promoted shell.  This may be
not quite right - there may have not been enough input to cause a
write flush to the log.

  - The logging seems to be able to see into a spawned subshell, but
I don't think it can see input/output if you, say, kick off an xterm.



I've suggested the lrexec module for catching everything, or you can look into 
the auditdistd (distributed auditing collection/collation to a remote/central 
server) approach, the praudit approach, or any of the other pieces of software 
mentions.




--

Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: Somewhat OT: Is Full Command Logging Possible?

2012-12-18 Thread Devin Teske


On Dec 18, 2012, at 5:43 PM, Tim Daneliuk wrote:

 On 12/18/2012 07:33 PM, Devin Teske wrote:
 
 On Dec 18, 2012, at 5:18 PM, Tim Daneliuk wrote:
 
 
 
 
 One further question, if I may.  If I do this:
 
   sudo su -
 
 Will log_input record everything I do once I've been promoted to
 root?  I ask because my initial experiments seem to show that all
 that's getting recorded is the content of the sudo command itself,
 not the subsequent actions…
 
 
 Correct, sudo is blind to the actions performed once the command requested 
 is executed (in this case, su and subsequently a shell followed by more 
 actions).
 
 
 Actually, I just tried this with both log_input and log_output options 
 enabled.
 It seems that it *can* see into the promoted shell with a few caveats:
 
  - Command output is logged immediately, but command inputs appear to only
be written to the log when you exit the promoted shell.  This may be
not quite right - there may have not been enough input to cause a
write flush to the log.
 
  - The logging seems to be able to see into a spawned subshell, but
I don't think it can see input/output if you, say, kick off an xterm.
 

What about if you do sudo vim and then type :sh ?
-- 
Devin



 
 I've suggested the lrexec module for catching everything, or you can look 
 into the auditdistd (distributed auditing collection/collation to a 
 remote/central server) approach, the praudit approach, or any of the other 
 pieces of software mentions.
 

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: Somewhat OT: Is Full Command Logging Possible?


On 12/18/2012 08:03 PM, Devin Teske wrote:


On Dec 18, 2012, at 5:43 PM, Tim Daneliuk wrote:


On 12/18/2012 07:33 PM, Devin Teske wrote:


On Dec 18, 2012, at 5:18 PM, Tim Daneliuk wrote:







One further question, if I may.  If I do this:

   sudo su -

Will log_input record everything I do once I've been promoted to
root?  I ask because my initial experiments seem to show that all
that's getting recorded is the content of the sudo command itself,
not the subsequent actions…



Correct, sudo is blind to the actions performed once the command requested is executed 
(in this case, su and subsequently a shell followed by more actions).



Actually, I just tried this with both log_input and log_output options enabled.
It seems that it *can* see into the promoted shell with a few caveats:

  - Command output is logged immediately, but command inputs appear to only
be written to the log when you exit the promoted shell.  This may be
not quite right - there may have not been enough input to cause a
write flush to the log.

  - The logging seems to be able to see into a spawned subshell, but
I don't think it can see input/output if you, say, kick off an xterm.



What about if you do sudo vim and then type :sh ?


Yep, I just tried that too.  It catches that.  It also catches
the in/output of subshells - like, say, kicking off sh interactively.
Similarly, if you're running text-based emacs, it catches the output
of spawning to a shell from there and doing things.

The only restriction I have run into so far, it that - for obvious
reasons - sudo cannot see into what you're doing if you kick off
an X application like xterm or graphical emacs, for instance.







--

Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: Somewhat OT: Is Full Command Logging Possible?


On 12/18/2012 08:20 PM, Tim Daneliuk wrote:

On 12/18/2012 08:03 PM, Devin Teske wrote:


On Dec 18, 2012, at 5:43 PM, Tim Daneliuk wrote:


On 12/18/2012 07:33 PM, Devin Teske wrote:


On Dec 18, 2012, at 5:18 PM, Tim Daneliuk wrote:







One further question, if I may.  If I do this:

   sudo su -

Will log_input record everything I do once I've been promoted to
root?  I ask because my initial experiments seem to show that all
that's getting recorded is the content of the sudo command itself,
not the subsequent actions…



Correct, sudo is blind to the actions performed once the command requested is executed 
(in this case, su and subsequently a shell followed by more actions).



Actually, I just tried this with both log_input and log_output options enabled.
It seems that it *can* see into the promoted shell with a few caveats:

  - Command output is logged immediately, but command inputs appear to only
be written to the log when you exit the promoted shell.  This may be
not quite right - there may have not been enough input to cause a
write flush to the log.

  - The logging seems to be able to see into a spawned subshell, but
I don't think it can see input/output if you, say, kick off an xterm.



What about if you do sudo vim and then type :sh ?


Yep, I just tried that too.  It catches that.  It also catches
the in/output of subshells - like, say, kicking off sh interactively.
Similarly, if you're running text-based emacs, it catches the output
of spawning to a shell from there and doing things.

The only restriction I have run into so far, it that - for obvious
reasons - sudo cannot see into what you're doing if you kick off
an X application like xterm or graphical emacs, for instance.


I should clarify that I tested this not on FreeBSD but on a Mint Linux
desktop I had handy.  I would expect the same behavior everywhere, though,
since sudo itself is reasonably portable...


--

Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: Somewhat OT: Is Full Command Logging Possible?

2012-12-18 Thread Devin Teske


On Dec 18, 2012, at 6:20 PM, Tim Daneliuk wrote:

 On 12/18/2012 08:03 PM, Devin Teske wrote:
 
 On Dec 18, 2012, at 5:43 PM, Tim Daneliuk wrote:
 
 On 12/18/2012 07:33 PM, Devin Teske wrote:
 
 On Dec 18, 2012, at 5:18 PM, Tim Daneliuk wrote:
 
 
 
 
 One further question, if I may.  If I do this:
 
   sudo su -
 
 Will log_input record everything I do once I've been promoted to
 root?  I ask because my initial experiments seem to show that all
 that's getting recorded is the content of the sudo command itself,
 not the subsequent actions…
 
 
 Correct, sudo is blind to the actions performed once the command requested 
 is executed (in this case, su and subsequently a shell followed by more 
 actions).
 
 
 Actually, I just tried this with both log_input and log_output options 
 enabled.
 It seems that it *can* see into the promoted shell with a few caveats:
 
  - Command output is logged immediately, but command inputs appear to only
be written to the log when you exit the promoted shell.  This may be
not quite right - there may have not been enough input to cause a
write flush to the log.
 
  - The logging seems to be able to see into a spawned subshell, but
I don't think it can see input/output if you, say, kick off an xterm.
 
 
 What about if you do sudo vim and then type :sh ?
 
 Yep, I just tried that too.  It catches that.  It also catches
 the in/output of subshells - like, say, kicking off sh interactively.
 Similarly, if you're running text-based emacs, it catches the output
 of spawning to a shell from there and doing things.
 
 The only restriction I have run into so far, it that - for obvious
 reasons - sudo cannot see into what you're doing if you kick off
 an X application like xterm or graphical emacs, for instance.
 

What about screen or tmux? (wondering if the transition into multiplexed shell 
is anywhere as opaque as X11).
-- 
Devin

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: Somewhat OT: Is Full Command Logging Possible?


On 12/18/2012 10:10 PM, Devin Teske wrote:


On Dec 18, 2012, at 6:20 PM, Tim Daneliuk wrote:


On 12/18/2012 08:03 PM, Devin Teske wrote:


On Dec 18, 2012, at 5:43 PM, Tim Daneliuk wrote:


On 12/18/2012 07:33 PM, Devin Teske wrote:


On Dec 18, 2012, at 5:18 PM, Tim Daneliuk wrote:







One further question, if I may.  If I do this:

   sudo su -

Will log_input record everything I do once I've been promoted to
root?  I ask because my initial experiments seem to show that all
that's getting recorded is the content of the sudo command itself,
not the subsequent actions…



Correct, sudo is blind to the actions performed once the command requested is executed 
(in this case, su and subsequently a shell followed by more actions).



Actually, I just tried this with both log_input and log_output options enabled.
It seems that it *can* see into the promoted shell with a few caveats:

  - Command output is logged immediately, but command inputs appear to only
be written to the log when you exit the promoted shell.  This may be
not quite right - there may have not been enough input to cause a
write flush to the log.

  - The logging seems to be able to see into a spawned subshell, but
I don't think it can see input/output if you, say, kick off an xterm.



What about if you do sudo vim and then type :sh ?


Yep, I just tried that too.  It catches that.  It also catches
the in/output of subshells - like, say, kicking off sh interactively.
Similarly, if you're running text-based emacs, it catches the output
of spawning to a shell from there and doing things.

The only restriction I have run into so far, it that - for obvious
reasons - sudo cannot see into what you're doing if you kick off
an X application like xterm or graphical emacs, for instance.



What about screen or tmux? (wondering if the transition into multiplexed shell 
is anywhere as opaque as X11).



It definitely works if you are in a screen session and sudo su - from there.  I 
have
not tried promoting myself to root and THEN starting the screen session (I 
don't use tmux).

--

Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: Somewhat OT: Is Full Command Logging Possible?

2012-12-08 Thread Damien Fleuriot


On 8 Dec 2012, at 03:13, Devin Teske devin.te...@fisglobal.com wrote:

 
 On Dec 7, 2012, at 5:22 PM, Paul Schmehl wrote:
 
 --On December 7, 2012 10:23:56 AM +0100 Fleuriot Damien m...@my.gd wrote:
 
 
 On Dec 6, 2012, at 9:20 PM, Paul Schmehl pschmehl_li...@tx.rr.com wrote:
 
 --On December 6, 2012 1:19:00 PM -0600 Tim Daneliuk
 tun...@tundraware.com wrote:
 
 I understand this.  Even the organization in question understands
 this.  They are not trying to *prevent* any kind of access.  All
 they're trying to do *log* it.  Why?  To meet some obscure
 compliance requirement they have to adhere to in order to
 remain in business.
 
 rant
 I know all of this is silly but that's our future when you
 let Our Fine Government regulate pretty much anything.
 /rant
 
 
 I sent this last night, but for some reason it never showed up.
 
 /usr/ports/security/sudoscript
 
 I believe this will meet your requirements.
 
 
 I'm sorry to say it won't.
 Nothing will prevent a user from removing sudoscript's FIFO once he gets
 root privileges.
 
 
 Well, sure, but, if someone logs in and sudos to root, that will be logged 
 by sudoscript.  If the logging then ceases, that would be cause for 
 disciplinary action up to and including dismissal.
 
 
 What about the case of:
 
 sudo vim
 
 or
 
 sudo vim file
 
 Surely that wouldn't raise an eyebrow, but…
 
 Then execute within vim:
 
 :sh
 
 or
 
 ^_^
 -- 
 Devin
 
 … and another gem …
 
 sr env HOME=$HOME vim
 
 then
 
 :E
 

My point exactly, such levels of protection can't be reached on our day to day 
OSes.

The only thing that can be done is trying to approach the expected level of 
scrutiny and security.

The audit framework is a viable solution IMO, as long as it has limited 
protection against kills (restart it, send a SMS alert...)
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: Somewhat OT: Is Full Command Logging Possible?

2012-12-07 Thread Damien Fleuriot


On 6 Dec 2012, at 20:19, Tim Daneliuk tun...@tundraware.com wrote:

 On 12/06/2012 12:55 PM, n j wrote:
 On Thu, Dec 6, 2012 at 12:47 AM, Tim Daneliuk tun...@tundraware.com wrote:
 ...
 Well ... does auditd provide a record of every command issued within a
 script?
 I was under the impression (and I may well be wrong) that it  noted only
 the name of the script being executed.
 
 Even if you configured auditd to record every command issued within a
 script, you'd still have a problem if a malicious user put the same
 commands inside a binary.
 
 As some people already pointed out, there is practically no way to
 control users once you give them root privileges.
 
 I understand this.  Even the organization in question understands
 this.  They are not trying to *prevent* any kind of access.  All
 they're trying to do *log* it.  Why?  To meet some obscure
 compliance requirement they have to adhere to in order to
 remain in business.
 
 rant
 I know all of this is silly but that's our future when you
 let Our Fine Government regulate pretty much anything.
 /rant
 

This sounds awfully similar to PCI DSS requirements to me.

Nothing to do with .gov then ;)
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: Somewhat OT: Is Full Command Logging Possible?

2012-12-07 Thread Fleuriot Damien


On Dec 6, 2012, at 9:20 PM, Paul Schmehl pschmehl_li...@tx.rr.com wrote:

 --On December 6, 2012 1:19:00 PM -0600 Tim Daneliuk tun...@tundraware.com 
 wrote:
 
 I understand this.  Even the organization in question understands
 this.  They are not trying to *prevent* any kind of access.  All
 they're trying to do *log* it.  Why?  To meet some obscure
 compliance requirement they have to adhere to in order to
 remain in business.
 
 rant
 I know all of this is silly but that's our future when you
 let Our Fine Government regulate pretty much anything.
 /rant
 
 
 I sent this last night, but for some reason it never showed up.
 
 /usr/ports/security/sudoscript
 
 I believe this will meet your requirements.


I'm sorry to say it won't.
Nothing will prevent a user from removing sudoscript's FIFO once he gets root 
privileges.


Basically, what Tim wants to do sounds very akin to the PCI DSS requirements 
that every user's action be logged.
The bad news is _this is not achievable on MS/nux/bsd_ systems.
The kind of logging and security required can only be attained on mainframes 
(read: i/Series , z/Series) using RACF and other absolutely awesome features.


The only thing Tim can do is try to approach the level of security that's 
required.

Devin's suggestion of a kernel module is what comes closest to achieving the 
goal, provided that:
- the functionnality is compiled in-kernel to prevent kldunload'ing the module
- the system runs at a secure level high enough to prevent kldunloads , if it 
can't be compiled in-kernel
- the functions used by the module cannot be overriden by another module (for 
example redeclare this module's sendlog() function with another dummy module, 
making sendlog() basically do a NOOP)

Another contestant that comes a close second is the use of the AUDIT framework, 
however one would need to ensure:
- audit trails cannot be tampered (chflags sappend)
- the audit daemon cannot be killed

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: Somewhat OT: Is Full Command Logging Possible?

2012-12-07 Thread Paul Schmehl


--On December 7, 2012 10:23:56 AM +0100 Fleuriot Damien m...@my.gd wrote:



On Dec 6, 2012, at 9:20 PM, Paul Schmehl pschmehl_li...@tx.rr.com wrote:


--On December 6, 2012 1:19:00 PM -0600 Tim Daneliuk
tun...@tundraware.com wrote:


I understand this.  Even the organization in question understands
this.  They are not trying to *prevent* any kind of access.  All
they're trying to do *log* it.  Why?  To meet some obscure
compliance requirement they have to adhere to in order to
remain in business.

rant
I know all of this is silly but that's our future when you
let Our Fine Government regulate pretty much anything.
/rant



I sent this last night, but for some reason it never showed up.

/usr/ports/security/sudoscript

I believe this will meet your requirements.



I'm sorry to say it won't.
Nothing will prevent a user from removing sudoscript's FIFO once he gets
root privileges.



Well, sure, but, if someone logs in and sudos to root, that will be logged 
by sudoscript.  If the logging then ceases, that would be cause for 
disciplinary action up to and including dismissal.


Not all problems can be solved with technology.
Paul Schmehl, Senior Infosec Analyst
As if it wasn't already obvious, my opinions
are my own and not those of my employer.
***
It is as useless to argue with those who have
renounced the use of reason as to administer
medication to the dead. Thomas Jefferson
There are some ideas so wrong that only a very
intelligent person could believe in them. George Orwell

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: Somewhat OT: Is Full Command Logging Possible?

2012-12-07 Thread Devin Teske


On Dec 7, 2012, at 5:22 PM, Paul Schmehl wrote:

 --On December 7, 2012 10:23:56 AM +0100 Fleuriot Damien m...@my.gd wrote:
 
 
 On Dec 6, 2012, at 9:20 PM, Paul Schmehl pschmehl_li...@tx.rr.com wrote:
 
 --On December 6, 2012 1:19:00 PM -0600 Tim Daneliuk
 tun...@tundraware.com wrote:
 
 I understand this.  Even the organization in question understands
 this.  They are not trying to *prevent* any kind of access.  All
 they're trying to do *log* it.  Why?  To meet some obscure
 compliance requirement they have to adhere to in order to
 remain in business.
 
 rant
 I know all of this is silly but that's our future when you
 let Our Fine Government regulate pretty much anything.
 /rant
 
 
 I sent this last night, but for some reason it never showed up.
 
 /usr/ports/security/sudoscript
 
 I believe this will meet your requirements.
 
 
 I'm sorry to say it won't.
 Nothing will prevent a user from removing sudoscript's FIFO once he gets
 root privileges.
 
 
 Well, sure, but, if someone logs in and sudos to root, that will be logged by 
 sudoscript.  If the logging then ceases, that would be cause for disciplinary 
 action up to and including dismissal.
 

What about the case of:

sudo vim

or

sudo vim file

Surely that wouldn't raise an eyebrow, but…

Then execute within vim:

:sh

or

^_^
-- 
Devin

… and another gem …

sr env HOME=$HOME vim

then

:E

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: Somewhat OT: Is Full Command Logging Possible?

2012-12-06 Thread Fleuriot Damien


On Dec 6, 2012, at 12:47 AM, Tim Daneliuk tun...@tundraware.com wrote:

 On 12/05/2012 05:42 PM, Damien Fleuriot wrote:
 
 
 On 6 Dec 2012, at 00:19, Tim Daneliuk tun...@tundraware.com wrote:
 
  sudo chown root:wheel my_naughty_script
  sudo chmod  700 my_naughty script
  sudo ./my_naughty_script
 
   The sudo log will note that I ran the script, but not what it did.
 
 
 
 wow, way to complicate matters.
 
 Hey, I didn't dream up this problem :)
 
 
 sudo csh
 
 
 
 So Gentle Geniuses, is there prior art here that could be applied
 to give me full coverage logging of every action taken by any person or
 thing running with effective or actual root?
 
 P.S. I do not believe
 
 Now would be a good time to start, then.
 
 
 Well ... does auditd provide a record of every command issued within a script?
 I was under the impression (and I may well be wrong) that it  noted only
 the name of the script being executed.
 

While it won't log every single command invoked from inside a script, it *can* 
log every single file access that's made.

Apart from IBM z/Series and i/Series mainframes, there is no hardware/software 
combination that I am aware of which will do that.

The Audit framework is your next best bet IMHO.


 
 The only things you need to ensure are:
 - auditd cannot be killed off (this is an interesting bit actually, anyone 
 knows how to do that ?)
 - the audit trail files can only be appended to ; man chflags
 
 
 An alternative would be lshell, however you'll have to whitelist commands 
 people can execute.
 
 
 
 Remember that we want admins to be able to do *anything* but we just want
 to log what they do, in fact do.
 
 -- 
 
 Tim Daneliuk tun...@tundraware.com
 PGP Key: http://www.tundraware.com/PGP/
 
 ___
 freebsd-questions@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-questions
 To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: Somewhat OT: Is Full Command Logging Possible?

2012-12-06 Thread Fleuriot Damien


On Dec 6, 2012, at 1:35 AM, Kurt Buff kurt.b...@gmail.com wrote:

 On Wed, Dec 5, 2012 at 3:48 PM, Tim Daneliuk tun...@tundraware.com wrote:
 On 12/05/2012 05:44 PM, Kurt Buff wrote:
 
 On Wed, Dec 5, 2012 at 3:19 PM, Tim Daneliuk tun...@tundraware.com
 wrote:
 
 I am working with an institution that today provides limited privilege
 escalation
 on their servers via very specific sudo rules.  The problem is that the
 administrators can do 'sudo su -'.
 
 snip
 
 
 sudo is misconfigured.
 
 man 5 sudoers and man 8 visudo
 
 
 
 Kurt
 
 
 I'm sorry Kurt, I'm sort of dense today, I'm not sure what you're
 saying.  Are you suggesting that there is a way to configure
 sudo so that if someone does 'sudo su -' to become an admin,
 sudo can be made to log every command they execute thereafter?
 
 No, I'm saying that sudo should not be configured to allow 'sudo su -'.


This is an ineffective solution.

So what, you're going to forbid sudo su -

Fine, I'll just run sudo csh .

If you forbid csh, I'll just copy the existing `which csh` to ~/toto and sudo 
~/toto .



Basically, anything short of actually whitelisting what people can run won't do.

And apparently that's not in Tim's list of desirable things ;)

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: Somewhat OT: Is Full Command Logging Possible?

2012-12-06 Thread n j

On Thu, Dec 6, 2012 at 12:47 AM, Tim Daneliuk tun...@tundraware.com wrote:
 ...
 Well ... does auditd provide a record of every command issued within a
 script?
 I was under the impression (and I may well be wrong) that it  noted only
 the name of the script being executed.

Even if you configured auditd to record every command issued within a
script, you'd still have a problem if a malicious user put the same
commands inside a binary.

As some people already pointed out, there is practically no way to
control users once you give them root privileges.

The only thing that would really solve your problem is probably
something like http://www.balabit.com/network-security/scb/features
(no personal experience with it, but seems it does what you need).

-- 
Nino
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: Somewhat OT: Is Full Command Logging Possible?

2012-12-06 Thread Tim Daneliuk


On 12/06/2012 12:55 PM, n j wrote:

On Thu, Dec 6, 2012 at 12:47 AM, Tim Daneliuk tun...@tundraware.com wrote:

...
Well ... does auditd provide a record of every command issued within a
script?
I was under the impression (and I may well be wrong) that it  noted only
the name of the script being executed.


Even if you configured auditd to record every command issued within a
script, you'd still have a problem if a malicious user put the same
commands inside a binary.

As some people already pointed out, there is practically no way to
control users once you give them root privileges.


I understand this.  Even the organization in question understands
this.  They are not trying to *prevent* any kind of access.  All
they're trying to do *log* it.  Why?  To meet some obscure
compliance requirement they have to adhere to in order to
remain in business.

rant
I know all of this is silly but that's our future when you
let Our Fine Government regulate pretty much anything.
/rant




The only thing that would really solve your problem is probably
something like http://www.balabit.com/network-security/scb/features
(no personal experience with it, but seems it does what you need).




--
---
Tim Daneliuk
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Fwd: Somewhat OT: Is Full Command Logging Possible?

2012-12-06 Thread Kurt Buff

Sorry, forgot to replay all...

Kurt

-- Forwarded message --
From: Kurt Buff kurt.b...@gmail.com
Date: Thu, Dec 6, 2012 at 11:53 AM
Subject: Re: Somewhat OT: Is Full Command Logging Possible?
To: Fleuriot Damien m...@my.gd

On Thu, Dec 6, 2012 at 1:26 AM, Fleuriot Damien m...@my.gd wrote:

 On Dec 6, 2012, at 1:35 AM, Kurt Buff kurt.b...@gmail.com wrote:

 On Wed, Dec 5, 2012 at 3:48 PM, Tim Daneliuk tun...@tundraware.com wrote:
 On 12/05/2012 05:44 PM, Kurt Buff wrote:

 On Wed, Dec 5, 2012 at 3:19 PM, Tim Daneliuk tun...@tundraware.com
 wrote:

 I am working with an institution that today provides limited privilege
 escalation
 on their servers via very specific sudo rules.  The problem is that the
 administrators can do 'sudo su -'.

 snip

 sudo is misconfigured.

 man 5 sudoers and man 8 visudo

 Kurt

 I'm sorry Kurt, I'm sort of dense today, I'm not sure what you're
 saying.  Are you suggesting that there is a way to configure
 sudo so that if someone does 'sudo su -' to become an admin,
 sudo can be made to log every command they execute thereafter?

 No, I'm saying that sudo should not be configured to allow 'sudo su -'.

 This is an ineffective solution.

 So what, you're going to forbid sudo su -

 Fine, I'll just run sudo csh .

 If you forbid csh, I'll just copy the existing `which csh` to ~/toto and 
 sudo ~/toto .

 Basically, anything short of actually whitelisting what people can run won't 
 do.

 And apparently that's not in Tim's list of desirable things ;)

Whitelisting commands is exactly what the sudoers file is for. If he
wants to do otherwise, then he's using the wrong tool.

Kurt
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: Somewhat OT: Is Full Command Logging Possible?

2012-12-06 Thread Paul Schmehl

--On December 6, 2012 1:19:00 PM -0600 Tim Daneliuk tun...@tundraware.com 
wrote:


I understand this.  Even the organization in question understands
this.  They are not trying to *prevent* any kind of access.  All
they're trying to do *log* it.  Why?  To meet some obscure
compliance requirement they have to adhere to in order to
remain in business.

rant
I know all of this is silly but that's our future when you
let Our Fine Government regulate pretty much anything.
/rant



I sent this last night, but for some reason it never showed up.

/usr/ports/security/sudoscript

I believe this will meet your requirements.

--
Paul Schmehl, Senior Infosec Analyst
As if it wasn't already obvious, my opinions
are my own and not those of my employer.
***
It is as useless to argue with those who have
renounced the use of reason as to administer
medication to the dead. Thomas Jefferson
There are some ideas so wrong that only a very
intelligent person could believe in them. George Orwell

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: Somewhat OT: Is Full Command Logging Possible?

2012-12-06 Thread Devin Teske

On Dec 5, 2012, at 3:19 PM, Tim Daneliuk wrote:

This is a little bit outside the strict boundaries of a FreeBSD question,
but I am hoping someone in this community has solved this problem and
that I might be able to adapt it for non-FreeBSD systems (AIX and Linux,
specifically).

I am working with an institution that today provides limited privilege
escalation
on their servers via very specific sudo rules. The problem is that the
administrators can do 'sudo su -'. The fact that they became root is
logged, *but everything thereafter they do is not*. What these people
need is something that does the following things - this need not be
sudo based, any FOSS or commercial solution would be considered:

- Log the fact that someone became effective root

- Log every command they execute *as* root

- If they run a script as root, log the individual
actions of that script

- Have visibility into all this no matter how they access
the system - console, ssh, xterm ….

There's a kernel module floating around the Intarwebs…

lrexec

We used it for some years to satisfy governance regulations.

But let me tell you… it got so noisy, it was ultimately disabled for sanity.

But don't let that stop You.

…

Quick search of lrexec module yields the following:
http://freebsd.munk.me.uk/archives/112-Installed-and-Configured-lrexec-module-For-Logging-System-Calls.html

NOTE: Our plan for replacing this functionality in our organization was to use
the praudit fire-hose available in FreeBSD-8.x. It too could be a solution to
your problem.
--
Devin

Nothing I have found so far meets all these criterion. Verbose
syslogging will not catch the case where you start a subshell
from the main shell. Keylogging seems to only have limited
coverage and does not appear it would work if, say, I log in
via ssh and then kick off an xterm. Other solutions
fail if I start an editor and shell out from there.

The current proposal is to install sudo rules such that NO one
is allowed 'sudo su -' and *every single command* you want
to run as root has to start with 'sudo'. This has two big
drawbacks:

- It's an enormous pain for the admins and fundamentally changes
their workflow

- It cannot see into scripts. So I can circumvent it pretty
easily with:

sudo chown root:wheel my_naughty_script
sudo chmod 700 my_naughty script
sudo ./my_naughty_script

The sudo log will note that I ran the script, but not what it did.

So Gentle Geniuses, is there prior art here that could be applied
to give me full coverage logging of every action taken by any person or
thing running with effective or actual root?

P.S. I do not believe auditd does this either.

Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

_
The information contained in this message is proprietary and/or confidential.
If you are not the intended recipient, please: (i) delete the message and all
copies; (ii) do not disclose, distribute or use the message in any manner; and
(iii) notify the sender immediately. In addition, please be aware that any
message addressed to our domain is subject to archiving and review by persons
other than the intended recipient. Thank you.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Somewhat OT: Is Full Command Logging Possible?

2012-12-05 Thread Tim Daneliuk


This is a little bit outside the strict boundaries of a FreeBSD question,
but I am hoping someone in this community has solved this problem and
that I might be able to adapt it for non-FreeBSD systems (AIX and Linux,
specifically).

I am working with an institution that today provides limited privilege 
escalation
on their servers via very specific sudo rules.  The problem is that the
administrators can do 'sudo su -'.  The fact that they became root is
logged, *but everything thereafter they do is not*.  What these people
need is something that does the following things - this need not be
sudo based, any FOSS or commercial solution would be considered:

  - Log the fact that someone became effective root

  - Log every command they execute *as* root

  - If they run a script as root, log the individual
actions of that script

  - Have visibility into all this no matter how they access
the system - console, ssh, xterm 

Nothing I have found so far meets all these criterion.  Verbose
syslogging will not catch the case where you start a subshell
from the main shell.  Keylogging seems to only have limited
coverage and does not appear it would work if, say, I log in
via ssh and then kick off an xterm.   Other solutions
fail if I start an editor and shell out from there.

The current proposal is to install sudo rules such that NO one
is allowed 'sudo su -' and *every single command* you want
to run as root has to start with 'sudo'.  This has two big
drawbacks:

  - It's an enormous pain for the admins and fundamentally changes
their workflow

  - It cannot see into scripts.  So I can circumvent it pretty
easily with:

  sudo chown root:wheel my_naughty_script
  sudo chmod  700 my_naughty script
  sudo ./my_naughty_script

   The sudo log will note that I ran the script, but not what it did.


So Gentle Geniuses, is there prior art here that could be applied
to give me full coverage logging of every action taken by any person or
thing running with effective or actual root?

P.S. I do not believe auditd does this either.


--

Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: Somewhat OT: Is Full Command Logging Possible?

2012-12-05 Thread Adam Vande More

On Wed, Dec 5, 2012 at 5:19 PM, Tim Daneliuk tun...@tundraware.com wrote:

 This is a little bit outside the strict boundaries of a FreeBSD question,
 but I am hoping someone in this community has solved this problem and
 that I might be able to adapt it for non-FreeBSD systems (AIX and Linux,
 specifically).

 P.S. I do not believe auditd does this either.


Challenge your beliefs.

-- 
Adam Vande More
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: Somewhat OT: Is Full Command Logging Possible?

2012-12-05 Thread Damien Fleuriot



On 6 Dec 2012, at 00:19, Tim Daneliuk tun...@tundraware.com wrote:

  sudo chown root:wheel my_naughty_script
  sudo chmod  700 my_naughty script
  sudo ./my_naughty_script
 
   The sudo log will note that I ran the script, but not what it did.
 
 

wow, way to complicate matters.

sudo csh



 So Gentle Geniuses, is there prior art here that could be applied
 to give me full coverage logging of every action taken by any person or
 thing running with effective or actual root?
 
 P.S. I do not believe

Now would be a good time to start, then.

The only things you need to ensure are:
- auditd cannot be killed off (this is an interesting bit actually, anyone 
knows how to do that ?)
- the audit trail files can only be appended to ; man chflags


An alternative would be lshell, however you'll have to whitelist commands 
people can execute.

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: Somewhat OT: Is Full Command Logging Possible?

2012-12-05 Thread Tim Daneliuk


On 12/05/2012 05:42 PM, Damien Fleuriot wrote:



On 6 Dec 2012, at 00:19, Tim Daneliuk tun...@tundraware.com wrote:


  sudo chown root:wheel my_naughty_script
  sudo chmod  700 my_naughty script
  sudo ./my_naughty_script

   The sudo log will note that I ran the script, but not what it did.




wow, way to complicate matters.


Hey, I didn't dream up this problem :)



sudo csh




So Gentle Geniuses, is there prior art here that could be applied
to give me full coverage logging of every action taken by any person or
thing running with effective or actual root?

P.S. I do not believe


Now would be a good time to start, then.



Well ... does auditd provide a record of every command issued within a script?
I was under the impression (and I may well be wrong) that it  noted only
the name of the script being executed.



The only things you need to ensure are:
- auditd cannot be killed off (this is an interesting bit actually, anyone 
knows how to do that ?)
- the audit trail files can only be appended to ; man chflags


An alternative would be lshell, however you'll have to whitelist commands 
people can execute.




Remember that we want admins to be able to do *anything* but we just want
to log what they do, in fact do.

--

Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: Somewhat OT: Is Full Command Logging Possible?

2012-12-05 Thread Tim Daneliuk


On 12/05/2012 06:35 PM, Kurt Buff wrote:

On Wed, Dec 5, 2012 at 3:48 PM, Tim Daneliuk tun...@tundraware.com wrote:

On 12/05/2012 05:44 PM, Kurt Buff wrote:


On Wed, Dec 5, 2012 at 3:19 PM, Tim Daneliuk tun...@tundraware.com
wrote:


I am working with an institution that today provides limited privilege
escalation
on their servers via very specific sudo rules.  The problem is that the
administrators can do 'sudo su -'.


snip


sudo is misconfigured.

man 5 sudoers and man 8 visudo



Kurt



I'm sorry Kurt, I'm sort of dense today, I'm not sure what you're
saying.  Are you suggesting that there is a way to configure
sudo so that if someone does 'sudo su -' to become an admin,
sudo can be made to log every command they execute thereafter?


No, I'm saying that sudo should not be configured to allow 'sudo su -'.

Since you say that the users are provided limited privilege
escalation on their servers via very specific sudo rules, it seems to
me that one of three things is going wrong:

o- Something is wrong with the configuration of sudoers if they can su
to root when they shouldn't be able to do so

o- Someone has misconceived what limited privilege escalation on
their servers via very specific sudo rules actually means, and
deliberately has it configured to allows users to su to root

o- The users' accounts are already root equivalent, which, depending
on the version and configuration of sudo, might give them the ability
to sudo to root regardless of the contents of the sudoers file (see,
for instance, the screen in FreeBSD when you perform 'cd
/usr/ports/security/sudo' and then 'make config')

Kurt


Oh, OK, I wasn't being clear:

- *Some* users are granted the ability to do sudo su -  These
  are the sysadmins.

- All other user are given selective ability to run only a few
  things via sudo.  This varies by department and is controlled
  through a combination of sudo rules and central LDAP group
  membership control.  This is necessary because, for example,
  some DBAs need this when installing a particular client.

--

Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: Somewhat OT: Is Full Command Logging Possible?

2012-12-05 Thread Adam Vande More

On Wed, Dec 5, 2012 at 5:42 PM, Damien Fleuriot m...@my.gd wrote:



 On 6 Dec 2012, at 00:19, Tim Daneliuk tun...@tundraware.com wrote:

   sudo chown root:wheel my_naughty_script
   sudo chmod  700 my_naughty script
   sudo ./my_naughty_script
 
The sudo log will note that I ran the script, but not what it did.
 
 

 wow, way to complicate matters.

 sudo csh



  So Gentle Geniuses, is there prior art here that could be applied
  to give me full coverage logging of every action taken by any person or
  thing running with effective or actual root?
 
  P.S. I do not believe

 Now would be a good time to start, then.

 The only things you need to ensure are:
 - auditd cannot be killed off (this is an interesting bit actually, anyone
 knows how to do that ?)


Can't be done really for an id 0 account.  Not without extensive
customization anyway. However the Audit Distribution Daemon was
recently committed so audit logs could potentially be stored in different
location easily.


 - the audit trail files can only be appended to ; man chflags


Audit Distribution Daemon would alleviate this as well.

-- 
Adam Vande More
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: Somewhat OT: Is Full Command Logging Possible?

2012-12-05 Thread Paul Schmehl

--On December 5, 2012 7:01:21 PM -0600 Tim Daneliuk tun...@tundraware.com 
wrote:



On 12/05/2012 06:35 PM, Kurt Buff wrote:

On Wed, Dec 5, 2012 at 3:48 PM, Tim Daneliuk tun...@tundraware.com
wrote:

On 12/05/2012 05:44 PM, Kurt Buff wrote:


On Wed, Dec 5, 2012 at 3:19 PM, Tim Daneliuk tun...@tundraware.com
wrote:


I am working with an institution that today provides limited privilege
escalation
on their servers via very specific sudo rules.  The problem is that
the administrators can do 'sudo su -'.


snip


sudo is misconfigured.

man 5 sudoers and man 8 visudo



Kurt



I'm sorry Kurt, I'm sort of dense today, I'm not sure what you're
saying.  Are you suggesting that there is a way to configure
sudo so that if someone does 'sudo su -' to become an admin,
sudo can be made to log every command they execute thereafter?


No, I'm saying that sudo should not be configured to allow 'sudo su -'.

Since you say that the users are provided limited privilege
escalation on their servers via very specific sudo rules, it seems to
me that one of three things is going wrong:

o- Something is wrong with the configuration of sudoers if they can su
to root when they shouldn't be able to do so

o- Someone has misconceived what limited privilege escalation on
their servers via very specific sudo rules actually means, and
deliberately has it configured to allows users to su to root

o- The users' accounts are already root equivalent, which, depending
on the version and configuration of sudo, might give them the ability
to sudo to root regardless of the contents of the sudoers file (see,
for instance, the screen in FreeBSD when you perform 'cd
/usr/ports/security/sudo' and then 'make config')

Kurt


Oh, OK, I wasn't being clear:

- *Some* users are granted the ability to do sudo su -  These
   are the sysadmins.

- All other user are given selective ability to run only a few
   things via sudo.  This varies by department and is controlled
   through a combination of sudo rules and central LDAP group
   membership control.  This is necessary because, for example,
   some DBAs need this when installing a particular client.



Install security/sudoscript.

Paul Schmehl, Senior Infosec Analyst
As if it wasn't already obvious, my opinions
are my own and not those of my employer.
***
It is as useless to argue with those who have
renounced the use of reason as to administer
medication to the dead. Thomas Jefferson
There are some ideas so wrong that only a very
intelligent person could believe in them. George Orwell

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

logging debug of hw.usb.debug=1 with syslog

2012-10-11 Thread Karolis Eigelis

Hi,

i need to debug USB device and i want to log all the messages via syslog,
but i do not know how to do that i looked at syslog.conf, but could find
the flag i should use for debug.log.

i used sysctl hw.usb.debug=1 lots of things i get printed out, but how to
log them permanently ?

Many Thanks,
Karolis
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: Security - logging of user commands

2012-07-26 Thread Damien Fleuriot

On 7/25/12 6:15 PM, jb wrote:
 Damien Fleuriot ml at my.gd writes:
 
 ... 
 From my syslog.conf:
 auth.info;authpriv.info /var/log/auth.log

 Yet I'm seeing not a trail in /var/log/auth.log , or messages, or even
 in secure
 ... 
 
 # less /var/log/auth.log 
 Feb 22 21:13:56 localhost newsyslog[1503]: logfile first created
 Feb 22 21:14:07 localhost login: login on ttyv0 as jb
 Feb 22 21:14:15 localhost su: jb to root on /dev/ttyv0
 ...
 Jul 25 15:23:48 localhost su: jb to root on /dev/pts/3
 Jul 25 17:25:05 localhost snoopy[50059]: [uid:0 sid:45449 tty:/dev/pts/2
 cwd:/usr/ports/security/snoopy filename:/usr/bin/touch]: touch 
 /etc/ld.so.preload 
 Jul 25 17:25:05 localhost snoopy[50060]: [uid:0 sid:45449 tty:/dev/pts/2
 cwd:/usr/ports/security/snoopy filename:/usr/bin/grep]: grep -c
 ^/usr/local/lib//snoopy.so /etc/ld.so.preload 
 Jul 25 17:52:29 localhost snoopy[50145]: [uid:0 sid:46687 tty:/dev/pts/3
 cwd:/usr/home/jb filename:/usr/bin/less]: less /var/log/auth.log 
 Jul 25 17:54:03 localhost snoopy[50148]: [uid:0 sid:46687 tty:/dev/pts/3
 cwd:/usr/home/jb filename:/usr/bin/touch]: touch test1 
 Jul 25 17:54:08 localhost snoopy[50149]: [uid:0 sid:46687 tty:/dev/pts/3
 cwd:/usr/home/jb filename:/usr/bin/less]: less /var/log/auth.log 
 [root@localhost /home/jb]#
 
 jb
 
 


Well, after some digging I am sorry to report that security/snoopy/ is,
imho, quite bugged on 8-STABLE and 9-STABLE alike.



Let's take the example of logging the current working directory:


Below is the statement from ./configure --help :
Optional Features:
[snip]
  --disable-cwd-logging   disable logging of Current Working Directory
  [default=enabled]



From config.h:66
/* Enable logging of Current Working Directory */
/* #undef SNOOPY_CWD_LOGGING */

From configure:4298
#define SNOOPY_CWD_LOGGING 1

From snoopy.c:127
/* Create logMessage */
#if defined(SNOOPY_CWD_LOGGING)



Small edits to snoopy.c to check if current working directory logging is
really enabled:

--- snoopy.c.orig   2012-07-26 10:16:06.0 +
+++ snoopy.c2012-07-26 10:18:05.0 +
@@ -123,12 +123,18 @@
logString[logStringSize-1] = '\0';


+/* Check wether SNOOPY_CWD_LOGGING is _really_ defined or not */
+int cwdlog=0;
+#if defined(SNOOPY_CWD_LOGGING)
+cwdlog=1;
+#endif
+
/* Create logMessage */
#if defined(SNOOPY_CWD_LOGGING)
getCwdRet = getcwd(cwd, PATH_MAX+1);
-   sprintf(logMessage, [uid:%d sid:%d tty:%s cwd:%s filename:%s]: 
%s,
getuid(), getsid(0), ttyPath, cwd, filename, logString);
+   sprintf(logMessage, [uid:%d sid:%d tty:%s cwd:%s filename:%s]: 
%s,
  getuid(), getsid(0), ttyPath, cwd, filename, logString);
#else
-   sprintf(logMessage, [uid:%d sid:%d tty:%s filename:%s]: %s,
getuid(), getsid(0), ttyPath, filename, logString);
+   sprintf(logMessage, cwdlog: %d - [uid:%d sid:%d tty:%s 
filename:%s]:
%s, cwdlog, getuid(), getsid(0), ttyPath, filename, logString);
#endif




And the result:
gmake snoopy.so
setenv LD_PRELOAD /usr/ports/security/snoopy/work/snoopy-1.8.0/snoopy.so
/etc/rc.d/named status


Yields, amongst others:

Jul 26 10:19:00 pf1 snoopy[96561]: cwdlog: 0 - [uid:0 sid:92850
tty:/dev/pts/0 filename:/bin/ps]: /bin/ps -ww -o pid= -o jid= -o
command= -p 1073


Notice how cwdlog is set to 0 which means we don't want to log the
CWD, although configure reports SNOOPY_CWD_LOGGING 1

I think that might not be the only bug, seeing only root actions seem to
be logged although the default should be to log every user.

I'd like to point out that apart from these edits for my tests this is a
*vanilla* install of snoopy.



Might anyone confirm the issue ?

The above is true for 8.1-RELEASE, 8-STABLE , 9-STABLE with snoopy being
at version 1.8.0 on all of them.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: Security - logging of user commands

2012-07-26 Thread jb

Damien Fleuriot ml at my.gd writes:

 ... 
 Might anyone confirm the issue ?
 
 The above is true for 8.1-RELEASE, 8-STABLE , 9-STABLE with snoopy being
 at version 1.8.0 on all of them.

$ uname -r
9.0-RELEASE-p3

$ man ldconfig
...
Filenames must conform to the lib*.so.[0-9] pattern in order to
 be added to the hints file.
...
FILES
 /var/run/ld.so.hints Standard hints file for the a.out dynamic
  linker.
 /var/run/ld-elf.so.hints Standard hints file for the ELF dynamic
  linker.
 /etc/ld.so.conf  Conventional configuration file containing
  directory names for invocations with -aout.
 /etc/ld-elf.so.conf  Conventional configuration file containing
  directory names for invocations with -elf.
 /var/run/ld-elf32.so.hints
 /var/run/ld32.so.hints   Conventional configuration files containing
  directory names for invocations with -32.
 /etc/objformat   Determines whether -aout or -elf is the
  default.  If present, it must consist of a
  single line containing either
  `OBJFORMAT=aout' or `OBJFORMAT=elf'.
...
$

# ls -al /usr/local/lib/libsnoopy.so*
lrwxr-xr-x  1 root  wheel14 Jul 26 20:43 /usr/local/lib/libsnoopy.so -
libsnoopy.so.1
-r-xr-xr-x  1 root  wheel  4824 Jul 26 20:07 /usr/local/lib/libsnoopy.so.1

$ grep ldconfig /etc/defaults/rc.conf
...
ldconfig_paths=... /usr/local/lib ...
...

# /etc/rc.d/ldconfig start
...
ldconfig_start()
...
for i in ${ldconfig_paths} /etc/ld-elf.so.conf; do
if [ -r ${i} ]; then
_LDC=${_LDC} ${i}
fi
done
check_startmsgs  echo 'ELF ldconfig path:' ${_LDC}
${ldconfig} -elf ${_ins} ${_LDC}
...


$ ldconfig -r
/var/run/ld-elf.so.hints:
search directories:
/lib:/usr/lib:/usr/lib/compat:/usr/local/lib:/usr/local/lib/event2:/usr/local
/lib/gcc46:/usr/local/lib/graphviz:/usr/local/lib/libxul:/usr/local/lib/nss:
/usr/local/lib/pth:/usr/local/lib/qt4
0:-lc.7 = /lib/libc.so.7
...
465:-lsnoopy.1 = /usr/local/lib/libsnoopy.so.1
...
$

# man ldconfig
...
# tail /var/log/auth.log
...
Jul 26 22:12:38 localhost snoopy[5884]: [uid:0 sid:2957 tty:/dev/pts/2
cwd:/usr/local/lib filename:/sbin/sysctl]: /sbin/sysctl -n hw.machine_arch 
Jul 26 22:12:38 localhost snoopy[5885]: [uid:0 sid:2957 tty:/dev/pts/2
cwd:/usr/local/lib filename:/sbin/sysctl]: /sbin/sysctl -n hw.machine 
Jul 26 22:12:38 localhost snoopy[5886]: [uid:0 sid:2957 tty:/dev/pts/2
cwd:/usr/local/lib filename:/usr/bin/locale]: /usr/bin/locale 
Jul 26 22:12:38 localhost snoopy[5889]: [uid:0 sid:2957 tty: cwd:/usr/local/lib
filename:/usr/bin/head]: head -1 
Jul 26 22:12:38 localhost snoopy[5888]: [uid:0 sid:2957 tty:/dev/pts/2
cwd:/usr/local/lib filename:/usr/bin/zcat]: /usr/bin/zcat
/usr/share/man/man8/ldconfig.8.gz 
Jul 26 22:12:38 localhost snoopy[5892]: [uid:0 sid:2957 tty: cwd:/usr/local/lib
filename:/usr/bin/groff]: groff -S -P-h -Wall -mtty-char -man -Tascii -P-c 
Jul 26 22:12:38 localhost snoopy[5891]: [uid:0 sid:2957 tty: cwd:/usr/local/lib
filename:/usr/bin/tbl]: tbl 
Jul 26 22:12:38 localhost snoopy[5890]: [uid:0 sid:2957 tty:/dev/pts/2
cwd:/usr/local/lib filename:/usr/bin/zcat]: /usr/bin/zcat
/usr/share/man/man8/ldconfig.8.gz 
Jul 26 22:12:38 localhost snoopy[5893]: [uid:0 sid:2957 tty: cwd:/usr/local/lib
filename:/usr/bin/more]: more 

# /etc/rc.d/named status
Cannot 'status' named. Set named_enable to YES in /etc/rc.conf or use
'onestatus' instead of 'status'.

# tail /var/log/auth.log
...
Jul 26 22:16:40 localhost snoopy[5917]: [uid:0 sid:2957 tty:/dev/pts/2
cwd:/usr/local/lib filename:/bin/ps]: /bin/ps -ww -p 5916 -o jid= 
Jul 26 22:16:40 localhost snoopy[5919]: [uid:0 sid:2957 tty:/dev/pts/2
cwd:/usr/local/lib filename:/bin/ps]: /bin/ps -ww -o pid= -o jid= -o command= 
-ax 
#

jb






___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Securituy - logging of user commands

Hello list,



We're currently working towards the PCI DSS certification (Payment Card
Industry) for a project at work.


One of the prerequisites is that all user commands be logged.

We're currently using a very bad hack that takes the last command from a
user's history and sends it to a log server.

This of course is unreliable as a user may entirely disable their
history, or just use another shell to bypass the csh function or whatever.



My colleagues installed Snoopy on debian and it seems to work wonders as
a module which is LD preloaded.


I notice it also exists on FreeBSD as /usr/ports/security/snoopy .


However I face several problems with it, mainly it doesn't seem to log
anything.



As per the README, I have added /usr/local/lib/snoopy.so to
/etc/ld.so.preload

I'm not even sure this file is used on BSD ?

As per the man page for ld.so there's no such file:
http://www.freebsd.org/cgi/man.cgi?query=ld.so

Neither libmap.conf nor ldconfig(8) seem to be the answer either.



I've googled for ld.so.conf and found the following 2 posts which seem
to indicate it isn't used either:
http://lists.freebsd.org/pipermail/freebsd-hackers/2003-June/001746.html
http://lists.freebsd.org/pipermail/freebsd-hackers/2003-June/001747.html

The posts mention -current but date back from 2003.



Lastly, I have also noticed that the port installs /usr/local/bin/detect
which I executed and would always reply something's fishy.

By looking at the (very short) source I noticed the program merely loads
/lib/libc.so.6 , and it wouldn't find it on my system (8.3-STABLE with
/lib/libc.so.7).
Adjusting and recompiling lets the program correctly print secure but
it does nothing else.

I have checked that the output /usr/local/lib/snoopy.so module is linked
against libc.so.7 , and it is.



Has anyone ever got Snoopy to work on BSD ?
Might I need to install linux emulation ?

Is there any other port that might do the job and which I could use ?
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: Securituy - logging of user commands

No I haven't.

That's a good suggestion, I'll look into it and see if it fits the
purpose :)


On 7/25/12 2:04 PM, Peter Boosten wrote:
 Have you ever considered the audit function of FreeBSD?
 
 
 Peter Boosten
 
 On 25 jul. 2012, at 13:47, Damien Fleuriot m...@my.gd wrote:
 
 Hello list,



 We're currently working towards the PCI DSS certification (Payment Card
 Industry) for a project at work.


 One of the prerequisites is that all user commands be logged.

 We're currently using a very bad hack that takes the last command from a
 user's history and sends it to a log server.

 This of course is unreliable as a user may entirely disable their
 history, or just use another shell to bypass the csh function or whatever.



 My colleagues installed Snoopy on debian and it seems to work wonders as
 a module which is LD preloaded.


 I notice it also exists on FreeBSD as /usr/ports/security/snoopy .


 However I face several problems with it, mainly it doesn't seem to log
 anything.



 As per the README, I have added /usr/local/lib/snoopy.so to
 /etc/ld.so.preload

 I'm not even sure this file is used on BSD ?

 As per the man page for ld.so there's no such file:
 http://www.freebsd.org/cgi/man.cgi?query=ld.so

 Neither libmap.conf nor ldconfig(8) seem to be the answer either.



 I've googled for ld.so.conf and found the following 2 posts which seem
 to indicate it isn't used either:
 http://lists.freebsd.org/pipermail/freebsd-hackers/2003-June/001746.html
 http://lists.freebsd.org/pipermail/freebsd-hackers/2003-June/001747.html

 The posts mention -current but date back from 2003.



 Lastly, I have also noticed that the port installs /usr/local/bin/detect
 which I executed and would always reply something's fishy.

 By looking at the (very short) source I noticed the program merely loads
 /lib/libc.so.6 , and it wouldn't find it on my system (8.3-STABLE with
 /lib/libc.so.7).
 Adjusting and recompiling lets the program correctly print secure but
 it does nothing else.

 I have checked that the output /usr/local/lib/snoopy.so module is linked
 against libc.so.7 , and it is.



 Has anyone ever got Snoopy to work on BSD ?
 Might I need to install linux emulation ?

 Is there any other port that might do the job and which I could use ?
 ___
 freebsd-questions@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-questions
 To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: Securituy - logging of user commands

2012-07-25 Thread Peter Boosten

Have you ever considered the audit function of FreeBSD?


Peter Boosten

On 25 jul. 2012, at 13:47, Damien Fleuriot m...@my.gd wrote:

 Hello list,
 
 
 
 We're currently working towards the PCI DSS certification (Payment Card
 Industry) for a project at work.
 
 
 One of the prerequisites is that all user commands be logged.
 
 We're currently using a very bad hack that takes the last command from a
 user's history and sends it to a log server.
 
 This of course is unreliable as a user may entirely disable their
 history, or just use another shell to bypass the csh function or whatever.
 
 
 
 My colleagues installed Snoopy on debian and it seems to work wonders as
 a module which is LD preloaded.
 
 
 I notice it also exists on FreeBSD as /usr/ports/security/snoopy .
 
 
 However I face several problems with it, mainly it doesn't seem to log
 anything.
 
 
 
 As per the README, I have added /usr/local/lib/snoopy.so to
 /etc/ld.so.preload
 
 I'm not even sure this file is used on BSD ?
 
 As per the man page for ld.so there's no such file:
 http://www.freebsd.org/cgi/man.cgi?query=ld.so
 
 Neither libmap.conf nor ldconfig(8) seem to be the answer either.
 
 
 
 I've googled for ld.so.conf and found the following 2 posts which seem
 to indicate it isn't used either:
 http://lists.freebsd.org/pipermail/freebsd-hackers/2003-June/001746.html
 http://lists.freebsd.org/pipermail/freebsd-hackers/2003-June/001747.html
 
 The posts mention -current but date back from 2003.
 
 
 
 Lastly, I have also noticed that the port installs /usr/local/bin/detect
 which I executed and would always reply something's fishy.
 
 By looking at the (very short) source I noticed the program merely loads
 /lib/libc.so.6 , and it wouldn't find it on my system (8.3-STABLE with
 /lib/libc.so.7).
 Adjusting and recompiling lets the program correctly print secure but
 it does nothing else.
 
 I have checked that the output /usr/local/lib/snoopy.so module is linked
 against libc.so.7 , and it is.
 
 
 
 Has anyone ever got Snoopy to work on BSD ?
 Might I need to install linux emulation ?
 
 Is there any other port that might do the job and which I could use ?
 ___
 freebsd-questions@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-questions
 To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: Securituy - logging of user commands

2012-07-25 Thread jb

Damien Fleuriot ml at my.gd writes:

 ... 
 I notice it also exists on FreeBSD as /usr/ports/security/snoopy .
 
 However I face several problems with it, mainly it doesn't seem to log
 anything.
 
 As per the README, I have added /usr/local/lib/snoopy.so to
 /etc/ld.so.preload
 
 I'm not even sure this file is used on BSD ?
 ...

/usr/ports/security/snoopy]# make clean; make
...
# ls work/snoopy-1.8.0/
...
enable.sh
...

jb

  


___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: Securituy - logging of user commands


On 7/25/12 2:42 PM, jb wrote:
 Damien Fleuriot ml at my.gd writes:
 
 ... 
 I notice it also exists on FreeBSD as /usr/ports/security/snoopy .

 However I face several problems with it, mainly it doesn't seem to log
 anything.

 As per the README, I have added /usr/local/lib/snoopy.so to
 /etc/ld.so.preload

 I'm not even sure this file is used on BSD ?
 ...
 
 /usr/ports/security/snoopy]# make clean; make
 ...
 # ls work/snoopy-1.8.0/
 ...
 enable.sh
 ...
 
 jb
 


Well that's my problem exactly, really.

1/ the enable script won't work and will always return an error,
requiring a manual activation
2/ even once enabled, snoopy doesn't get loaded because
/etc/ld.so.preload is not used on FBSD apparently
3/ even when enabled with setenv LD_PRELOAD /usr/local/lib/snoopy.so,
snoopy won't return any log



From config.h:
/* Syslog facility to use */
#define SNOOPY_SYSLOG_FACILITY LOG_AUTHPRIV

/* Syslog level to use */
#define SNOOPY_SYSLOG_LEVEL LOG_INFO


From my syslog.conf:
auth.info;authpriv.info /var/log/auth.log

Yet I'm seeing not a trail in /var/log/auth.log , or messages, or even
in secure


I have however validated that snoopy.so is called, as per the following:

# truss ls /dev/null
[snip]
open(/usr/local/lib/snoopy.so,O_RDONLY,031)= 2 (0x2)
fstat(2,{ mode=-r-xr-xr-x ,inode=548761,size=6952,blksize=16384 }) = 0 (0x0)
fstatfs(0x2,0x7fffe220,0x19,0x0,0x80080053a068,0x0) = 0 (0x0)
pread(0x2,0x80063e2a0,0x1000,0x0,0x80080053a068,0x0) = 4096 (0x1000)
mmap(0x0,1056768,PROT_NONE,MAP_PRIVATE|MAP_ANON|MAP_NOCORE,-1,0x0) =
34366341120 (0x80064c000)
mmap(0x80064c000,8192,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE,2,0x0)
= 34366341120 (0x80064c000)
mmap(0x80074d000,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED,2,0x1000)
= 34367393792 (0x80074d000)
close(2) = 0 (0x0)


And still no logs...
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: Securituy - logging of user commands

2012-07-25 Thread Victor Sudakov

Peter Boosten wrote:
 Have you ever considered the audit function of FreeBSD?

Does it really log user commands? At best, it logs executed processes.

-- 
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
sip:suda...@sibptus.tomsk.ru
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: Securituy - logging of user commands

2012-07-25 Thread jb

Damien Fleuriot ml at my.gd writes:

 ... 
 From my syslog.conf:
 auth.info;authpriv.info /var/log/auth.log
 
 Yet I'm seeing not a trail in /var/log/auth.log , or messages, or even
 in secure
 ... 

# less /var/log/auth.log 
Feb 22 21:13:56 localhost newsyslog[1503]: logfile first created
Feb 22 21:14:07 localhost login: login on ttyv0 as jb
Feb 22 21:14:15 localhost su: jb to root on /dev/ttyv0
...
Jul 25 15:23:48 localhost su: jb to root on /dev/pts/3
Jul 25 17:25:05 localhost snoopy[50059]: [uid:0 sid:45449 tty:/dev/pts/2
cwd:/usr/ports/security/snoopy filename:/usr/bin/touch]: touch 
/etc/ld.so.preload 
Jul 25 17:25:05 localhost snoopy[50060]: [uid:0 sid:45449 tty:/dev/pts/2
cwd:/usr/ports/security/snoopy filename:/usr/bin/grep]: grep -c
^/usr/local/lib//snoopy.so /etc/ld.so.preload 
Jul 25 17:52:29 localhost snoopy[50145]: [uid:0 sid:46687 tty:/dev/pts/3
cwd:/usr/home/jb filename:/usr/bin/less]: less /var/log/auth.log 
Jul 25 17:54:03 localhost snoopy[50148]: [uid:0 sid:46687 tty:/dev/pts/3
cwd:/usr/home/jb filename:/usr/bin/touch]: touch test1 
Jul 25 17:54:08 localhost snoopy[50149]: [uid:0 sid:46687 tty:/dev/pts/3
cwd:/usr/home/jb filename:/usr/bin/less]: less /var/log/auth.log 
[root@localhost /home/jb]#

jb


___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: Securituy - logging of user commands


On 25 Jul 2012, at 18:15, jb jb.1234a...@gmail.com wrote:

 Damien Fleuriot ml at my.gd writes:
 
 ... 
 From my syslog.conf:
 auth.info;authpriv.info /var/log/auth.log
 
 Yet I'm seeing not a trail in /var/log/auth.log , or messages, or even
 in secure
 ... 
 
 # less /var/log/auth.log 
 Feb 22 21:13:56 localhost newsyslog[1503]: logfile first created
 Feb 22 21:14:07 localhost login: login on ttyv0 as jb
 Feb 22 21:14:15 localhost su: jb to root on /dev/ttyv0
 ...
 Jul 25 15:23:48 localhost su: jb to root on /dev/pts/3
 Jul 25 17:25:05 localhost snoopy[50059]: [uid:0 sid:45449 tty:/dev/pts/2
 cwd:/usr/ports/security/snoopy filename:/usr/bin/touch]: touch 
 /etc/ld.so.preload 
 Jul 25 17:25:05 localhost snoopy[50060]: [uid:0 sid:45449 tty:/dev/pts/2
 cwd:/usr/ports/security/snoopy filename:/usr/bin/grep]: grep -c
 ^/usr/local/lib//snoopy.so /etc/ld.so.preload 
 Jul 25 17:52:29 localhost snoopy[50145]: [uid:0 sid:46687 tty:/dev/pts/3
 cwd:/usr/home/jb filename:/usr/bin/less]: less /var/log/auth.log 
 Jul 25 17:54:03 localhost snoopy[50148]: [uid:0 sid:46687 tty:/dev/pts/3
 cwd:/usr/home/jb filename:/usr/bin/touch]: touch test1 
 Jul 25 17:54:08 localhost snoopy[50149]: [uid:0 sid:46687 tty:/dev/pts/3
 cwd:/usr/home/jb filename:/usr/bin/less]: less /var/log/auth.log 
 [root@localhost /home/jb]#
 
 jb
 

Thanks for taking the time to show me it works, at least for you.

What fbsd and snoopy version might these be ?

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

isc-dhcpd - logging client transactions

2012-06-06 Thread Ewald Jenisch

Hi,

I've set up isc-dhcpd (/usr/ports/net/isc-dhcp42-server). The daemon
runs, hands out IP-addresses however logging doesn't seem to work.

Here's what I've got in the respective config-files:

/etc/rc.conf:
# dhcpd
dhcpd_enable=YES
dhcpd_conf=/usr/local/etc/dhcpd.conf
dhcpd_ifaces=em0
dhcpd_withumask=022
dhcpd_chuser_enable=YES
dhcpd_withuser=dhcpd
dhcpd_withgroup=dhcpd
dhcpd_chroot_enable=YES
dhcpd_devfs_enable=YES
dhcpd_rootdir=/var/db/dhcpd

/usr/local/etc/dhcpd.conf:
...
log-facility local7;

/etc/syslog.conf:
local7.*/var/log/dhcpd.log


/var/log/dhcpd.log is touched, so it exists.

Also restarted syslogd and isc-dhcpd.


Result: dhcpd works (i.e. I see entries in the leases-file
(/var/db/dhcpd/var/db/dhcpd/dhcpd.leases) however nothing is logged to
/var/log/dhcpd.log.

I can rule out any error with syslogd.conf since when I start isc-dhcp
by hand (/usr/local/sbin/dhcpd -d) I get an error message - and this
one is definitely logged to /var/log/dhcpd.log.

What I really need though is a log of all the DHCP-transactions,
i.e. DHCP-requests, address assignments etc.

Thanks much in advance for your help,
-ewald
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: define a default username for logging in

2012-04-18 Thread takCoder

Hi again,

Really Thank You for your tricky advice.. it was a Nice one(and seems to be
the Only one!).. :)

sorry for late reply; it took me a while to become sure i got no other ways
that bothering you again..

the suggested way seems to work, but i've got a problem:
how can i apply these settings on pts devices?! i mean, how can i disable
login on pts devices to continue the rest? do you have any idea??

i tried the same format in /etc/ttys, but it didn't work..
i could not find any tips via googling as well.. so.. :)

you know, it's not that important to be able to use all 999 enabled pts
devices on my server! i can abound them if there is a file such as
/etc/ttys for per pty device configurations..

looking forward to receive your ideas.
Thanks in Advance :)
takCoder

On Sat, Apr 7, 2012 at 12:39 PM, Polytropon free...@edvax.de wrote:

 On Sat, 7 Apr 2012 12:21:57 +0430, takCoder wrote:
  Hi All :)
 
  i'm trying to find a way to enable a required feature : to set *default
  username *in my Freebsd 8.2 server..
 
  i mean, i wanna be able to login with just entering My Master Password(no
  usernames needed.. also prefer it to be per tty), which is *not related
 to
  my root account,  *but is the password of a user which i have defined as
 my
  default user..
 
  is it possible for, e.g. pam_login module (i couldn't find any manuals on
  such feature yet..), to have such a config or is there any other ways to
  set such default username for login?

 It is, but I assume my answer will just be a half of the
 whole story. The problem will be: no password. But maybe
 you can find some inspiration and then extend the procedure
 to fit your needs.



 1. Modify /etc/gettytab as follows:

default:\
...

localautologin:\
:al=USERNAME:tc=Pc:

a|std.110|110-baud:\
...

 where USERNAME is the name of the user you want to login as
 (given by the al= parameter, and inheriting the tc= settings).
 Make sure the user does exist in the system.



 2. Modify /etc/ttys as follows:

ttyv0  /usr/libexec/getty localautologin  cons25  on  secure

 and maybe change cons25 to cons25l1 (or any other value that might
 be required).



 As I said initially, this does _not_ prompt for a password!
 Maybe /etc/passwd's shell field allows you to add the password
 protection.

 If you're logging in remotely, ssh USERNAME@yourserver.qw.er.tzu
 will only prompt for a password. This idea offers an opportunity
 to something overcomplicated:

 Create a user for localautologin that is _not_ your default
 user name. Make this user login automatically, and into his
 ~/.login, place the command ssh USERNAME@localhost so
 right after performing the localautologin, ssh will attempt
 to connect to localhost _as USERNAME_ and _prompt for_ the
 password. Terrible, I know. :-)

 To milden the pain of this approach, you could allow telnet
 for localhost, i. e. from 127.0.0.1 to 127.0.0.1 _ONLY_ and
 nothing more, and use telnet instead of ssh in the ~/.login
 command.




 --
 Polytropon
 Magdeburg, Germany
 Happy FreeBSD user since 4.0
 Andra moi ennepe, Mousa, ...

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

define a default username for logging in

2012-04-07 Thread takCoder

Hi All :)

i'm trying to find a way to enable a required feature : to set *default
username *in my Freebsd 8.2 server..

i mean, i wanna be able to login with just entering My Master Password(no
usernames needed.. also prefer it to be per tty), which is *not related to
my root account,  *but is the password of a user which i have defined as my
default user..

is it possible for, e.g. pam_login module (i couldn't find any manuals on
such feature yet..), to have such a config or is there any other ways to
set such default username for login?

i've googled most of the keywords i thought might be related, but haven't
find any related answers except for maybe working on nsswitch.conf or
master.passwd or login.conf options (which are, as you see, really *different
ways,  *and also none seems to be behaved per tty..)
and now, i'm not quite sure whether i'm taking the correct steps or not..
and i've got a bit confused..

would anyone please helps me find the way?
thanks a lot for your helps :)

Best Regards,
takCoder
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: define a default username for logging in

2012-04-07 Thread Polytropon

On Sat, 7 Apr 2012 12:21:57 +0430, takCoder wrote:
 Hi All :)
 
 i'm trying to find a way to enable a required feature : to set *default
 username *in my Freebsd 8.2 server..
 
 i mean, i wanna be able to login with just entering My Master Password(no
 usernames needed.. also prefer it to be per tty), which is *not related to
 my root account,  *but is the password of a user which i have defined as my
 default user..
 
 is it possible for, e.g. pam_login module (i couldn't find any manuals on
 such feature yet..), to have such a config or is there any other ways to
 set such default username for login?

It is, but I assume my answer will just be a half of the
whole story. The problem will be: no password. But maybe
you can find some inspiration and then extend the procedure
to fit your needs.



1. Modify /etc/gettytab as follows:

default:\
...

localautologin:\
:al=USERNAME:tc=Pc:

a|std.110|110-baud:\
...

where USERNAME is the name of the user you want to login as
(given by the al= parameter, and inheriting the tc= settings).
Make sure the user does exist in the system.



2. Modify /etc/ttys as follows:

ttyv0  /usr/libexec/getty localautologin  cons25  on  secure

and maybe change cons25 to cons25l1 (or any other value that might
be required).



As I said initially, this does _not_ prompt for a password!
Maybe /etc/passwd's shell field allows you to add the password
protection.

If you're logging in remotely, ssh USERNAME@yourserver.qw.er.tzu
will only prompt for a password. This idea offers an opportunity
to something overcomplicated:

Create a user for localautologin that is _not_ your default
user name. Make this user login automatically, and into his
~/.login, place the command ssh USERNAME@localhost so
right after performing the localautologin, ssh will attempt
to connect to localhost _as USERNAME_ and _prompt for_ the
password. Terrible, I know. :-)

To milden the pain of this approach, you could allow telnet
for localhost, i. e. from 127.0.0.1 to 127.0.0.1 _ONLY_ and
nothing more, and use telnet instead of ssh in the ~/.login
command.




-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Syslog server not logging remote machines to file?


Hi,

I've got a really strange problem which seems to either be a bug with 
the syslog server service or perhaps because I'm running jails on my 
system.


I can log my router syslog information but somehow the syslog server 
doesn't put the information into the designated file; which should be 
/var/log/cisco857w.log???


This is the syslog definition in my /etc/rc.conf file:

{

syslogd_enable=YES
#syslog_flags=
syslogd_flags=-d -b 192.168.1.120 -a 192.168.1.1/24:* -vv -C

}

Additionally here is my /etc/syslog.conf file:

{

# $FreeBSD: src/etc/syslog.conf,v 1.30.2.1.2.1 2009/10/25 01:10:29 
kensmith Exp $

#
#Spaces ARE valid field separators in this file. However,
#other *nix-like systems still insist on using tabs as field
#separators. If you are sharing this file between systems, you
#may want to use only tabs as field separators here.
#Consult the syslog.conf(5) manpage.
#+server.domain
*.err;kern.warning;auth.notice;mail.crit/dev/console
*.notice;local7.none;authpriv.none;kern.debug;lpr.info;mail.crit;news.err
/var/log/messages

security.*/var/log/security
auth.info;authpriv.info/var/log/auth.log
mail.info/var/log/maillog
lpr.info/var/log/lpd-errs
ftp.info/var/log/xferlog
cron.*/var/log/cron
*.=debug/var/log/debug.log
*.emerg*
# uncomment this to log all writes to /dev/console to /var/log/console.log
#console.info/var/log/console.log
# uncomment this to enable logging of all log messages to /var/log/all.log
# touch /var/log/all.log and chmod it to mode 600 before it will work
#*.*/var/log/all.log
# uncomment this to enable logging to a remote loghost named loghost
#*.*@loghost
# uncomment these if you're running inn
# news.crit/var/log/news/news.crit
# news.err/var/log/news/news.err
# news.notice/var/log/news/news.notice
!ppp
*.*/var/log/ppp.log
!*
+192.168.1.1
*.*/var/log/cisco857w.log
#local7.* /var/log/cisco857w.log
#!*
#+172.16.0.1
#*.*

}

uname -a shows this:

{

# uname -a
FreeBSD server.domain 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 21 
15:02:08 UTC 2009 
r...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64


}

The odd thing about this is that I did the same thing on a non-jailed 
32bit machine running FreeBSD 8.x and the system worked fine.


In my research for the problem I have covered this material:

{

http://www.freebsd.org/doc/handbook/network-syslogd.html

http://forums.devshed.com/bsd-help-31/remote-syslog-question-router-to-freebsd-118652.html

http://www.freebsd.org/doc/handbook/network-syslogd.html

http://www.daemonforums.org/showthread.php?t=2968

http://bsd.dischaos.com/2009/02/25/logging-cisco-ios-messages-to-external-freebsd-syslog/

http://unix.derkeiler.com/Mailing-Lists/FreeBSD/questions/2007-02/msg00384.html

http://plone.lucidsolutions.co.nz/networking/cisco/ios/logging-to-a-syslog-or-rsyslog-host-from-cisco-ios

http://lists.nycbug.org/pipermail/talk/2007-April/010091.html

http://www.freebsdonline.com/content/view/527/506/

}

They all seem to say more or less the same thing that either putting the:

{

+192.168.1.1
*.*/var/log/cisco857w.log
or
local7.* /var/log/cisco857w.log

}

statements either at the top of the file or changing the syntax slightly 
using a + between machines should do the trick; however, non of the 
things I tried have worked from any of the material mentioned above!


Here is my debug information:

{

# tcpdump -tlnvv -i em0 port 514
tcpdump: listening on em0, link-type EN10MB (Ethernet), capture size 96 
bytes
IP (tos 0x0, ttl 255, id 337, offset 0, flags [none], proto UDP (17), 
length 122)

192.168.1.1.59189  192.168.1.120.514: SYSLOG, length: 94
Facility local7 (23), Severity debug (7)
Msg: 10040: 010027: Nov 19 10:28:04.322: ISAKMP:(0): S[|syslog]
IP (tos 0x0, ttl 255, id 338, offset 0, flags [none], proto UDP (17), 
length 122)

192.168.1.1.59189  192.168.1.120.514: SYSLOG, length: 94
Facility local7 (23), Severity debug (7)
Msg: 10041: 010028: Nov 19 10:28:04.326: ISAKMP:(0): S[|syslog]
IP (tos 0x0, ttl 255, id 339, offset 0, flags [none], proto UDP (17), 
length 142)

192.168.1.1.59189  192.168.1.120.514: SYSLOG, length: 114
Facility local7 (23), Severity notice (5)
Msg: 10042: 010029: Nov 19 10:28:04.770: %SYS-5-CONFIG[|syslog]
IP (tos 0x0, ttl 255, id 340, offset 0, flags [none], proto UDP (17), 
length 122)

192.168.1.1.59189  192.168.1.120.514: SYSLOG, length: 94
Facility local7 (23), Severity debug (7)
Msg: 10043: 010030: Nov 19 10:30:30.672: ISAKMP:(0): S[|syslog]
IP (tos 0x0, ttl 255, id 341, offset 0, flags [none], proto UDP (17

Re: Syslog server not logging remote machines to file?

2011-11-19 Thread Robert Bonomi


Kaya Saman kayasa...@gmail.com wrote:

 Hi,

 I've got a really strange problem which seems to either be a bug with 
 the syslog server service or perhaps because I'm running jails on my 
 system.

 I can log my router syslog information but somehow the syslog server 
 doesn't put the information into the designated file; which should be 
 /var/log/cisco857w.log???


The -usual- 'gotcha' for this situation is that you have to _create_ the 
file FIRST, and then tell syslogd to reload it's configuration.  (i.e. 
'kill -HUP' the PID for syslogd)


___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: Syslog server not logging remote machines to file?


On 11/19/2011 05:21 PM, Robert Bonomi wrote:

Kaya Samankayasa...@gmail.com  wrote:

Hi,

I've got a really strange problem which seems to either be a bug with
the syslog server service or perhaps because I'm running jails on my
system.

I can log my router syslog information but somehow the syslog server
doesn't put the information into the designated file; which should be
/var/log/cisco857w.log???


The -usual- 'gotcha' for this situation is that you have to _create_ the
file FIRST, and then tell syslogd to reload it's configuration.  (i.e.
'kill -HUP' the PID for syslogd)


That's ok, however due to me running syslogd in debug mode anyway - ctrl 
+ c should do that anyway. I performed a: ps aux | grep syslog with 
no result other then my 'grepping' displayed.


Meaning that the syslog daemon should have reloaded right? - I mean it's 
standard for everything else which works in that way!

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: Syslog server not logging remote machines to file?

On 11/19/2011 06:52 PM, Robert Bonomi wrote:

 From kayasa...@gmail.com  Sat Nov 19 09:33:08 2011
Date: Sat, 19 Nov 2011 17:31:50 +0200
From: Kaya Samankayasa...@gmail.com
To: Robert Bonomibon...@mail.r-bonomi.com
CC: freebsd-questions@freebsd.org
Subject: Re: Syslog server not logging remote machines to file?

On 11/19/2011 05:21 PM, Robert Bonomi wrote:

Kaya Samankayasa...@gmail.com   wrote:

Hi,

I've got a really strange problem which seems to either be a bug with
the syslog server service or perhaps because I'm running jails on my
system.

I can log my router syslog information but somehow the syslog server
doesn't put the information into the designated file; which should be
/var/log/cisco857w.log???

The -usual- 'gotcha' for this situation is that you have to _create_ the
file FIRST, and then tell syslogd to reload it's configuration.  (i.e.
'kill -HUP' the PID for syslogd)

That's ok, however due to me running syslogd in debug mode anyway - ctrl
+ c should do that anyway. I performed a: ps aux | grep syslog with
no result other then my 'grepping' displayed.

Meaning that the syslog daemon should have reloaded right? - I mean it's
standard for everything else which works in that way!

Well if ps -aux doesn't show any syslogd entry, then syslogd is -not-
running -- which would explain why it's not logging anything to the file :)

If you're stopping and restarting syslogd, then, yes, that causes it to
re-read the configuration.

This begs the question, however, *DOES* that file exist?  syslog does _not_
_create_ a missing logfile, just because it is mentioned in the syslog.conf
file.
g

Robert,

I can assure that syslogd is running, hence the logging posted within my 
first email to the list. When run with the -d and -vv flags set in 
/etc/rc.conf I need to use ctrl +c to break out of it as it logs 
directly to the tty.

Just to go over it again, output from syslogd with -d and -vv flags set 
running in debug mode shows:

{

logmsg: pri 56, flags 4, from Server, msg syslogd: restart
syslogd: restarted
logmsg: pri 6, flags 4, from Server, msg syslogd: kernel boot file is 
/boot/kernel/kernel

Logging to FILE /var/log/messages
syslogd: kernel boot file is /boot/kernel/kernel
logmsg: pri 166, flags 17, from Server, msg Nov 19 12:33:34 syslog.err 
Server syslogd: exiting on signal 2

cvthname(192.168.1.1)
validate: dgram from IP 192.168.1.1, port 59189, name router.domain;
accepted in rule 0.
logmsg: pri 275, flags 0, from cisco857w, msg 10048: 010035: Nov 19 
10:33:48.037: %SYS-5-CONFIG_I: Configured from console by admin on vty0 
(192.168.1.120)

}

The file is mentioned in syslogd config and seems to be loaded within 
the configuration:

{

cfline(*.*/var/log/cisco857w.log, f, *, 
+192.168.1.1)

7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 X FILE: 
/var/log/cisco857w.log

}

The file *has* been created also under /var/log/ dir however self 
creation is possible using the -C flag within /etc/rc.conf file; and 
give 'appropriate' permission 600:

{

# ls -l /var/log | grep cisco857
-rw---  1 root   wheel 0 Nov 18 16:32 cisco857w.log

}

So after all this looks {**perfect**} what can this mysterious problem be??

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: Syslog server not logging remote machines to file?




cvthname(192.168.1.1)
validate: dgram from IP 192.168.1.1, port 59189, name router.domain;
accepted in rule 0.
logmsg: pri 275, flags 0, from cisco857w, msg 10048: 010035: Nov 19
10:33:48.037: %SYS-5-CONFIG_I: Configured from console by admin on vty0
(192.168.1.120)

If we take the 'priority' of that message at face value,
   it is a facility value of 34
   and a logging priority of  3

On the machines I have access to, facility values stop at _24_.

The message may be being discarded because of a 'nonsense' priority.


I changed the 'facility' value within the IOS itself to kernel:

(config)#logging facility kern

- and now the generated message shows this:

accepted in rule 0.
logmsg: pri 15, flags 0, from cisco857w, msg 10146: 010133: Nov 19 
23:05:54.538: %SYS-5-CONFIG_I: Configured from console by admin on vty0 
(192.168.0.53



still not logging to file though :-( ??




The file is mentioned in syslogd config and seems to be loaded within
the configuration:

{

cfline(*.*/var/log/cisco857w.log, f, *,
+192.168.1.1)

7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 X FILE:
/var/log/cisco857w.log

_THAT_ lookks like only _24_ known 'facility' values.


# ls -l /var/log | grep cisco857
-rw---  1 root   wheel 0 Nov 18 16:32 cisco857w.log

And, I presume that when you are invoking syslogd in 'debug' mode, you
are running as superuser.


Yep, that is correct! Am using: su -


So after all this looks {**perfect**} what can this mysterious problem be??


I'm _guessing_ that the apparent 'facility' value of 34 is a good candidate.





___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: System randomly not logging complete bi-directional traffic.

2011-10-23 Thread freebsd_user


Thanks for everyone's patients.  In reply to Michael asking about the rule
set used; the issue happens without ipfw.

We temporarily employed ipfw to help and confirm whether traffic was in
fact coming into port 80 and while randomly not being logged or seen by
FreeBSD's syslogd, or by the web server.

It became more of a concern when both tshark and tcpdump are seen
capturing the traffic in both directions, yet the web server nor syslogd
(before using ipfw), were found to randomly not log certain incoming
traffic to port 80; as can be seen by the sample provided in the beginning
of this thread.

So, to be perfectly clear, with or without ipfw this logging issue remains.

 Sorry to have missed your prior post - please include the entire
 ruleset.  Thanks.

 On Sun, Oct 9, 2011 at 10:28 AM,  freebsd_u...@guice.ath.cx wrote:
 freebsd-questions@freebsd.org
 #
 #
 # FreeBSD_7-4 RELEASE
 # Our hardware is pristine
 #
 # What is described herein are regular, yet random occurrences; we need
 help.

 We have already performed a reinstall of FreeBSD_7-4 RELEASE (and the
 daemons in question); the issue remains. Below, is part of a
 conversation
 with an httpd whereby the packets (entire conversations) are randomly
 'not' being logged and/or seen by either the httpd nor ipfw (logging
 enabled), yet both tshark and tcpdump are capturing everything.

 To be perfectly clear, httpd and ipfw (randomly) will not see/log
 anything
 of an 'entire conversation'.  It is not like it drops certain packets of
 a
 conversation; they (httpd/ipfw) either see and log everything during a
 conversation, or, 'do not see' and 'do not log' any packet associated
 with
 a given conversation; all the while tshark and tcpdump are capturing
 everything (bidirectional); hence the connection is real.

 The capture below was witnessed by both tshark and tcpdump, but not
 logged
 via the httpd or the following ipfw rule:

 $cmd 00029 deny log logamount 0 ip from table(1) to me 80

 The above ipfw rule functions properly from table(1) which contains --
 ip.ip.ip.ip/32 -- one (1) ip per line.

 The names (below) were changed to protect the innocent; yeah right.

 Internet Protocol Version 4, Src: ex.ter.nal.ip (ex.ter.nal.ip), Dst:
 in.ter.nal.ip (in.ter.nal.ip)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00:
 Not-ECT (Not ECN-Capable Transport))
         00.. = Differentiated Services Codepoint: Default (0x00)
 
 ..00 = Explicit Congestion Notification: Not-ECT (Not
 ECN-Capable Transport) (0x00)
    Total Length: 60
    Identification: 0x8ce5 (36069)
    Flags: 0x02 (Don't Fragment)
        0...  = Reserved bit: Not set
        .1..  = Don't fragment: Set
        ..0.  = More fragments: Not set
    Fragment offset: 0
    Time to live: 251
    Protocol: TCP (6)
    Header checksum: 0x9102 [correct]
        [Good: True]
        [Bad: False]
    Source: ex.ter.nal.ip (ex.ter.nal.ip)
    Destination: in.ter.nal.ip (in.ter.nal.ip)
 Transmission Control Protocol, Src Port: 46463 (46463), Dst Port: http
 (80), Seq: 0, Len: 0
    Source port: 46463 (46463)
    Destination port: http (80)
    [Stream index: 19]
    Sequence number: 0    (relative sequence number)
    Header length: 40 bytes
    Flags: 0x02 (SYN)
        000.   = Reserved: Not set
        ...0   = Nonce: Not set
         0...  = Congestion Window Reduced (CWR): Not set
         .0..  = ECN-Echo: Not set
         ..0.  = Urgent: Not set
         ...0  = Acknowledgement: Not set
          0... = Push: Not set
          .0.. = Reset: Not set
          ..1. = Syn: Set
            [Expert Info (Chat/Sequence): Connection establish request
 (SYN): server port http]
                [Message: Connection establish request (SYN): server port
 http]
                [Severity level: Chat]
                [Group: Sequence]
          ...0 = Fin: Not set
    Window size value: 5840
    [Calculated window size: 5840]
    Checksum: 0xe7f8 [validation disabled]
        [Good Checksum: False]
        [Bad Checksum: False]
    Options: (20 bytes)
        Maximum segment size: 1460 bytes
        TCP SACK Permitted Option: True
        Timestamps: TSval 309029146, TSecr 0
            Kind: Timestamp (8)
            Length: 10
            Timestamp value: 309029146
            Timestamp echo reply: 0
        No-Operation (NOP)
        Window scale: 7 (multiply by 128)
            Kind: Window Scale (3)
            Length: 3
            Shift count: 7
            [Multiplier: 128]
    Frame Number: 51
    Frame Length: 74 bytes (592 bits)
    Capture Length: 74 bytes (592 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ip:tcp]
 Ethernet II, Src: Router_cf:gr:f0 (11:52:c3:fd:dd:f0), Dst: Goe_40:84:21
 (00:15:18:40:28:41)
    Destination: Goe_40:84:21 (00:15:18:40:28:41)
        Address: Goe_40:84:21 (00

System randomly not logging complete bi-directional traffic.

2011-10-09 Thread freebsd_user

freebsd-questions@freebsd.org
#
#
# FreeBSD_7-4 RELEASE
# Our hardware is pristine
#
# What is described herein are regular, yet random occurrences; we need help.

We have already performed a reinstall of FreeBSD_7-4 RELEASE (and the
daemons in question); the issue remains. Below, is part of a conversation
with an httpd whereby the packets (entire conversations) are randomly
'not' being logged and/or seen by either the httpd nor ipfw (logging
enabled), yet both tshark and tcpdump are capturing everything.

To be perfectly clear, httpd and ipfw (randomly) will not see/log anything
of an 'entire conversation'.  It is not like it drops certain packets of a
conversation; they (httpd/ipfw) either see and log everything during a
conversation, or, 'do not see' and 'do not log' any packet associated with
a given conversation; all the while tshark and tcpdump are capturing
everything (bidirectional); hence the connection is real.

The capture below was witnessed by both tshark and tcpdump, but not logged
via the httpd or the following ipfw rule:

$cmd 00029 deny log logamount 0 ip from table(1) to me 80

The above ipfw rule functions properly from table(1) which contains --
ip.ip.ip.ip/32 -- one (1) ip per line.

The names (below) were changed to protect the innocent; yeah right.

Internet Protocol Version 4, Src: ex.ter.nal.ip (ex.ter.nal.ip), Dst:
in.ter.nal.ip (in.ter.nal.ip)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00:
Not-ECT (Not ECN-Capable Transport))
 00.. = Differentiated Services Codepoint: Default (0x00) 
..00 = Explicit Congestion Notification: Not-ECT (Not
ECN-Capable Transport) (0x00)
Total Length: 60
Identification: 0x8ce5 (36069)
Flags: 0x02 (Don't Fragment)
0...  = Reserved bit: Not set
.1..  = Don't fragment: Set
..0.  = More fragments: Not set
Fragment offset: 0
Time to live: 251
Protocol: TCP (6)
Header checksum: 0x9102 [correct]
[Good: True]
[Bad: False]
Source: ex.ter.nal.ip (ex.ter.nal.ip)
Destination: in.ter.nal.ip (in.ter.nal.ip)
Transmission Control Protocol, Src Port: 46463 (46463), Dst Port: http
(80), Seq: 0, Len: 0
Source port: 46463 (46463)
Destination port: http (80)
[Stream index: 19]
Sequence number: 0(relative sequence number)
Header length: 40 bytes
Flags: 0x02 (SYN)
000.   = Reserved: Not set
...0   = Nonce: Not set
 0...  = Congestion Window Reduced (CWR): Not set
 .0..  = ECN-Echo: Not set
 ..0.  = Urgent: Not set
 ...0  = Acknowledgement: Not set
  0... = Push: Not set
  .0.. = Reset: Not set
  ..1. = Syn: Set
[Expert Info (Chat/Sequence): Connection establish request
(SYN): server port http]
[Message: Connection establish request (SYN): server port
http]
[Severity level: Chat]
[Group: Sequence]
  ...0 = Fin: Not set
Window size value: 5840
[Calculated window size: 5840]
Checksum: 0xe7f8 [validation disabled]
[Good Checksum: False]
[Bad Checksum: False]
Options: (20 bytes)
Maximum segment size: 1460 bytes
TCP SACK Permitted Option: True
Timestamps: TSval 309029146, TSecr 0
Kind: Timestamp (8)
Length: 10
Timestamp value: 309029146
Timestamp echo reply: 0
No-Operation (NOP)
Window scale: 7 (multiply by 128)
Kind: Window Scale (3)
Length: 3
Shift count: 7
[Multiplier: 128]
Frame Number: 51
Frame Length: 74 bytes (592 bits)
Capture Length: 74 bytes (592 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ip:tcp]
Ethernet II, Src: Router_cf:gr:f0 (11:52:c3:fd:dd:f0), Dst: Goe_40:84:21
(00:15:18:40:28:41)
Destination: Goe_40:84:21 (00:15:18:40:28:41)
Address: Goe_40:84:21 (00:15:18:40:28:41)
 ...0     = IG bit: Individual address
(unicast)
 ..0.     = LG bit: Globally unique address
(factory default)
Source: Router_cf:gr:f0 (11:52:c3:fd:dd:f0)
Address: Router_cf:gr:f0 (11:52:c3:fd:dd:f0)
 ...0     = IG bit: Individual address
(unicast)
 ..0.     = LG bit: Globally unique address
(factory default)
Type: IP (0x0800)
Internet Protocol Version 4, Src: ex.ter.nal.ip (ex.ter.nal.ip), Dst:
in.ter.nal.ip (in.ter.nal.ip)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00:
Not-ECT (Not ECN-Capable Transport))
 00.. = Differentiated Services Codepoint: Default (0x00) 
..00 = Explicit Congestion Notification: Not-ECT (Not
ECN-Capable Transport

Re: System randomly not logging complete bi-directional traffic.

2011-10-09 Thread Michael Sierchio

Sorry to have missed your prior post - please include the entire
ruleset.  Thanks.

On Sun, Oct 9, 2011 at 10:28 AM,  freebsd_u...@guice.ath.cx wrote:
 freebsd-questions@freebsd.org
 #
 #
 # FreeBSD_7-4 RELEASE
 # Our hardware is pristine
 #
 # What is described herein are regular, yet random occurrences; we need help.

 We have already performed a reinstall of FreeBSD_7-4 RELEASE (and the
 daemons in question); the issue remains. Below, is part of a conversation
 with an httpd whereby the packets (entire conversations) are randomly
 'not' being logged and/or seen by either the httpd nor ipfw (logging
 enabled), yet both tshark and tcpdump are capturing everything.

 To be perfectly clear, httpd and ipfw (randomly) will not see/log anything
 of an 'entire conversation'.  It is not like it drops certain packets of a
 conversation; they (httpd/ipfw) either see and log everything during a
 conversation, or, 'do not see' and 'do not log' any packet associated with
 a given conversation; all the while tshark and tcpdump are capturing
 everything (bidirectional); hence the connection is real.

 The capture below was witnessed by both tshark and tcpdump, but not logged
 via the httpd or the following ipfw rule:

 $cmd 00029 deny log logamount 0 ip from table(1) to me 80

 The above ipfw rule functions properly from table(1) which contains --
 ip.ip.ip.ip/32 -- one (1) ip per line.

 The names (below) were changed to protect the innocent; yeah right.

 Internet Protocol Version 4, Src: ex.ter.nal.ip (ex.ter.nal.ip), Dst:
 in.ter.nal.ip (in.ter.nal.ip)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00:
 Not-ECT (Not ECN-Capable Transport))
         00.. = Differentiated Services Codepoint: Default (0x00) 
 ..00 = Explicit Congestion Notification: Not-ECT (Not
 ECN-Capable Transport) (0x00)
    Total Length: 60
    Identification: 0x8ce5 (36069)
    Flags: 0x02 (Don't Fragment)
        0...  = Reserved bit: Not set
        .1..  = Don't fragment: Set
        ..0.  = More fragments: Not set
    Fragment offset: 0
    Time to live: 251
    Protocol: TCP (6)
    Header checksum: 0x9102 [correct]
        [Good: True]
        [Bad: False]
    Source: ex.ter.nal.ip (ex.ter.nal.ip)
    Destination: in.ter.nal.ip (in.ter.nal.ip)
 Transmission Control Protocol, Src Port: 46463 (46463), Dst Port: http
 (80), Seq: 0, Len: 0
    Source port: 46463 (46463)
    Destination port: http (80)
    [Stream index: 19]
    Sequence number: 0    (relative sequence number)
    Header length: 40 bytes
    Flags: 0x02 (SYN)
        000.   = Reserved: Not set
        ...0   = Nonce: Not set
         0...  = Congestion Window Reduced (CWR): Not set
         .0..  = ECN-Echo: Not set
         ..0.  = Urgent: Not set
         ...0  = Acknowledgement: Not set
          0... = Push: Not set
          .0.. = Reset: Not set
          ..1. = Syn: Set
            [Expert Info (Chat/Sequence): Connection establish request
 (SYN): server port http]
                [Message: Connection establish request (SYN): server port
 http]
                [Severity level: Chat]
                [Group: Sequence]
          ...0 = Fin: Not set
    Window size value: 5840
    [Calculated window size: 5840]
    Checksum: 0xe7f8 [validation disabled]
        [Good Checksum: False]
        [Bad Checksum: False]
    Options: (20 bytes)
        Maximum segment size: 1460 bytes
        TCP SACK Permitted Option: True
        Timestamps: TSval 309029146, TSecr 0
            Kind: Timestamp (8)
            Length: 10
            Timestamp value: 309029146
            Timestamp echo reply: 0
        No-Operation (NOP)
        Window scale: 7 (multiply by 128)
            Kind: Window Scale (3)
            Length: 3
            Shift count: 7
            [Multiplier: 128]
    Frame Number: 51
    Frame Length: 74 bytes (592 bits)
    Capture Length: 74 bytes (592 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ip:tcp]
 Ethernet II, Src: Router_cf:gr:f0 (11:52:c3:fd:dd:f0), Dst: Goe_40:84:21
 (00:15:18:40:28:41)
    Destination: Goe_40:84:21 (00:15:18:40:28:41)
        Address: Goe_40:84:21 (00:15:18:40:28:41)
         ...0     = IG bit: Individual address
 (unicast)
         ..0.     = LG bit: Globally unique address
 (factory default)
    Source: Router_cf:gr:f0 (11:52:c3:fd:dd:f0)
        Address: Router_cf:gr:f0 (11:52:c3:fd:dd:f0)
         ...0     = IG bit: Individual address
 (unicast)
         ..0.     = LG bit: Globally unique address
 (factory default)
    Type: IP (0x0800)
 Internet Protocol Version 4, Src: ex.ter.nal.ip (ex.ter.nal.ip), Dst:
 in.ter.nal.ip (in.ter.nal.ip)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN

maildrop logging overwriting instead of appending

Ok, I finally took the plunge today and converted my .procmailrc into
a .mailfilter, adjusted my .forward file, and am now, for the most
part, a contented new maildrop user.  :-)

Just one problem: on each invocation of maildrop, the logfile is being
overwritten, rather than appended to.

I have the following in my .mailfilter file (this is outside of any
specific filtering rule):

logfile Mail/maildrop.log

I can't see anything else anywhere in the maildrop docs that might
affect the way the logfile is handled.  According to the manpage, if
the logfile already exists, it should be appended to, but this isn't
what's happening.

Clues, anyone?

-- 
Conrad J. Sabatier
conr...@cox.net
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: maildrop logging overwriting instead of appending

2011-09-30 Thread Warren Block


On Fri, 30 Sep 2011, Conrad J. Sabatier wrote:


Ok, I finally took the plunge today and converted my .procmailrc into
a .mailfilter, adjusted my .forward file, and am now, for the most
part, a contented new maildrop user.  :-)

Just one problem: on each invocation of maildrop, the logfile is being
overwritten, rather than appended to.

I have the following in my .mailfilter file (this is outside of any
specific filtering rule):

logfile Mail/maildrop.log


Maybe use an absolute path like ~/Mail/maildrop.log or 
$HOME/Mail/maildrop.log?

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: maildrop logging overwriting instead of appending

On Fri, 30 Sep 2011 18:16:17 -0600 (MDT)
Warren Block wbl...@wonkity.com wrote:

 On Fri, 30 Sep 2011, Conrad J. Sabatier wrote:
 
  Ok, I finally took the plunge today and converted my .procmailrc
  into a .mailfilter, adjusted my .forward file, and am now, for the
  most part, a contented new maildrop user.  :-)
 
  Just one problem: on each invocation of maildrop, the logfile is
  being overwritten, rather than appended to.
 
  I have the following in my .mailfilter file (this is outside of any
  specific filtering rule):
 
  logfile Mail/maildrop.log
 
 Maybe use an absolute path like ~/Mail/maildrop.log or 
 $HOME/Mail/maildrop.log?

Well, I'll try that.  The Mail/maildrop.log *is* being written to, but
I've only seen at most a single delivery noted in it each time I've
looked.  Kinda weird.

Let me see if an absolute path will somehow make a difference...

-- 
Conrad J. Sabatier
conr...@cox.net
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: maildrop logging overwriting instead of appending

On Fri, 30 Sep 2011 20:31:36 -0500
Conrad J. Sabatier conr...@cox.net wrote:

 On Fri, 30 Sep 2011 18:16:17 -0600 (MDT)
 Warren Block wbl...@wonkity.com wrote:
 
  On Fri, 30 Sep 2011, Conrad J. Sabatier wrote:
  
   Just one problem: on each invocation of maildrop, the logfile is
   being overwritten, rather than appended to.
  
   I have the following in my .mailfilter file (this is outside of
   any specific filtering rule):
  
   logfile Mail/maildrop.log
  
  Maybe use an absolute path like ~/Mail/maildrop.log or 
  $HOME/Mail/maildrop.log?
 
 Well, I'll try that.  The Mail/maildrop.log *is* being written to, but
 I've only seen at most a single delivery noted in it each time I've
 looked.  Kinda weird.

Let me correct that: I'm seeing the deliveries for a single instance of
maildrop only each time, not necessarily just a single delivery.

 Let me see if an absolute path will somehow make a difference...

Well, that didn't have any effect.  Just tried using:

logfile ${HOME}/Mail/maildrop.log

Same behavior.  This is really odd.   Maybe I'll try rebuilding/
reinstalling maildrop.  May be some quirk related to having built it
under 9.0-BETA2 and then running it now under 9.0-BETA3?  Who
knows?  :-)

Anyway, like I just mentioned in #bsdports a few minutes ago, maildrop
is already working so well, I hardly even need any logging.  But I'd
still like to clear up this mystery.  I hate things like this!  :-)

As an aside to anyone still hesitant to convert from procmail to
maildrop:

Fear not!  It's a remarkably easy transition, and the .mailfilter
syntax is *so* much less arcane than procmail's.  A real breath of
fresh air, if I do say so.  :-)

-- 
Conrad J. Sabatier
conr...@cox.net
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

Re: maildrop logging overwriting instead of appending