This article explains how to install and configure periodic scans with ClamAV on CentOS7 or Redhat (RHEL) 7 servers. Much of this came from “https://ismailyenigul.wordpress.com/2015/01/05/install-clamav-on-centos-7/”.
The .htaccess file can restrict access to web browsers to specific things. I’ve written about this (on this blog) previously. However, here i talk about file types.
The snippets below are (or can be) the entire contents of the .htaccess file.
Prevent access to bash files that shouldn’t be in the root (document root):
<Files ~ "\.sh$"> Order deny,allow Deny from all </Files>
If you need to have bash scripts accessible via Apache, consider putting them in a directory perhaps called “/private” and we can then restrict that to the location:
Recently i wrote about the importance of a sensible IT setup for small businesses. See it here http://www.agix.com.au/?p=5422. I discussed security but skipped a-lot to keep it simple. This document goes further into depth.
A well thought and simple computer network goes a long way to good security but the more thought you put into your network security the better prepared you will be.
These are my recommendations:
- Evaluate the biggest risks. Whatever your business most needs to stay open is what you have to protect. Let’s focus on IT though. Starting from this you can work your way though with purpose. For example, if your CRM is the post important IT system, make sure it’s protected with backups, software updates, database redundancy, network restrictions, strong passwords, physical access restrictions and an audit of who and when it’s accessed. Use this as a template for your critical systems.
- Have good backups. When the day comes (and it will) when your business is hacked, or data goes missing, you will want to know your backups are available and complete. Make sure you have both off-site and on-site backups. It’s slow to restore large amounts of data from remote locations so a local copy of your data is necessary. Backups should be encrypted. A cleaner can (and this happens often) steal your backup disk from the server room if it’s not locked so make sure the USB disk’s data is encrypted. Test your backups regularly. It can be costly and time-consuming to restore a complete server from backups but it’s worth it periodically. Simple document restores should be done too.
- Strict network storage controls. All documents should be stored on a server that’s backed up daily (at least). Consider a document management system (DMS) or simply use a network share. Whatever you use, make sure staff can access only what they need to access in order to do their job. Two very good reasons for this are: a) it restricts that amount of damage a single staff member can do if disgruntled or clumsy. And b) a virus on a given staff members computer can access network storage that the staff member’s login can access. Limiting the access of users helps limit the potential damage of viruses, clumsy staff and cryptoware (cryptoware is software the goes through your documents and encrypts them – and you can only decrypt your documents when you pay (the hackers) for the unlock key).
- The obvious little things. Make sure all workstations and laptops have up-to-date antivirus, passwords must expire monthly, passwords are not written down or shared, passwords are of 8 characters or more, emails are scanned on their way in and out of the organisation and workstations and portable devices are updated regularly.
- Educate staff on what’s acceptable and not. Let’s use a story for this one. Suppose the hacker calls your receptionist and says “Hi I’m Andrew calling from XYZ company on behalf of your_supplier. We’re tasked with assisting in the recall of a product popular_product and are calling to make sure you’re aware of the pending recall following up with a PDF with more details. Can you tell me where to send the email to so that it will be read today? It will contain a PDF document with all the details.” At this point there is no reason for the receiver to questions the legitimacy of the caller because they haven’t asked for any information other than an email address and company policy says nothing about giving that out – it’s fine and normal practice. And the caller knows the receiver stocks a product and can even refer to it by it’s product code as that’s freely available. This (the phone call) is potentially a huge issue. A quick risk assessment says: this may be true and if it is it’s very important so therefore worth following up on. The receiver gives the email address – which the hacker could have easily found out anyway. The hacker continues “Thank you. One last thing, some people have complained the PDF document comes out blank. Can you tell me which version of Adobe Reader you have? I’d like to send you a version that works for you. Just open any PDF document you already have and click Help and About.” The receiver provides it. The hacker finishes with “Thank you, i will send that through right now, it can take a few minutes to come through. Any hassles, please call the number in the email or your normal contact at you_supplier. Thank’s again.” The hacker uses “hacker tools” (similar to Microsoft Office but for hackers) to create a blank PDF document which, when opened, will create a back-door into the receivers computer. This is very easy to do and very effective because most of us trust PDF documents because they seem so static and standard. Why is this so easy? Acrobat Reader has a long history of exploits that hackers take advantage of and best of all (for the hackers) antivirus software doesn’t look for this. And it’s annoying to allow the constant updates to run so we tend to click the “cancel” button when it tries. Don’t do that.
- So what should your staff do? Create some policies and rules that staff must follow. Make sure it’s understood by everyone and grounds for a warning or worse if not followed:
a) only staff can use and access company computers remotely or physically – don’t allow unexpected IT people, sales people or anyone else use or ask you (your staff) to use company computer for their purposes,
b) workstations and portable devices should be locked when not in use – make sure devices auto-lock themselves after a short period of time and that they need a password or pin to unlock,
c) workstations should be turned (not just locked) at the end of the work-day – this limits the opportunity for hackers,
d) workstations should have their USB storage capabilities disabled – this is a major method of virus infections,
e) workstations and portable devices should have their software updated automatically including PDF readers, the operating system, and office software – don’t skip updates,
f) company servers and related IT gear (routers, etc) should be behind locked doors,
g) when someone calls, visits or emails with a story ultimately requesting you (your staff) to do something, consider the consequences, thing carefully – even knowing the name of the company that supports your IT systems would allow the hacker to arrive (on-site) waring a shirt with that companies logo printed on it.
The list above is incomplete but it’s a start. The hacker wants you or your staff to do something which will allow the hacker to gain access to the information they need. Even bright and well educated people get tricked in these ways. We all fall for marketing tricks daily – it’s the same thing. It doesn’t take much for someone to go through your garbage looking for discarded document or send a seemingly innocent PDF attachment via email and result in compromised systems. Be aware and limit the hackers opportunities. This is an “all of business” task and education is the key.
I update this article periodically to keep it current. The principles never change though.
Who should read this? Those who are responsible for businesses IT systems.
Do things the right way.
When staff ask why things aren’t as simple or easy as they’d like, you know their expectations of business IT resources are inconsistent with reality. Perhaps they’re using email as a CRM or their desktop as their filing system. Either they need to adjust their expectations or you need to adjust the IT systems to meet their expectations. Start here. Solve the issue of expectations and everything else falls into place.
A distributed denial of service attack (or DDoS) will either bring your server down or significantly degrade its performance. This article explains a quick way to tackle the problem.
The IPTables firewall rules that follow ensure packets are limited to a set number per period of time. This rule will ensure only 10 new requests can hit the server in a 20 second period. It won’t stop the attack but it will keep your server up.
Just a quick reference for setting up your Gentoo server to get its time from an NTP server either local or on the Internet.
Get NTP onto the machine
emerge --ask -jv ntp
Edit the NTP config
Comment out the servers that you do not need and add your own, the address I have added below is a pool of servers so we only need to set one entry you could do this internally by creating a DNS round robin type situation or just specify three seperate entries.
Create the key and set a passphrase:
openssl genrsa -des3 -out server.key 2048
Create the csr file making sure the CN (common name) matches whatever domain name it represents such as “www.agix.local”. This requires the passphrase from the step above:
openssl req -new -key server.key -out server.csr
Remove the passphrase:
openssl rsa -in server.key -out server.key.nopass
Generate the self-signed certificate:
Test the remote servers HTTPS certificate:
openssl s_client -showcerts -connect www.agix.local:443
Test the remote servers SMTP STARTTLS certificate:
openssl s_client -connect mail.agix.local:25 -starttls smtp
This playbook will add the script “myscript.sh” to the target machine(s) “/etc/cron.monthly” directory thereby having it run each month by cron. You can simply change the location to have it go into one of the other cron.x locations. I’ve used ansible version “ansible 1.9.4”.
You’ve dumped a DB from MySQL and didn’t use the “–no-triggers” option. Now you’re trying to import your data into RDS MySQL which complains that:
ERROR 1227 (42000) at line xxx: Access denied; you need (at least one of) the SUPER privilege(s) for this operation
You can solve this by editing the dump file with ‘sed’ and then importing into RDS’s MySQL from your newly modified dump file.sed -E 's/DEFINER=`[^`]+`@`[^`]+`/DEFINER=CURRENT_USER/g' dumpfile.sql > dumpfile_no_tags.sql