Get the LinuxSecurity news you want faster with RSS
Powered By
Security Tips
Need a quick security fix? Whether its sudo or lilo, tcp or icmp, you'll find short and straight-to-the point guidance in our listing of Security Tips.
A Unix-based tool: Lynis is an auditing tool which tests and gathers information from Unix based systems. The audience for this tool are security and system auditors, network specialists and system maintainers.
Lynis features
- System and security audit checks
- File Integrity Assessment
- System and file forensics
- Usage of templates/baselines (reporting and monitoring)
- Extended debugging features
Source: http://www.linuxhaxor.net - Posted by Ryan Berens
From Linuxhaxor.net, the top 3 tips: Are there any other tips you think should have been included or that you found to be true?
The following is a list of rules and tips you might find useful in dealing with basic security concerns:
1. Avoid doing your regular jobs when you are logged in as root. This reduces the risk of getting a cuckoo egg or a virus and protects you from your own mistakes.
2. If possible, always try to use encrypted connections to work on a remote machine. Using SSH (secure shell) to replace telnet, ftp, rsh, and rlogin should be standard practice.
3. Avoid using authentic method based on ip address alone.
An interesting and quick tip on how to fix a mail server error while running SELinux: Since I upgraded my server and activated SELinux I haven't gotten any emails from Wordpress when people post comments on this blog (that's why it has taken my so long time to approve comments). Today I decided it was time to look into the problem...
"Know your enemy." So the saying goes in all forms of the attacker/defender relationship. This article is an example of that. One of the most vulnerable forms of security is the password - many people have easy to duplicate passwords, companies often keep default passwords the same, and so on and so forth. Crackers can take advantage of this - especially if they have the right tools. And the better you know those tools, the better you can protect against them.
Do note there are also various tools to generate wordlists for brute forcing based on information gathered such as documents and web pages (such as Wyd - password profiling tool) These are useful resources that can add unique words that you might not have if your generic lists.
A great find (from NixCraft) for a quick overview on the available programs to detect and check for rookits on your machine:
A rootkit is a program (or combination of several programs) designed to take fundamental control (in Unix terms "root" access, in Windows terms "Administrator" access) of a computer system, without authorization by the system’s owners and legitimate managers.
A quick dose of Linux Security advice from Dan Walsh:
He was asked: I have switched the user role of an existing account to xguest_u thus enabling kiosk mode for this specific user. Works like a charm, thanks. Now i only need to permit ssh access.
And later:
Working towards true Least privilege is a noble goal, but with potentially a large increase in complexity.
Here, Erik Johansson goes into upgrading his standard Debian set-up to Debian-Etch. He goes on to say:
After upgrading my server (from Debian Sarge to Debian Etch) I decided to enabled SELinux. After reading some documentation (besides Debian's basic setup documentation I can recommend Fedora's SELinux wiki and especially this presentation) I got the basic setup working. Getting Subversion to fully work required a few extra steps. For your convenience and my memory I've listed them below...
It's a great, short HOWTO on upgrading your system with SELinux, what to look for, and how to get it all up and running.
Thankfully, you can help avoid it reaching your client by using the power of Postfix to run your mail. Sendmail, Qmail and others provide mail, sure, but limiting false positives, avoiding server overloads, and establishing a good defense is just plain better with Postfix.
Whether you like gray listing, want to configure black lists, or want a step-by-step on setting up secure mail - this is a great, quick overview.
The dictionary defines "proxy" as "the authority or power to act on behalf of another". This pretty well describes software proxies as well. It is an intermediary in the connection path. As an example, if we were using a web proxy like "squid" (http://www.squid-cache.org/), every time we browse to a web site, we would actually be connecting to our locally running squid server. Squid in turn, would relay our request to the ultimate, real destination. And then squid would relay the web pages back to us. It is a go-between. Like "firewalls", a "proxy" can refer to either a specific application, or a dedicated server which runs a proxy application.
Proxies can perform various duties, not all of which have much to do with security. But the fact that they are an intermediary, makes them a good place to enforce access control policies, limit direct connections through a firewall, and control how the network behind the proxy looks to the Internet. So this makes them strong candidates to be part of an overall firewall strategy. And, in fact, are sometimes used instead of packet filtering firewalls. Proxy based firewalls probably make more sense where many users are behind the same firewall. And it probably is not high on the list of components necessary for home based systems.
Configuring and administering proxies can be complex, and is beyond the scope of this document. The Firewall and Proxy Server HOWTO has examples of setting up proxy firewalls here - http://tldp.org/HOWTO/Firewall-HOWTO.html
Squid usage is discussed at http://squid-docs.sourceforge.net/latest/html/book1.htm
This article solely relates to the the insecurities that remain in the XML schema defined for any web server that relates to peculiar web servicing application. This is actually based on the AJAX framework as the xml specification act as an interface to server objects. The interface which is being provided by the xml schema directly configures the server on the fly which is dependent on the specific service providing servlet. The wrong schema in the web.xml or the index.xml provide leads to the origin of the web attack base that really disrupts the functioning of the server which further results in leveraging information. I am going to discuss the schema designing and relative effects if it is not configured properly.
