Re: Daily security report oddity...
Kurt Buff wrote: I got a daily security run email from one of my machines on Monday morning, with the following entry: zmx1.zetron.com login failures: Aug 30 06:57:17 zmx1 su: BAD SU mlee to root on /dev/ttyp2 Aug 30 09:42:17 zmx1 su: BAD SU mlee to root on /dev/ttyp0 What's puzzling is that this account has been completely inactive for well over a year - this fellow is long gone, and I simply didn't clean it up - that's my bad, but that's not the puzzling part. I traced it down, and found out that he had not logged in on Sunday. The auth.log is, as you can see from the listing below, quite old. The entries referenced above are from two years ago. zmx1# ll /var/log/a* -rw--- 1 root wheel 71845 Sep 1 15:42 /var/log/auth.log -rw--- 1 root wheel 6087 Aug 29 2007 /var/log/auth.log.0.bz2 -rw--- 1 root wheel 5774 Aug 12 2007 /var/log/auth.log.1.bz2 -rw--- 1 root wheel 5795 Jul 24 2007 /var/log/auth.log.2.bz2 -rw--- 1 root wheel 6813 Jul 6 2007 /var/log/auth.log.3.bz2 So, a couple of questions: Why would the daily security run pick up something from *two years ago* and only report it again today? The machine hasn't been rebooted in a very long time, if that makes a difference. Is there any way to prevent something like this happening again - or perhaps can I force the entry of the year into the date field for the auth.log entries? 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 Hello, If you look at the syntax of the logfile, you will see no year is listed. Most likely the whole file is parsed on security run. Since the logfile has been rotated the 30th of august 2007, it's very much possible you'll get all your messages all over again. Perhaps it's wise to rotate you logfiles once a year just in case... And it make no difference the machine hasn't been rebooted in a very long time... (define very long time ;-) http://uptimes-project.org/hosts/view/150 ) signature.asc Description: OpenPGP digital signature
Re: Daily security report oddity...
On Wed, Sep 2, 2009 at 00:23, Mark Stapperst...@mapper.nl wrote: Kurt Buff wrote: I got a daily security run email from one of my machines on Monday morning, with the following entry: zmx1.zetron.com login failures: Aug 30 06:57:17 zmx1 su: BAD SU mlee to root on /dev/ttyp2 Aug 30 09:42:17 zmx1 su: BAD SU mlee to root on /dev/ttyp0 What's puzzling is that this account has been completely inactive for well over a year - this fellow is long gone, and I simply didn't clean it up - that's my bad, but that's not the puzzling part. I traced it down, and found out that he had not logged in on Sunday. The auth.log is, as you can see from the listing below, quite old. The entries referenced above are from two years ago. zmx1# ll /var/log/a* -rw--- 1 root wheel 71845 Sep 1 15:42 /var/log/auth.log -rw--- 1 root wheel 6087 Aug 29 2007 /var/log/auth.log.0.bz2 -rw--- 1 root wheel 5774 Aug 12 2007 /var/log/auth.log.1.bz2 -rw--- 1 root wheel 5795 Jul 24 2007 /var/log/auth.log.2.bz2 -rw--- 1 root wheel 6813 Jul 6 2007 /var/log/auth.log.3.bz2 So, a couple of questions: Why would the daily security run pick up something from *two years ago* and only report it again today? The machine hasn't been rebooted in a very long time, if that makes a difference. Is there any way to prevent something like this happening again - or perhaps can I force the entry of the year into the date field for the auth.log entries? Kurt Hello, If you look at the syntax of the logfile, you will see no year is listed. Most likely the whole file is parsed on security run. Since the logfile has been rotated the 30th of august 2007, it's very much possible you'll get all your messages all over again. Perhaps it's wise to rotate you logfiles once a year just in case... And it make no difference the machine hasn't been rebooted in a very long time... (define very long time ;-) http://uptimes-project.org/hosts/view/150 ) Heh. Well, for me a very long time is more than a year, because security patches for the OS will at some point mandate a reboot - and usually in less than a year. I suppose there's a way to do auth log rotation automagically - would that be sysutils/logrotate? 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: Daily security report oddity...
In the last episode (Sep 02), Kurt Buff said: On Wed, Sep 2, 2009 at 00:23, Mark Stapperst...@mapper.nl wrote: Kurt Buff wrote: I traced it down, and found out that he had not logged in on Sunday. The auth.log is, as you can see from the listing below, quite old. The entries referenced above are from two years ago. zmx1# ll /var/log/a* -rw--- 1 root wheel 71845 Sep 1 15:42 /var/log/auth.log -rw--- 1 root wheel 6087 Aug 29 2007 /var/log/auth.log.0.bz2 -rw--- 1 root wheel 5774 Aug 12 2007 /var/log/auth.log.1.bz2 -rw--- 1 root wheel 5795 Jul 24 2007 /var/log/auth.log.2.bz2 -rw--- 1 root wheel 6813 Jul 6 2007 /var/log/auth.log.3.bz2 So, a couple of questions: Why would the daily security run pick up something from *two years ago* and only report it again today? The machine hasn't been rebooted in a very long time, if that makes a difference. Is there any way to prevent something like this happening again - or perhaps can I force the entry of the year into the date field for the auth.log entries? If you look at the syntax of the logfile, you will see no year is listed. Most likely the whole file is parsed on security run. Since the logfile has been rotated the 30th of august 2007, it's very much possible you'll get all your messages all over again. Perhaps it's wise to rotate you logfiles once a year just in case... And it make no difference the machine hasn't been rebooted in a very long time... (define very long time ;-) http://uptimes-project.org/hosts/view/150 ) Heh. Well, for me a very long time is more than a year, because security patches for the OS will at some point mandate a reboot - and usually in less than a year. I suppose there's a way to do auth log rotation automagically - would that be sysutils/logrotate? The system already rotates auth.log. Just edit /etc/newsyslog.conf and add a date check to the line for auth.log. The default is to roll it when it hits 100KB, but if you add something like $M1D0 to the when column it'll rotate it monthly as well. -- Dan Nelson dnel...@allantgroup.com ___ 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: Daily security report oddity...
On Wed, Sep 2, 2009 at 10:03, Dan Nelsondnel...@allantgroup.com wrote: In the last episode (Sep 02), Kurt Buff said: snip Heh. Well, for me a very long time is more than a year, because security patches for the OS will at some point mandate a reboot - and usually in less than a year. I suppose there's a way to do auth log rotation automagically - would that be sysutils/logrotate? The system already rotates auth.log. Just edit /etc/newsyslog.conf and add a date check to the line for auth.log. The default is to roll it when it hits 100KB, but if you add something like $M1D0 to the when column it'll rotate it monthly as well. -- Dan Nelson dnel...@allantgroup.com That's exactly the clue I needed. Thanks, Dan. I'm looking at 'man newsyslog.conf' right now. 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
Daily security report oddity...
I got a daily security run email from one of my machines on Monday morning, with the following entry: zmx1.zetron.com login failures: Aug 30 06:57:17 zmx1 su: BAD SU mlee to root on /dev/ttyp2 Aug 30 09:42:17 zmx1 su: BAD SU mlee to root on /dev/ttyp0 What's puzzling is that this account has been completely inactive for well over a year - this fellow is long gone, and I simply didn't clean it up - that's my bad, but that's not the puzzling part. I traced it down, and found out that he had not logged in on Sunday. The auth.log is, as you can see from the listing below, quite old. The entries referenced above are from two years ago. zmx1# ll /var/log/a* -rw--- 1 root wheel 71845 Sep 1 15:42 /var/log/auth.log -rw--- 1 root wheel 6087 Aug 29 2007 /var/log/auth.log.0.bz2 -rw--- 1 root wheel 5774 Aug 12 2007 /var/log/auth.log.1.bz2 -rw--- 1 root wheel 5795 Jul 24 2007 /var/log/auth.log.2.bz2 -rw--- 1 root wheel 6813 Jul 6 2007 /var/log/auth.log.3.bz2 So, a couple of questions: Why would the daily security run pick up something from *two years ago* and only report it again today? The machine hasn't been rebooted in a very long time, if that makes a difference. Is there any way to prevent something like this happening again - or perhaps can I force the entry of the year into the date field for the auth.log entries? 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: Security report question
On 9/30/07, Ian Smith [EMAIL PROTECTED] wrote: On Sun, 30 Sep 2007 09:41:00 -0700 Kurt Buff [EMAIL PROTECTED] wrote: On 9/30/07, Chuck Swiger [EMAIL PROTECTED] wrote: Kurt Buff wrote: [ ... ] +Limiting closed port RST response from 283 to 200 packets/sec I don't know what this means, though I suspect it could mean that I'm being port scanned. Is this a reasonable guess? Yes. It could also be something beating really hard on a single closed port, too. -- -Chuck Thanks. This, coupled with some invalid SSH login attempts from a known user, has made me quite suspicious. I think, though, that this is all that I can call it at this point - suspcious. Anything further I could turn up to monitor/log what's going on? It may help in spotting unwanted stuff getting past your firewall, to either add to /etc/rc.conf: log_in_vain=1 or (coming to the same thing) add to /etc/sysctl.conf: net.inet.tcp.log_in_vain=1 net.inet.udp.log_in_vain=1 You can set the latter two sysctls immediately, of course. Cheers, Ian Looks like it's time to learn how to set up PF. This machine is internal to our enterprise, but in its own subnet separate from the server and the end-user subnets, between our firewall and our main router. The only ports open on it are SSH and SMTP, so I hadn't had the inclination, amongst all my other tasks, to set up that up. Handbook, here I come. Thanks for the help. Kurt ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Security report question
Kurt Buff wrote: [ ... ] +Limiting closed port RST response from 283 to 200 packets/sec I don't know what this means, though I suspect it could mean that I'm being port scanned. Is this a reasonable guess? Yes. It could also be something beating really hard on a single closed port, too. -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Security report question
On 9/30/07, Chuck Swiger [EMAIL PROTECTED] wrote: Kurt Buff wrote: [ ... ] +Limiting closed port RST response from 283 to 200 packets/sec I don't know what this means, though I suspect it could mean that I'm being port scanned. Is this a reasonable guess? Yes. It could also be something beating really hard on a single closed port, too. -- -Chuck Thanks. This, coupled with some invalid SSH login attempts from a known user, has made me quite suspicious. I think, though, that this is all that I can call it at this point - suspcious. Anything further I could turn up to monitor/log what's going on? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Security report question
On Sun, 30 Sep 2007 09:41:00 -0700 Kurt Buff [EMAIL PROTECTED] wrote: On 9/30/07, Chuck Swiger [EMAIL PROTECTED] wrote: Kurt Buff wrote: [ ... ] +Limiting closed port RST response from 283 to 200 packets/sec I don't know what this means, though I suspect it could mean that I'm being port scanned. Is this a reasonable guess? Yes. It could also be something beating really hard on a single closed port, too. -- -Chuck Thanks. This, coupled with some invalid SSH login attempts from a known user, has made me quite suspicious. I think, though, that this is all that I can call it at this point - suspcious. Anything further I could turn up to monitor/log what's going on? It may help in spotting unwanted stuff getting past your firewall, to either add to /etc/rc.conf: log_in_vain=1 or (coming to the same thing) add to /etc/sysctl.conf: net.inet.tcp.log_in_vain=1 net.inet.udp.log_in_vain=1 You can set the latter two sysctls immediately, of course. Cheers, Ian ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Security report question
I've noted in a security mail from one of my machines the following log entries: +++ /tmp/security.yEepp7hR Sat Sep 29 03:02:07 2007 +Limiting closed port RST response from 253 to 200 packets/sec +Limiting closed port RST response from 233 to 200 packets/sec +Limiting closed port RST response from 262 to 200 packets/sec +Limiting closed port RST response from 283 to 200 packets/sec I don't know what this means, though I suspect it could mean that I'm being port scanned. Is this a reasonable guess? Kurt ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
security report messages
Hi all, Receiving the following... I assume this is just because of a portupgrade that we did that tried to upgrade cyrus, and I assume this is the automated port account creation/deletion that it does but I wanted to run it by everyone. Jul 9 15:29:52 mercury saslpasswd: failed to set plaintext secret for cyrus: generic failure Jul 9 15:29:52 mercury saslpasswd: failed to set APOP secret for cyrus: generic failure Jul 9 15:29:52 mercury saslpasswd: PLAIN: failed to set secret for cyrus: generic failure Jul 9 15:29:52 mercury saslpasswd: failed to disable account for cyrus: user not found Jul 9 15:29:52 mercury saslpasswd: failed to disable APOP account for cyrus: user not found Jul 9 15:29:52 mercury saslpasswd: PLAIN: failed to set secret for cyrus: user not found Anything to be concerned about? Thanks, Matt ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Security Report
Hi, Is it my imagination or should FreeBSD automatically make run a cron job to generate a security report? If so does anyone have the cron line? Rgds Rus -- http://www.fsck.me.uk - My blog http://www.65535.net - $120 for a lifetime UNIX shell account To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
RE: Security Report
-Original Message- From: Rus Foster [mailto:[EMAIL PROTECTED]] Sent: Monday, January 13, 2003 13:17 To: [EMAIL PROTECTED] Subject: Security Report Hi, Is it my imagination or should FreeBSD automatically make run a cron job to generate a security report? If so does anyone have the cron line? daily_status_security_enable=YES is the default, from /etc/defaults/periodic.conf. If you didn't change that in /etc/periodic.conf it should run as a part of the periodic daily. The periodic daily line in /etc/crontab is (by default): 1 3 * * * rootperiodic daily To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Security Report
On Mon, Jan 13, 2003 at 11:16:50AM +, Rus Foster wrote: Is it my imagination or should FreeBSD automatically make run a cron job to generate a security report? If so does anyone have the cron line? No, you're not imagining things. See /etc/crontab for the invocation of the periodic(8) script. The security report is generated as part of the daily periodic job. If you aren't receiving the reports, check that a) they aren't piling up in some mail queue somewhere: # mailq -v # mailq -Ac -v or b) that the default settings in /etc/periodic.conf haven't been set to redirect the report output somewhere else. Look for the 'daily_status_security_enable', 'daily_status_security_inline' and 'daily_status_security_output' settings. If you haven't got a /etc/periodic.conf file that's OK, as you'll just end up using the default settings from /etc/defaults/periodic.conf Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks Savill Way PGP: http://www.infracaninophile.co.uk/pgpkey Marlow Tel: +44 1628 476614 Bucks., SL7 1TH UK To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Security Report
On Mon, 13 Jan 2003, Matthew Seaman wrote: On Mon, Jan 13, 2003 at 11:16:50AM +, Rus Foster wrote: Is it my imagination or should FreeBSD automatically make run a cron job to generate a security report? If so does anyone have the cron line? No, you're not imagining things. See /etc/crontab for the invocation of the periodic(8) script. The security report is generated as part of the daily periodic job. Thanks. Don;t suppose there is a tool to harden FreeBSD as well is there? I couldn't see anything in ports Rus To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
