Symantec today announced the next version of Symantec Endpoint Protection. This release, version 12.1, will ship later this year. You can sign up for the beta at http://go.symantec.com/sep12beta/ .
Long in coming, this release is a major milestone. On the face of it, that statement is odd; after all, SEP is mature product and its feature set hasn't at a fundamental level, changed. It is still offers the critical elements of endpoint security, - malware protection, access control, device control, application control, firewall and IPS. It “kinda, sorta” looks like nothing has changed.
Well, don't believe it. There are countless new features in this release, and in subsequent blog posts I will dive into them. The real change, however, is under the covers and in the test results. SEP 12 is built on a powerful new stack of security technologies – which not only offer state-of-the-art protection, but which also position SEP to continue to provide great protection in a world with hundreds of millions, even billions of unique malicious programs.
Last year, Symantec identified 286 million different pieces of malware. Think about scanning each of the thousands of scanable objects on your computer for any one of 286 million malware signatures. Ok, the problem isn’t really that bad – that 286,000,000 figure represents mostly minor variants of a much smaller number of malware samples. But still, we are talking about over 10 million virus signatures.
Powered by Insight, SEP knows the reputation of up to 70% of the executables on your system – which means it need not scan those files unless they have changed. By reputation, I don’t just mean that we can identify bad files with signatures in the cloud (which, by the way, is the secret sauce behind McAfee’s Artemis/ Global Threat Intelligence technology). Insight does has something unique, well, 2 things. First, for every file we track (over 2.5 billion files), we have a security rating. Second, WE TRACK 2.5 BILLION FILES – 31 MILLION NEW FILES EVERY WEEK. Sorry for shouting, but that is a huge database. It is large enough that we can derive the context and the associations of the file – its "reputation" if you will, with great confidence. We are tracking the presence, age and security rating of nearly every executable on the internet. No-one else can do that. It is not even close.
Insight isn’t the only new security feature in SEP. The other half of the story is Sonar.
Sonar is an AI driven driven technology that tracks file behaviour in real time. Where older generations of heuristic scanners ran on file open/close/modify and on periodic scans, Sonar runs all the time – watching file behaviours and rating them on over 400 attributes.
The other big change in SEP is its enhanced support for virtualization. I look into the new virtualization technology in a later post.
You can see how effective SEP is in latest detection and performance test reports. We have posted them on the SEP Beta page - http://go.symantec.com/sep12beta/ . Take a look.
Vision
System Administrator's Corner....
Friday, March 18, 2011
Thursday, March 17, 2011
Restrict/Limit Users using (/etc/security/)
User limitations are set in the following files:
- File: /etc/security/limits.conf :
- core - limits the core file size (KB)
- data - max data size (KB)
- fsize - maximum filesize (KB)
- memlock - max locked-in-memory address space (KB)
- nofile - max number of open files
- rss - max resident set size (KB)
- stack - max stack size (KB)
- cpu - max CPU time (MIN)
- nproc - max number of processes
- as - address space limit
- maxlogins - max number of logins for this user
- priority - the priority to run user process with
- locks - max number of file locks the user can hold
- File: /etc/security/access.conf :
Limit access by network or local console logins.
- File: /etc/security/group.conf :
Grant/restrict group device access.
- File: /etc/security/time.conf :
Restrict user access by time, day.
System Monitor Commands
Basic command line:
pstree Processes and parent-child relationships top Show top processes iostat Report CPU statistics and input/output statistics for devices and partitions. ps -auxw process status uname -a print system information cat /proc/version Display Linux kernel version in use. cat /etc/redhat-release Display Red Hat Linux Release. (also /etc/issue) uptime Tell how long the system has been running. Also number of users and system's load average. w Show who is logged on and what they are doing. /sbin/lsmod List all currently loaded kernel modules.
Same as cat /proc/modules/sbin/runlevel Displays the system's current runlevel. hostname Displays/changes the system's node name. (Must also manually change hostname setting in /etc/sysconfig/network. Command will change entry in /etc/hosts) service Red Hat/Fedora command to display status of system services.
Example: service --status-all
Help: service --help
gnome-system-monitor Operating system monitor and usage graphing. gkrellm Graphical system monitor. (Additional RPM package: gkrellm) ps3 3D load meter. Very cool 3-D graphics. xosview Operating system monitor: load, memory, swap, net, disk, ...
Monday, March 14, 2011
Activating a VG when quorum is lost
Normally, volume groups are automatically activated during system startup. Unless you intentionally deactivate a volume group using vgchange, you will probably not need to reactivate a volume group.
However, LVM does require that a "quorum" of disks in a volume group be available. During normal system operation, LVM needs a quorum of more than half of the disks in a volume group for activation. If, during run time, a disk fails and causes quorum to be lost, LVM alerts you with a message to the console, but keeps the volume group active.
If there is no other way to make a quorum available, the -q option to the vgchange command will override the quorum check.
EXAMPLE:
vgchange -a y -q n /dev/vg01
When you replace a disk that was not online when you originally activated the volume group, use the activation command again to attach the now accessible disks to the volume group.
EXAMPLE:
vgchange -a y /dev/vg01
However, LVM does require that a "quorum" of disks in a volume group be available. During normal system operation, LVM needs a quorum of more than half of the disks in a volume group for activation. If, during run time, a disk fails and causes quorum to be lost, LVM alerts you with a message to the console, but keeps the volume group active.
If there is no other way to make a quorum available, the -q option to the vgchange command will override the quorum check.
EXAMPLE:
vgchange -a y -q n /dev/vg01
When you replace a disk that was not online when you originally activated the volume group, use the activation command again to attach the now accessible disks to the volume group.
EXAMPLE:
vgchange -a y /dev/vg01
Subscribe to:
Posts (Atom)