Re: Daily security report oddity...
On Wed, Sep 2, 2009 at 10:03, Dan Nelson wrote: > In the last episode (Sep 02), Kurt Buff said: >> 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"
Re: Daily security report oddity...
In the last episode (Sep 02), Kurt Buff said: > On Wed, Sep 2, 2009 at 00:23, Mark Stapper 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 00:23, Mark Stapper 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...
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
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
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]"
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
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]"
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]"
Re: Security Report
On Mon, Jan 13, 2003 at 11:32:00AM +, Rus Foster wrote: > 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 There are any number of tools to help you eliminate vulnerabilities and generally harden up your system. With FreeBSD you're starting from a pretty good base already, and just applying common sense will go a long way towards keeping you clear. However, these are untrusting times and there are a number of extra measures that you can certainly take. i) Read the security(7) man page. ii) Eliminate any services, network daemons etc. that you may have enabled, but that you aren't using. Make sure that you can account for all of the entries in the output of 'netstat -a'. Install 'nmap' from ports and scan your host at regular intervals. Even better, if you can swing it, is to get a friend to scan your host from a remote location. For those network services you need to supply, configure them on the basis of 'least privilege' --- ie. deny all access by default and only open up sufficient for authorised uses. Run servers as unprivileged users and use chroot(8) and jail(8) to limit your exposure even if a server is compromised. Choose software packages with a good reputation for security. Learn about ipfw(8) or ipf(8) and hosts_options(5) as well as any server specific configuration options. It's a good idea to defend in depth -- configure your servers strictly even if you also have a firewall ruleset that does an equivalent job. After all, mistakes happen and this way, you should be several steps away from disaster. iii) If you're giving out or selling login accounts (including to things like web sites or ftp accounts) to other users, sit down and write an acceptable usage policy detailing what is, and is not permissible to do from your machine and the penalties incurred for infraction. Get all your users to agree and sign off on this policy. Then enforce it strictly. Make sure that login messages (like /etc/issue (see gettytab(5)), /etc/motd, etc/ftpwelcome) can't be construed as an invitation to hack into your machine. iv) Proper, on-going maintainance of the system is vital for ensuring security. It's just not possible to spend a few days securing a machine and then have it be 'secure' for ever after. Keep up to date with security advisories. Update machines regularly. Clean out old software installations or user accounts that are now surplus to requirements. v) Your best defense is useless if the black hats can sneak in under your guard and do nefarious things without your noticing. Develop a nasty, suspicious character. Make sure that any and all activities of a potentially sensitive nature result in log file entries or some other form of audit trail. Paranoia is good. Think about using intrusion detection systems such as snort. Monitor your filesystems for suspicious changes --- tools like tripwire are invaluable for detecting trojans and root kits. System logs make good bedtime reading. vi) Eschew plaintext. ssh(1) is your friend. Avoid plain telnet or rsh. Remember that remote X sessions are easy to snoop as well: employ ssh's ability to pass X protocol data through an encrypted tunnel. vii) Remember that there is no such thing as absolute security. A clever enough and sufficiently determined attacker will always be able to beat you. (What would you do if a couple of thugs broke into your house and began breaking your fingers until you told them the root password?) Be measured in the policies you adopt. Weigh up the value of what you are trying to protect and the cost --- not just financial, but in terms of aggravation to legitimate users --- of the security measures you impose. viii) And finally, take good backups and keep them in a secure, off-site location. Sleep well at night. 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
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
> -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
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
