Over the years, I have worked with many SSH boxen and had the pleasure to manage even more SSH keys. The problem with all that is the keys start to build up and then you wonder which boxes have which keys in the authorized keys file and so on and so on. Well, I can’t say I have the ultimate solution, but I do have a few tips that I have come across along the way. Hopefully they will be of use to someone else besides myself.
If you want to leave certain nice to do's or ease of use functionality available to your self such as leaving SSH open only to root or having a machine with anonymous FTP access available, then take a slightly different approach to securing your environment (or those particular machines): layered security. Without changing the physical layout of your network, change the network layout using iptables and/or tcp wrappers.
Nathan wrote in earlier with attempts to exploit PHP file inclusion that his server had automatically thwarted. He's promoting the use of mod_security, mod_evasive, fail2ban and suhosin in a Apache/PHP environment.
Since knowledge and experience is a way to win from the bad guys, how about sharing your favorite setup for Apache/PHP security (Basically a "LAMP" environment although I'd rather not focus on the OS part in there) and we'll summarize on this page. Also let us know what you like of the components you use, why they are your favorite etc.
No doubt you're already aware of the standard logfiles that Apache httpd creates for you. There's the access log, which tells you every time a request is made to your server. There's also the error log, which makes a note every time something goes wrong or something of interest happens that you should know about.
Click this Mojo Ad
There are a few things that you can do to make your access log more useful, such as using the combined, rather than the common, logfile format--but that's another article. Look at the documentation for mod_log_config for more information on that.
Sun Microsystems has issued a security update intended for computers running Sun Solaris 10 operating system. The update patches a security vulnerability that could cause kernel panic by sending one false ICMP request.
The vendor does not disclose the conditions required for the attack to occur, but in its security advisory, Sun suggest testing whether a system responds to ICMP echo requests using a normal ping utility.
The recent surge in malware attacks against zero-day flaws in some of the most widely used software packages is confirmation of an IT administrator's worst nightmare: Stand-alone, signature-based anti-virus software offers no protection from sophisticated online criminals.
During 2006, there was a wave of zero-day attacks against Microsoft Office applications—through vulnerabilities known only to the attackers—that bypassed all anti-virus protection at the network and desktop level. Because traditional anti-virus technology depends on the ability to quickly capture malware samples, reverse the code for the specific characteristics, and then write and release detection signatures, the zero-day attack presents a major dilemma.
How do you cost effectively defend web applications from attack? Your organization relies on mission critical business applications that contain sensitive information about customers, business processes and corporate data. Moving away from proprietary client/server applications to web applications gives you a simpler, cost-effective, highly extensible delivery platform. These applications are more than a valuable tool to power your business operations; they are also a valuable and vulnerable target for attackers. Web applications are increasingly the preferred targets of cyber-criminals looking to profit from identity theft, fraud, corporate espionage, and other illegal activities.
There are several things that you can do to prevent problems. I would recommend putting the DNS servers behind your current firewall and give them a public IP address. When allowing port 53 through the firewall, be sure to allow both TCP and UDP through. I learned this one the hard way the first time I put DNS servers behind a firewall. There were intermittent problems in DNS resolution until both TCP and UDP were allowed through the firewall for port 53. If you put the DNS servers behind your current firewall, I would suggest putting the servers in a different subnet from your server farm or anything else on your network. I would also suggest putting an access control list statement in the switch for the subnet that the DNS servers will be on that doesnt allow traffic from the DNS servers to ingress onto your network and only talk over your Internet connection. Another option is to put the servers on a DMZ connection. Some firewalls allow this with the installation of an additional network card if the firewall you have doesnt have an additional port already available.
Cross Site Request Forgery (also known as XSRF, CSRF, and Cross Site Reference Forgery) works by exploiting the trust that a site has for the user. Site tasks are usually linked to specific urls (Example: http://site/stocks?buy=100&stock=ebay) allowing specific actions to be performed when requested. If a user is logged into the site and an attacker tricks their browser into making a request to one of these task urls, then the task is performed and logged as the logged in user. Typically an attacker will embed malicious HTML or JavaScript code into an email or website to request a specific 'task url' which executes without the users knowledge, either directly or by utilizing a Cross-site Scripting Flaw. Injection via light markup languages such as BBCode is also entirely possible. These sorts of attacks are fairly difficult to detect potentially leaving a user debating with the website/company as to whether or not the stocks bought the day before was initiated by the user after the price plummeted.
This paper addresses digital forensic analysis tools and their use in a legal setting. To enter scientific evidence into a States court, a tool must be reliable and relevant. The reliability of evidence is tested by applying “Daubert” guidelines. To date, there have been few legal challenges to digital evidence, but as the field matures this will likely change. This paper examines the Daubert guidelines and shows that open source tools may more clearly and comprehensively meet the guidelines than closed source tools.
