Responding to a Security Incident
I spend a good chunk of my time on mailing lists and organizations concerned with monitoring hacker activity. Such lists are the INCIDENTS list from SecurityFocus.com and the SANS GIAC effort, providing a daily update of hacker activities from various parties around the world. Often, the question of the value of reporting an incident is debated. I routinely counsel people to report most incidents they see. What this does for the ISP is help them gather information about a set of independently correlated data about a nefarious customer or a compromised machine on their network. Just don't expect much to be done about it. Most ISPs don't react and aren't very neighborly. Some of us in the business routinely block entire networks from connecting to our networks based on their patterns of allowing unseemly activity to continue.
We'll not go into detecting incidents, but we will define them as port probes, port scans, denial of service (DoS) attempts and unauthorized access attempts. Each of these warrants investigation, some more than others. Combining intrusion detection software with log analysis (which you should be doing anyhow), these events should stand out.
We'll start with a simple detect and extract information from it, deciding how best to proceed. This first one is a log message of a refused connect request from a service, wrapped using TCP wrappers (tcpd). As of this writing, FTP sweeps are all the rage:
$ grep refuse /var/log/secure Nov 8 15:26:31 linux ftpd: refused connect from 7dyn94.ztm.casema.net
TCP_wrappers makes an excellent basic intrusion detection system, logging both successes and failures. You should be using at least TCP_wrappers for access control and minimizing what services people can connect to at all.
A brief note about connection attempts: One important thing that gets overlooked by the casual paranoid Internet user is the threshold of what defines a probe or an attack, and what is worth reporting. Usually it's not worth reporting SMTP (port 25/TCP) or HTTP (port 80/TCP) probes, unless you can demonstrate that it was more than a simple connection attempt. Why? Say I see you on a chatline, and I want to send you some mail directly or see if you have an interesting web site. If you are blocking those requests, they would show up as port probes. But they're usually more innocent than they may appear. The same goes for ping requests (ICMP_ECHO), which are used, for example, in gaming and Napster to determine latency. Don't get in a tizzy about simple things; focus on actual intrusion attempts, like an FTP exploit or a network sweep for a service.
One of the first things we do is map an IP address to that hostname. I prefer to work with IP addresses rather than hostnames, as sometimes ISPs will sell their netblocks in smaller quantities, yet retain administrative control of them.
$ nslookup 7dyn94.ztm.casema.net Name: 7dyn94.ztm.casema.net Address: 22.214.171.124
Now we begin to dig around for domain information using this network address. You can use command line "whois" information to find out about this network address.
Two different major types of databases exist, depending on if you are searching by hostname or network addresses. Network names are handled by registries like Network Solutions, and network numbers are handled by the ARIN (American Registry of Internet Numbers) database. Because we're using a network number, we'll be using the ARIN database, but we'll do both to illustrate how it is done.
A quick note on using whois. You can specify query@whois-engine using fwhois, which is very common on Linux boxes. However, this doesn't work on normal whois clients. You have to use the -h whois-engine option, instead. Hence, the queries fwhois email@example.com and whois -h whois.networksolutions.com domain.com are equivalent. In these examples, we'll be using the fwhois command-line tool or web-based whois searches, and whois is just a symbolic link to fwhois.
First, the ARIN search:
$ whois firstname.lastname@example.org [whois.arin.net] European Regional Internet Registry/RIPE NCC (NET-RIPE-NCC-) These addresses have been further assigned to European users. Contact information can be found in the RIPE database, via the WHOIS and TELNET servers at whois.ripe.net, and at http://www.ripe.net/db/whois.html Netname: RIPE-NCC-212 Netblock: 126.96.36.199 - 188.8.131.52 Maintainer: RIPE Coordinator: RIPE Network Coordination Centre (RIPE-NCC-ARIN) nicdb@RIPE.NET +31 20 535 4444 Fax- - +31 20 535 4445 Domain System inverse mapping provided by: NS.RIPE.NET 184.108.40.206 NS.EU.NET 220.127.116.11 AUTH03.NS.UU.NET 18.104.22.168 NS2.NIC.FR 22.214.171.124 SUNIC.SUNET.SE 126.96.36.199 MUNNARI.OZ.AU 188.8.131.52 NS.APNIC.NET 184.108.40.206 To search on arbitrary strings, see the Database page on the RIPE NCC web-site at http://www.ripe.net/db/ Record last updated on 16-Oct-1998. Database last updated on 9-Nov-2000 07:02:34 EDT. The ARIN Registration Services Host contains ONLY Internet network information: Networks, ASNs and related POCs. Use the whois server at rs.internic.net for DOMAIN related Information and whois.nic.mil for NIPRNET Information.
Aside from all the extraneous information, we can see from this record that ARIN doesn't handle exact information for this network block. We'll then use network name in a query:
$ whois email@example.com Registrant: N.V. Casema (CASEMA-DOM) P.O. Box 345 Delft, 2600 AH THE NETHERLANDS Domain Name: CASEMA.NET Administrative Contact: Network Operations Centre (NOC137-ORG) domain-tech@EURO.NET EuroNet Internet BV Muiderstraat 1 Amsterdam NL +31 20 5355555 Fax- +31 20 5355400 Technical Contact, Zone Contact: Davids, Marco (MD2446) domaintech1@CASEMA.NET N.V. Casema - IKC Brassersplein 2 Delft ZH 2612 CT NL +31(0)15 8881000 (FAX) +31(0)15 8881099 Billing Contact: Finance Departement (FD5-ORG) nic-invoices@EURONET.NL EuroNet Internet BV Postbus 11095 Amsterdam NL +31 20 5355555 Fax- +31 20 5355400 Record last updated on 13-Jun-2000. Record expires on 30-Jan-2001. Record created on 28-Jan-1997. Database last updated on 7-Nov-2000 19:15:09 EST. Domain servers in listed order: NS.CASEMA.NL 220.127.116.11 NS1.CASEMA.NET 18.104.22.168
We now have the information we need to proceed. We'll be sending our memo to the addresses listed as the billing contact, technical contact and the administrative contact. For good measure, we'll toss in the often used addresses security@ and abuse@, hopefully targeting the right people.
Additional information you may want to gather include a traceroute to find their upstream network providers and the AUP (acceptable use policy) of the ISP. Usually digging around on www.domain.com can turn it up. Rarely do ISPs have hacker-friendly AUP terms, but it's been known to happen.
|A Project to Guarantee Better Security for Open-Source Projects||Aug 27, 2015|
|Concerning Containers' Connections: on Docker Networking||Aug 26, 2015|
|My Network Go-Bag||Aug 24, 2015|
|Doing Astronomy with Python||Aug 19, 2015|
|Build a “Virtual SuperComputer” with Process Virtualization||Aug 18, 2015|
|Firefox Security Exploit Targets Linux Users and Web Developers||Aug 17, 2015|
- A Project to Guarantee Better Security for Open-Source Projects
- Concerning Containers' Connections: on Docker Networking
- My Network Go-Bag
- Problems with Ubuntu's Software Center and How Canonical Plans to Fix Them
- Doing Astronomy with Python
- Firefox Security Exploit Targets Linux Users and Web Developers
- Build a “Virtual SuperComputer” with Process Virtualization
- diff -u: What's New in Kernel Development
- Three More Lessons
- August 2015 Issue of Linux Journal: Programming