Re: [CentOS] log monitoring and reporting software
After our security team completed POC testing from multiple vendors, we are in the process of implementing LogRhythm in our environment which includes 5000+ servers (Linux, Windows and Solaris). Len Date: Thu, 3 Mar 2011 15:00:53 +0100 From: postnali...@googlemail.com To: centos@centos.org Subject: Re: [CentOS] log monitoring and reporting software On Thu, Mar 3, 2011 at 2:46 PM, Les Mikesell wrote: On 3/3/11 3:12 AM, Janez Kosmrlj wrote: > Hi folks, > In the company where i work, we are implementing a security standard. A part > of > this is a log monitoring and reporting software. There are a few requirements, > that the software must fulfil: > - It must be capable of collecting logs from different devices (Linux > machines, > network equipment, ...). > - it must be capable of sending alarms on security events > - it has to generate daily (weekly, monthly) reports > - it's a plus if it is easy configurable > - it has to have a good support or at least a good community if it is an > opensource product > > So what are you using or at least some recommendations would be nice. An > opensource product would be nice, but it's not required. > > I know i could google it, but it's difficult to decide for a product just from > online and marketing presentations. It would be nice to get some real world > experience. OpenNMS is a good snmp monitoring framework with notification/reporting. It doesn't 'collect' logs but you can configure it to receive syslog from other machines and there are a variety of other ways you can pick up data. I'm not sure I'd call it easy to configure, but there are examples on their wiki. http://www.opennms.org -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos It has to collect logs from syslog (or similar service ), because one requirement for certification is "log history from all devices in one place". And since we are talking about 1500 devices it should be easy to configure and maintain. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] security cameras
> Date: Wed, 23 Feb 2011 10:30:56 -0500 > From: geb...@mousecar.com > To: centos@centos.org > Subject: Re: [CentOS] security cameras > > On 02/22/2011 09:02 PM B.J. McClure wrote: > > Not sure it will answer your question but there was an article in > > December 2010 issue of Linux Magazine re surveillance cameras and linux. > > > > HTH. > > > > B.J. > > > > > > BJ, I looked around Linux Mag's site for quite a while, did a couple > searches, and browsed the contents Dec 2010 and quite a few issues > before and after that, but couldn't find any article about selecting > and/or setting up surveillance cameras... except one on implementing > motion detection in cameras. Is that the one you were thinking of? > > Still, thanks much. I'll probably come back to that one later. If some > other info source comes to you, I'd be glad to hear about it. > > ___ > CentOS mailing list > CentOS@centos.org > http://lists.centos.org/mailman/listinfo/centos The article starts on page 30 of the December 2010 issue of Linux Magazine. The article is titled "Webcam Surveillance". Len ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] [Fwd: Re: iptables]
> Date: Thu, 29 Apr 2010 00:13:43 +0200 > From: gavro...@gavroche.pl > To: centos@centos.org > Subject: Re: [CentOS] [Fwd: Re: iptables] > > On Fri, Apr 23, 2010 at 06:08:45PM -0400, Robert Spangler wrote: > > On Friday 23 April 2010 15:20, cahit Eyigünlü wrote: > > > > > how or why i have redesigned it to this and it seems like worked : > > > > See big problems in your future. > > > > > :INPUT ACCEPT [0:0] > > > :FORWARD ACCEPT [0:0] > > > :OUTPUT ACCEPT [0:0] > > > > Anyone with a little bit of security awareness would never set the default > > policy to ACCEPT and the reason is below. You would think RH would know > > better. > > > > > -A INPUT -j RH-Firewall-1-INPUT > > > -A FORWARD -j RH-Firewall-1-INPUT > > > -A RH-Firewall-1-INPUT -i lo -j ACCEPT > > > -A RH-Firewall-1-INPUT -i eth0 -j ACCEPT > > > > With this rule above you just opened up you complete system to what ever it > > is > > connected to. That is why it is working. I am hoping this box doesn't > > have > > Internet access. > > > > > -A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT > > > -A RH-Firewall-1-INPUT -p 50 -j ACCEPT > > > -A RH-Firewall-1-INPUT -p 51 -j ACCEPT > > > -A RH-Firewall-1-INPUT -p udp --dport 5353 -d 224.0.0.251 -j ACCEPT > > > -A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT > > > -A RH-Firewall-1-INPUT -p tcp -m tcp --dport 631 -j ACCEPT > > > -A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT > > > -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 8443 -j > > > ACCEPT > > > -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j > > > ACCEPT > > > -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 25 -j > > > ACCEPT > > > -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j > > > ACCEPT > > > -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 21 -j > > > ACCEPT > > > "/etc/sysconfig/iptables" 40L, 1617C > > > > Even if you didn't have the line with '-i eth0 -j ACCEPT' you system was > > still > > open to everyone because at this point if none of the rules apply and the > > firewall falls back to the policy setting to decide what to do with a > > packet. > > Since all your policies are set to ACCEPT the packet is accepted and the > > hacker is in. > > > > For this reason one would think RH would do a little more and set the > > default > > policies to DROP. It is so easy to miss the reject or drop statements at > > the > > end and the policy would catch them for you. > > > > I know some will argue that RH did what they needed to do, but they could > > go > > that extra step don't you think. > > Absolutely agree with you. It would save us from threads like that > because people would need to read about iptables and stop to ask silly > questions. > > -- > Dominik Zyla > Setting the default policy to DROP is not always the best approach, especially if you do remote administration. What happens when you are connected remotely and execute: # iptables -F You are either jumping in the car to drive to the server or on the phone trying to reach someone local to assist because the default DROP policy just killed your session. In my opinion a better option for creating a default DROP policy is to add the following rule (INPUT chain in this example) as the last entry in a chain: -A INPUT -j DROP Now you have a chain that performs like one with a default DROP policy but does not kill your remote session if all rules are flushed. Len _ Hotmail is redefining busy with tools for the New Busy. Get more from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
