Responding to a Security Incident
Now we'll put this information into a sample memo to send to the domain contacts to register our complaint. Remember the following things:
* Addresses that you record can be forged quite easily* It's usually not the staff of the ISP or network that are attempting to violate security measures
Further, general rules of thumb that have proven successful for many people over the years are:
* If it's a dedicated line, like a cable modem or a DSL line, it's probably a compromised machine* If it's a dial-up line, it is often a stolen account
With this in mind we can craft our memo.
Things that must go into the memo are:
* Your identification, including name, organization (if any), and role in that organization* The brief purpose of why you are contacting them* Log output to prove your point, time stamped* The address of the host that was hit* Your timezone information, preferably with an offset of GMT (Greenwich Mean Time).* If a compromise occurred
For good measure, I always use a friendly tone.
Another option is to PGP sign your message. This will provide a stronger signature for you, and provide proof that you sent the message to the ISP. This will also help verify that the message was received without being modified in transit. If you do this, include in your memo the location of where you PGP key can be downloaded. In your signature line is a good place.
Don't be stupid, don't make threatening gestures, don't threaten legal action unless you have spoken to a lawyer about things, don't demand action be taken and don't threaten retaliation. Don't retaliate, you'll just become guilty of a violation of your AUP as well. I have seen this numerous times before; please do not fall victim to it as well.
Below is a sample memo, one which mirrors one that I would send regarding the the above detected incident:
To: domain-tech@EURO.NET, domaintech1@CASEMA.NET, nic-invoices@EURONET.NL, email@example.com, firstname.lastname@example.org, email@example.com From: Jose Nazario (firstname.lastname@example.org) Subject: [SECURITY] FTP probe from casema.net domain Good day, My name is Jose Nazario and I am a customer of BigCorp ISP. I am writing to you today to note that a machine I own was probed by a host in the casema.net network. This was a probe to the FTP daemon, port 21/TCP. You are listed as a responsible party in the domain records. As there are a number of problems with FTP servers currently making the rounds with hackers, this may represent someone attempting to find vulnerable hosts to compromise. This may represent a legitimate user in violation of their AUP or a compromised machine on your network. The host on my network that received the traffic from your domain is myhost.bigisp.com (10.10.32.4). The log entry for this incident looks like this: Nov 8 15:26:31 linux ftpd: refused connect from 7dyn94.ztm.casema.net All times are in US Eastern (GMT-5). While no reply is expected, the favor of an acknowledgment would be appreciated. Thank you for your attention to this matter, Jose Nazario email@example.com http://www.bigisp.com/~jnazario/
This is the first thing that many people think about when documenting a security incident. Most people have this image of a scruffy 15-year-old hacker being led to a prison in handcuffs. The truth is this rarely happens, even with the best of documentation on your end. The reasons for this are many and varied, but can be summarized in large measure by the difficulty in proving who was using what system at what time, and the forensic value of the evidence.
The FBI will not investigate a security incident unless the monetary damage is above $5,000US, someone's life was in danger or interstate commerce was affected. Even then the evidence may have lost forensic value for a criminal prosecution.
If you think the legal authorities should be contacted, you should speak to your site supervisors and any legal advisors to ensure you have a plan before any security incidents take place. Two books you may want to begin with are listed below in the references section.
One questions people have is "Should I contact CERT or a similar organization with this information?" In my experience, it is usually not necessary except under pretty uncommon circumstances.
Most of the incidents you will see are probes of one type or another. Port scans, probes for services like RPC services or DNS servers, maybe even a few web probes for cgi-bin scripts, but just probes. While it's pretty obvious they're sizing you up for an attempt to break in, they didn't get in and they didn't cause any damage.
Times when I have contacted CERT (http://www.cert.org) here in the United States are when legitimate intrusions have taken place, novel exploits have been used which are not documented in the security community and when the system has been used to gain entry into other computers or for DoS attacks. This helps provide a central place for the information on the attack to be stored and evaluated, and, potentially, a third party to show that actions were being taken to remedy the situation. Also, contacting CERT is a good idea if the incident is above a probe, such as a real documented attempt or a successful break-in, and occurred from a host outside of the United States.
CERT-type organizations exist all over the world and are worth reporting to if you file an incident with CERT. File a similar report with the organization in the originating country. A comprehensive list of CERT and similar organizations from around the world can be found at FIRST's contact information page. FIRST is an organization that provides a forum for incident handling.
Note that CERT has no legal authority, but does work with the authorities to investigate security incidents when they are warranted.
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- Stunnel Security for Oracle
- The Firebird Project's Firebird Relational Database
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released