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]"
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
