|
ISP SPECIFIC QUESTIONS
END USER QUESTIONS
ISP SPECIFIC QUESTIONS
| Identify your IPs so other networks can reach you! |
|
Problems which aren't identified don't get fixed.
Provide proper role accounts in RIR whois records, including abuse role accounts. Be sure such accounts are read frequently by admins with the authority to fix the problems identified by reports to that address.
Properly identify subnet clients. For example, ARIN requires public identification records for /29 (8 IPs) and larger ranges (section 4.2.3.7.2.).
This FAQ also has information about proper rDNS as well as the role accounts to go with those hostnames. |
| We get a lot of abuse@ mail, how can we handle it? |
|
There are tools and services designed specifically with the needs of an abuse desk in mind. They come highly recommended and are used in production environments at large ISP/NSP abuse departments:
Procmail can be extremely useful for sorting an inbound mail stream. For example, you could flag and sort any mail which had any of your IPs in it. You could bundle it into /24 chunks (or whatever works for you) and triage based on relative volumes. Spammers can even turn themselves in, that way.
Grepcidr is another handy tool for finding IPs or IP ranges from within a file. You could "$ grepcidr IP.Range spam.file" to pull out all the IPs in that range from your file of spam and abuse reports, for example.
Filtering an abuse@ mailbox can be tricky because much of the mail which it should receive looks like spam. Content filters will hit on many spam reports. Filter out spam reports and you risk not identifying a problem on your network. Spamresource.com offers some thoughts on how to deal with all the spam aimed at the abuse box. |
| But we're not seeing any spam reports!? |
|
There are any number of reasons you didn't see spam reports before your IPs were listed by Spamhaus, or by other lists or networks. Among them:
You're not signed up for sufficient Feedback Loops (FBL). (Search Google for "ISP Feedback Loops.")
Your abuse@ account is filtered so spam reports don't get through. It goes over quota, has insufficient retention capacity, inadequate search tools, isn't read frequently or completely, or is otherwise dysfunctional.
You use a free email account or host your abuse@ account on a service such as Gmail who filter spam into the spam folder and you never seen many reports. A bad idea. If you must use Gmail, there is a way to Disable your Gmail spam folder.
Filters are catching spam from your IP addresses before it hits reporting addresses.
People, users and ISP admins, are tired of reporting spam and simply block it as soon as it's detected, no questions or comments. Sometimes called "LART fatigue".
The use of "disposable e-mail addresses" means those who use them aren't seeing spam in their primary accounts, so it doesn't get reported.
Spammers have improved their listwashing methods to eliminate spam reporting addresses. Some ISPs aid that process by passing reports along to spammers without verifying that the root problem is fixed. Spammers also have many other means to wash away the symptoms of their ill-gotten lists while not fixing the basic problem (i.e., no opt in). |
| What can we do about accounts that are not breaking the law? (AUP) |
|
Laws regarding the Internet vary by jurisdiction; different countries each have their own laws which cover some abuses, but possibly not all. Besides, police or court intervention is often too slow to be effective at stopping Internet abuse. To effectively stop all abuse in a timely manner, each ISP must create and enforce a set of rules on all of their customers and users, often called an Acceptable Use Policy (AUP).
Those policies should be written into contracts with every customer of the ISP and apply to the customers-of-customers and all other users of the ISP's network, too. ISPs which want to maintain good relationships with other networks must enforce AUPs which prohibit abuse against those other networks.
Spamhaus is not a law enforcement agency nor does it claim to know all the laws in every country. Instead, we build our anti-spam lists based on our own published policies, policies which all of our users--including very large networks--agree with. Again, any network which wants to exchange e-mail (or other traffic) with Spamhaus users
must enforce policies prohibiting abuse by all users of their network.
If you don't have an AUP yet you can use our free AUP builder to create one. Be sure to have your company lawyer adjust it so that you can effectively enforce the policies you need for your network's traffic to be acceptable to other networks. |
| We are an ESP and send lots of mail. What should we do about bad customers ? |
|
Please refer to the Best Current Practices documents prepared by M3AAWG (Messaging Malware Mobile Anti-Abuse Working Group [MAAWG]):
This may also help:
|
| How do I connect with other "abuse desks" in the industry? |
|
The Messaging Malware Mobile Anti-Abuse Working Group (M3AAWG, formerly MAAWG) is the first step in an effort to align the messaging industry stakeholders along three directives: Collaboration, Technology and Policy. M3AAWG provides an excellent opportunity for social networking with other responsible senders and receivers.
Another touchstone is the Coalition Against Unsolicited Commercial Email (CAUCE) and its international affiliates. |
| What can we as an ISP do to prevent spam through compromised accounts? |
|
User account compromises are a growing problem, especially with malware targetting specific services and providers for stealing of user login/password combinations. More information on this subject can be found in our blog article Spam through compromised passwords, can it be stopped?. |
| What can we do to prevent fraudulent signups? |
|
Detecting and preventing fraudulent signups for ISP services can be a complex task. In October 2012 we published a lengthy blogpost with many tips and tricks to deal with this issue: How hosting providers can battle fraudulent sign-ups. |
| Dynamic IP lists & port 25 blocking - strongly suggested! |
|
Dynamic IP ranges--dialup, cable, and DSL--are a huge source of spam. The users of those ranges are most vulnerable to attacks by viruses and Trojan Horse proxy software installed by virus infections which turn their computers into botnet zombie spam spewers. Dynamic IP users on your network should send their mail out through your network's outbound customer servers, or through other dedicated outbound "smarthosts" accessible via SMTP AUTH (authenticated) on port 587:
RFC2554,
RFC2476,
RFC4409.
The best way to stop the massive amounts of dynamic IP spam is for your network to filter port 25 on dynamic ranges, only allowing port 25 access to your smarthosts (or not even that, if your smarthosts use AUTH). The Messaging Malware Mobile Anti-Abuse Working Group, M3AAWG (formerly MAAWG), has its recommendations on port 25 blocking, available in various languages:
If you run a NAT gateway, see http://www.abuseat.org/nat.html.
But even if you cannot block port 25, most other networks would rather not accept any mail from dynamic ranges. To assist them with that, it is polite for your network to list your dynamic, end-user, IP ranges in the Spamhaus PBL.
Besides being a good Internet neighbor and helping other networks avoid spam from your users, listing your dynamic addresses in those lists makes those ranges less attractive to spammers because they know they can't deliver to many networks which use those lists, and you'll get proportionally fewer spam reports.
Please add your dynamic IP ranges to those lists! |
| How do users send mail if Port 25 is blocked? (SMTP AUTH) |
|
Users of dynamic ranges with blocked port 25 can connect with SMTP AUTH "SUBMISSION" protocol: ftp://ftp.rfc-editor.org/in-notes/rfc2554.txt. We have more instructions for several other mail programs in the Generic Questions FAQ.
What is needed:
The ISP configures its server to accept SMTP AUTH connections on port 587; all modern mail servers support it. Don't block dynamic users from port 587, and don't use PBL or Zen on 587 connections! Don't block your own users!
Each user configures their mail client (MUA) to connect via SMTP AUTH on port 587, with username/password. All current MUAs have that as an option; use the mail client's "help" menu.
In Outlook and Outlook Express, the menus for that are something like this: - Internet E-mail Settings
- - Outgoing Server
- - - [x] My outgoing server (SMTP) requires authentication
- Advanced
- - Server Port Number
- - - Outgoing server (SMTP): [587]
- - - [x] This server requires an encrypted connection That way, only authorized users can connect to your mail server, you know exactly what account it is, and they bypass "port 25 blocking". Users with "SMTP AUTH" can then send mail from their computer via your server from anywhere they can connect, so it is very good for travelers like business people and students.
You should also consider filtering outbound spam on your mail server, possibly with something like http://spamassassin.apache.org/. |
| What is "proxy hijacking"? What do I need to know about proxies? |
|
A proxy is any computer which can perform a function as a surrogate for another computer, under control of a remote operator. When an insecure proxy is used by spammers to transmit spam, that proxy computer is said to be "hijacked." The most common proxies seen in spam are the virus-installed trojans which actually transmit the spam via SMTP (they usually receive their commands on other ports).
Other proxies used in spamming include web-cache and promiscuous DNS proxies, explained in this presentation in your choice of .ppt or .pdf formats. Currently, the most popular proxy protocols used by these virus-installed trojans are SOCKS4, SOCKS5 and HTTP-connect, but they may operate on any port. Increasingly, computers controlled by these virus-installed trojans -- "zombies" -- are parts of larger botnets controlled by criminal spam gangs and other Internet criminals.
ISP admins need to be able to identify proxies, secure them and block unauthorized access to them, and remove the software if necessary. Many trojan proxies do not show up with routine port scans, either operating on obscure high-number ports or using evasive mechanisms to avoid detection. Their filenames are not consistent. It may be necessary to do complete forensics, including packet sniffing and system monitoring, to identify the malware.
For many end-user systems, it is simply more effective to wipe the hard disk and reinstall a fresh system, or to pay a professional to clean the system. |
| What is a "honeypot" or "proxypot"? What is a "proxy hijack source" or "C&C"? |
|
[hijack source/C&C]---(SOCKS)--->[zombie PC]---(SMTP)--->[spam rcpt] Even more important than securing proxies is locating the proxy hijack source - the command and control (C&C) server for a botnet composed of many proxies (tens of thousands). These C&C servers are the actual originating source servers which send spam out through compromised proxy systems. The proxies hide the originating IP address from showing up in spam headers, of course, so you probably will not see spam reports, but special honeypots called "proxypots" identify the server motherships. Proxypots mimic a zombie PC, but unlike the zombie, they record the spammer's source IP. Spamhaus uses proxypots -- and other techniques -- to identify those C&C or proxy hijack servers.
To confirm those detections, as well as to monitor your own network routinely, every ISP should have the tools and skills to do traffic flow analysis. When you look at traffic flowing from a C&C server, you will see many connections on high-number ports to many destination IP address around the 'net - thousands and thousands of connections on unusual high-number ports! The destinations are almost always compromised proxies on end-user broadband networks. Be prepared with a good network monitoring tool to check traffic flows from suspected hijack servers. Some of the tools we've heard of include Tippingpoint, Fortinet, Sandvine, Packeteer, Allot NetEnforcer, Cisco's P-cube, and flow-tools for collecting and processing netflow data from Cisco and Juniper routers. Also see Stager for sorting and presenting data collected by those tools.
Network operators can also subscribe to a daily report of reported C&Cs on their network. ISOTF's "Drone Armies" research team posted a summary of their work on the NANOG mailing list and invited interested admins to contact them at c2report@isotf.org. Those reports show IP, time, domain, and port.
Spamhaus hears two common excuses given by proxy spammers to trick abuse admins. One excuse is a cover-up for that unusual traffic flow pattern, "We're doing VOIP." A closer look at the packets will disprove that. The other common exuse is "we removed the virus from the computer." Since it wasn't a virus causing the problem, that obviously doesn't stop the spam. Remember, these are dedicated servers with large lists feeding into them. And also remember, if it was a virus problem, you'd see that IP in spam headers.
|
| Should an ISP use the XBL to block their own users since it means they have a virus or open proxy? |
|
We're getting a lot of reports of spurious blocking caused by sites using the Spamhaus XBL to block authenticated access to smarthosts / outgoing email servers. The XBL is only designed to be used on incoming email, i.e. on the hosts that your MX records point to.
If you use the same hosts for incoming email and smarthosting / outgoing email, then you should always ensure that you exempt authenticated clients from XBL checks, just as you would for dynamic/dialup blocklists.
As your users are often on dynamic IP addresses, a user may be assigned an IP address from his provider that is in the XBL due to the virus or open proxy situation of a previous user of that IP address.
Another way of putting this is: "Do not use the XBL to block your own users".
Using the XBL to alert an ISP's security department when a user's IP is in the XBL is permissible and a good thing. But remember, that user may not be the one with the virus or open proxy problem.
Note: This also applies to using the XBL to deny access to web-forums, journals or blogs. |
| Should an ISP use the PBL to block their own users? |
|
No! Spurious blocking caused by sites using the Spamhaus PBL to block authenticated access to smarthosts or outgoing email servers is very bad. The PBL is only designed to be used on incoming email, i.e. on the hosts that your MX records point to.
If you use the same hosts for incoming email and smarthosting or outgoing email, then you should always ensure that you exempt authenticated clients from PBL checks. As your users are often on dynamic IP addresses, a user may be assigned an IP address from his provider that is in the PBL.
Another way of putting this is: "Do not use the PBL to block your own users".
Note: This also applies to using the PBL to deny access to web-forums, journals or blogs. |
| Backscatter from spam firewalls and anti-virus systems |
|
So-called "spam firewalls," software running in front of production servers to process out spam and viruses, can be a problem for other networks if they simply deflect the spam on to other mailboxes. Most spam and all mail-borne viruses use a forged Sender address, and bouncing it back to that address only results in sending unwanted and burdensome mail to innocent third parties. Either reject the SMTP connection with a 5xy message, silently discard it (your firewall identified it as spam, remember?), or file it in a quarantine area for *your* users to glean. Don't make it someone else's responsibility when they are almost certainly not involved.
The backscatter problem does not affect only spam firewalls though. Also regular MTAs can suffer of the same problem due to misconfigurations. The problem occurs every time a message is accepted from the original sender, then it is discovered that it can not be delivered for any reason and a non-delivery notification is generated and returned to the original sender. The problem is that the original sender is forged in spam, so those messages may go to someone who was not involved at all in the spam sending. The problem is solved by having the MTA detect that the message can not be delivered while the original SMTP transaction is still in progress, and reject the transaction without accepting the message. In this way, no mail will go to the forged sender.
On the Barracuda Spam Firewall, the option to turn spam bouncing off can be found in the Basic Tab under Spam Scoring. Near the bottom there is a check box for "Send Bounce." This is checked by default and should be unchecked. Instructions with screenshots are shown at http://postmaster.gtcs.com/CudaFix.php. Barracuda 300 may not have this option, but the 400 and 600 versions do have it.
When using the amavisd-new content scanner, the configuration file amavisd.conf should contain:
$final_virus_destiny = D_DISCARD; (or D_REJECT)
$final_banned_destiny = D_DISCARD; (or D_REJECT)
$final_spam_destiny = D_DISCARD; (or D_REJECT)
Avoid the D_BOUNCE setting which is the one that causes problems. Note that the D_REJECT seeting has the same effect as a D_BOUNCE in a post queue filter. Thus D_REJECT should be used only for a pre-queue filter.
Note from the above example that the same principle applies to anti-virus notifications and bounces as well. If it's a virus, and it's after the year 2003, 99.9% of the time the return path will be bogus. DO NOT SEND IT THERE!
Other references on spam and virus backscatter:
http://www.spamcop.net/fom-serve/cache/329.html#bounces
http://www.postfix.org/BACKSCATTER_README.html
http://en.wikipedia.org/wiki/Backscatter_%28e-mail%29
http://www.spamresource.com/2007/02/backscatter-what-is-it-how-do-i-stop-it.html |
| My mail server is listed on the SBL as a phish spam source, what should I do ? |
|
Phish spam is sent by criminals gangs. They hijack mail servers to get good delivery rates, usually forging the sender address and constantly changing the IP of origin.
If you have this problem, you can not solve it by blocking specific IP addresses or email senders, or in general using filtering/blocking rules, antispam appliances, etc. The spammers exploited a security hole: it should be impossible for anyone external to your organization to use your server to send mail to arbitrary destinations. Your server should accept inbound mail or outbound mail, but it should reject at the SMTP level by default all mail attempting to "pass through".
So, to solve the problem you have to identify and fix this security hole. This should not be too difficult, because the spam was sent by your mail server and therefore evidences and traces have been left in the mail logs. You have to analyze the logs to figure out what the spammers did. If your mail server is Microsoft Exchange, see the FAQ entry below.
In most cases no malware or viruses are involved. Just checking your server and clients for malware is generally insufficient, usually not relevant and does not solve the problem. Obviously, blocking the forged sender address or the IP of origin also does not solve the problem, as those parameters are constantly changed.
These are the most common mechanisms exploited, approximately ordered by number of occurrences, and their typical resolution path:
- (by far the most common) the spam was sent as authenticated mail, injected from an external IP using a valid username and password. Find the involved account from the mail logs and contact its owner.
- if the password was extremely easy to guess, just change it.
- if the password was difficult to guess, it was probably stolen by a keylogger trojan running on a client PC or laptop. Disinfect all the computers used by that person, then change the password.
If for any reason you are unsure about the account involved, then change all passwords, including those of much-abused role accounts such as admin or info. test is also heavily abused.
The logs should always be checked to verify this point, before the following rare possibilities 2, 3, and 4 are even considered.
- the spam was not authenticated, but it came from a PC or laptop internal to the LAN, as shown by the local IP address in the logs: clean that computer, as there is malware on it.
- the spam was not authenticated and it came from a web server in your LAN. In this case, the spammers injected the message via HTTP using a security hole on the web server. Check the web logs for a confirmation, and close the hole.
- the spam was not authenticated and it was injected via SMTP from outside: in this case, you have an "open relay" configuration. Fix it.
Do not forget to check the mail queue, and delete all the spam samples that may still be there, waiting to be delivered. Only after all this has been done, the SBL team can process a removal request for a listed phish source.
For a general perspective about this problem, you can also read this article. |
| How can we keep 419ers off our webmail? |
|
It's difficult to keep the dedicated 419 scam spammers off of an ISP's webmail, but there are some techniques to make it much harder for them.
Add some systems to minimize the ability to easily and quickly sign up for multiple webmail accounts. Limit new accounts from the same IP address in a small time period. Use CAPTCHA tests. Watch for patterns of abusive usernames (user1, user1, user3, A_user, B_user, etc.) and remove all names within that pattern as soon as detected.
Block IP ranges as needed, often quite aggressively.
Rate-limit RCPT_TO (419ers load up To, CC and BCC fields...what legit webmail needs more than a dozen or so RCPTs?).
Dump mail with more than 10 lines in the .sig (used by 419ers to avoid other field limitations).
Keep up with abuse@ reports and adapt *quickly* to new attack vectors as they are reported.
Apply outbound filtering with properly adjusted tools such as SpamAssassin. ("Properly adjusted" means you probably need to optimize the parameters for your application.)
|
END USER QUESTIONS
| My IP was used for rogue DNS - how is that happening? |
|
In 2014 and 2015 we are seeing lots of DNS set up on hacked machines, usually on systems in commercial hosting facilities. Forensics on these intrusions have been minimal; usually the box just gets wiped, or maybe some ports blocked, but the actual intrusion vector may not be determined. We'd like to hear more from anyone knowledgable in these intrusions. Here are some of the ways we have heard of DNS being set up to use IP addresses without the owner's permission:
1. TinyDNS installed illicitly. TinyDNS is excellent and perfectly legitimate DNS software, but it is also widely used by bad guys for these rogue DNS installations. They probably like its small size and fast performance, same as legitimate users. Any hack that allows content to be written to the box could be the vulnerability used to install it.
2. NAT (Natural Address Translation; "natting") like this:
-A PREROUTING -d 0.0.0.0 -p udp -m udp --dport 53 -j DNAT--to-destination 255.0.0.255:53
-A POSTROUTING -d 255.0.0.255 -p udp -m udp --dport 53 -j SNAT--to-source 0.0.0.0
(Where 0.0.0.0 represents your hacked computer's address, and 255.0.0.255 represents the bad guy's "back end." If you find that, please let us know the back end address.)
3. Multicast DNS (5353/tcp, 5353/udp)
Our blog post on webserver security has general information which can help deter these attacks: http://www.spamhaus.org/news/article/718/stop-spammers-from-exploiting-your-webserver
|
| What is "fast flux" hosting? |
|
Fast flux domain hosting involves the use of botnet zombie drones on broadband IPs infected to act as reverse proxies for the spammer's website or nameservers. The spamvertised domain's A-record is pointed at a rapidly changing series of zombie IPs (hence the name) with very short "TTL" values, usually less than five minutes (300s). When both the A and NS RRs use that type of bot hosting it is referred to as double flux. There are typically four or five A records to distribute the load and increase the odds of the website staying up in case a bot crashes or is taken offline. The proxy action hides the IP location of the spammer's dedicated servers. As the very act of hijacking computers is illegal in most jurisdictions, such fast flux hosting is mostly used for further criminal activities such as phishing, malware and child exploitation. These criminals know they could be identified if they used valid whois info so they always use bogus data, so registrars can confidently HOLD (suspend) the domain based on ICANN 3.7.7.2.
January 2008: ICANN's Security and Stability Advisory Committee has published an advisory on Fast Flux hosting at sac025.pdf.
Here is an example of the DNS of a fast flux domain (double flux) that was used in child exploitation:$ dig @NS2.WESTNS.COM wildcard.malaga-53.com a
; <<>> DiG 9.2.4 <<>> @NS2.WESTNS.COM wildcard.malaga-53.com a
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13728
;; flags: qr aa rd; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;wildcard.malaga-53.com. IN A
;; ANSWER SECTION:
wildcard.malaga-53.com. 180 IN A 68.126.240.182
wildcard.malaga-53.com. 180 IN A 70.228.170.6
wildcard.malaga-53.com. 180 IN A 68.74.207.77
wildcard.malaga-53.com. 180 IN A 70.253.85.166
wildcard.malaga-53.com. 180 IN A 67.37.184.67
;; Query time: 145 msec
;; SERVER: 67.190.128.40#53(67.190.128.40)
;; WHEN: Sun Sep 3 17:xx:xx 2006
;; MSG SIZE rcvd: 120 Here are the hostnames of those A-record addresses. Note that they are all dynamic broadband names typical of botnet zombies:[67.37.184.67] adsl-67-37-184-67.dsl.chcgil.ameritech.net.
[70.228.170.6] ppp-70-228-170-6.dsl.emhril.ameritech.net.
[68.74.207.77] adsl-68-74-207-77.dsl.milwwi.ameritech.net.
adsl-68-74-207-77.dsl.milwwi.sbcglobal.net.
[70.253.85.166] ppp-70-253-85-166.dsl.austtx.swbell.net.
[68.126.240.182] ppp-68-126-240-182.dsl.irvnca.pacbell.net.
[67.190.128.40] c-67-190-128-40.hsd1.co.comcast.net.And finally, here are the A-records for the NS hosts, again on botnet zombies:$ dig @ns2.WESTNS.COM ns2.westns.com a
; <<>> DiG 9.2.4 <<>> @ns2.WESTNS.COM ns2.westns.com a
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53259
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 4
;; QUESTION SECTION:
;ns2.westns.com. IN A
;; ANSWER SECTION:
ns2.westns.com. 180 IN A 70.115.193.8
;; AUTHORITY SECTION:
westns.com. 180 IN NS ns2.westns.com.
westns.com. 180 IN NS ns4.westns.com.
westns.com. 180 IN NS ns3.westns.com.
westns.com. 180 IN NS ns5.westns.com.
westns.com. 180 IN NS ns1.westns.com.
;; ADDITIONAL SECTION:
ns4.westns.com. 180 IN A 24.98.2.58
ns3.westns.com. 180 IN A 67.184.161.182
ns5.westns.com. 180 IN A 24.163.92.147
ns1.westns.com. 180 IN A 70.245.189.179
;; Query time: 2359 msec
;; SERVER: 67.190.128.40#53(67.190.128.40)
;; WHEN: Sun Sep 3 18:xx:xx 2006
;; MSG SIZE rcvd: 198
|
| What's ARP (Address Resolution Protocol) daemon spoofing? |
|
http://thespamdiaries.blogspot.com/2006/02/new-host-cloaking-technique-used-by.html
It's a tricky way for a spammer to make their spam appear to come from a different IP than their dedicated server, but still on the same VLAN subnet.
To avoid the problem, design your VLAN so that:
- customers can't snoop on each other, even at broadcast level such as arp traffic;
- no customer can send out packets with any source IP other than their assigned one;
- no customer can generate ARP traffic for any IPs other than their own.
As for identifying what server it really is, can you put a port monitor on the switch port of your router and sniff its packets? You should be able to see the MAC address of anything returned from those IP addresses, even if they were injecting forged packets from somewhere else on the Internet. And you should be able to see the gratuitous ARPs.
This technique is in use in the wild. If you detect this on your network, Spamhaus would very much appreciate any details you can provide, including connection information for the spammer's "home base." |
| Got any info on PHP Nuke exploits? |
|
PHP-Nuke Script Insertion Vulnerabilities
Note that the webmail module has been removed from the PHP-Nuke distribution due to its poor security since version 7.2 (march 2004). Using a more recent distribution of PHP-Nuke is of no help if the webmail module has been retained from a previous release, or has been downloaded later from some other site as an "add-on".
Also note that, according to user reports, it appears to be insufficient to disable the webmail feature to prevent the scammers from using it. You must delete the webmail module, causing removal of all the related files from the server. |
| Why should I worry about reverse DNS (rDNS)? |
|
Reverse DNS (rDNS) consists of mapping IP addresses into hostnames. While most Internet applications do not require rDNS to work, there are several reasons why defining rDNS in your network is highly desirable:
- publishing rDNS allows people to associate quickly and easily your IP address with your domain name, and therefore it makes easier to report abuse from your IP address space to your abuse desk (abuse@domain)
- publishing information about dynamically assigned IPs greatly helps other networks to distinguish the nature of different mail sources in your network (mail servers vs infected end user machines), and to block SMTP connections from dynamic addresses (if they wish to do so) without guessing and risking to inadvertently block mail servers
- publishing proper rDNS for statically assigned IPs - and in particular for those corresponding to proper mail servers - greatly reduces the likelihood that other networks will block those servers by mistake, thinking that their IP belongs to residential dynamic space
- moreover, some networks are refusing mail from IP addresses without rDNS defined
- on the client side, there are security benefits in running applications such as ssh from an IP with rDNS assigned
|
| How do I get rDNS working? |
|
You need to get a delegation of the reverse DNS zone, and then configure the zone. If your network is, say, 198.51.100.0/24, "getting a delegation" means having a NS record for 100.51.198.in-addr.arpa pointing to your nameservers, while "configuring the zone" means inserting the right information in the corresponding zone file in your nameservers.
Getting a delegation
You get a rDNS delegation from the same entity that gave you the IP addresses: it may be the ISP you are taking connectivity from, or the regional Internet registry of your area.
Regional Internet Registries (RIR) have formal procedures for assigning rDNS delegations: follow the links pertinent to your registry.
Configure the zone
For general information about defining a reverse zone in your nameservers, see for instance
the APNIC guide or the RIPE pages linked above.
Note that you do not need to insert all the individual records by hand. If you are using Bind, once you have defined a naming convention for a portion of your space you can use the powerful $GENERATE directive (described in the Bind 9 manual) to define several records with a single line.
For instance, you can write in the 100.51.198.in-addr.arpa zone file:
$ORIGIN 100.51.198.in-addr.arpa.
$GENERATE 1-254 $ PTR adsl-$-100-51-198.dynamic.example.net.
which is equivalent to 254 lines
1.100.51.198.in-addr.arpa. PTR adsl-1-100-51-198.dynamic.example.net.
...
254.100.51.198.in-addr.arpa. PTR adsl-254-100-51-198.dynamic.example.net.
Do not forget to check that matching forward A records are defined in the zone of example.net. This is very important because it "validates" the rDNS information. You can define them with another $GENERATE directive, like
$ORIGIN dynamic.example.net.
$GENERATE 1-254 adsl-$-100-51-198 A 198.51.100.$
which is equivalent to 254 lines
adsl-1-100-51-198.dynamic.example.net. A 198.51.100.1
...
adsl-254-100-51-198.dynamic.example.net. A 198.51.100.254
|
| What rDNS naming convention should I use? |
|
Make it easier for other networks to identify your dynamic ranges, and thus to filter more appropriately, by using a fixed string like dynamic or dialup as a subdomain immediately below your main domain (also called "right anchored"). Put the geographical information (if it applies to your case) at the next level, and the most variable information (like the last octet of the IP) at the outer, left-most level. Use dots as separators rather than dashes or other symbols so as to create subdomains, and put the most variable information on the left-most part of the name. For instance, this is a good naming scheme:
123.adsl7.timbuktu.dynamic.example.com
Clearly the same information could be made available with another scheme like
dadsl7-123-tktu.example.com, but other people would have to define complex regular expressions to parse that, wasting resources and increasing the likelihood of making mistakes.
If you need to include the IP address or a part of it in the hostname, reverse the order of the octets, again to have the most variable information at the outer level. For instance, the reverse DNS for 203.0.113.167 should preferably be
167.113.0.203.timbuktu.dynamic.example.com
rather than 203.0.113.167.timbuktu.dynamic.example.com.
We also recommend to use similar conventions to identify static IPs and business connections as clearly as possible. For instance, you can use something like:
245.sdsl.timbuktu.business.static.example.com
Such a scheme helps your business customers to maintain good SMTP deliverability to other networks even when neighboring dynamic IP ranges are infected with bots and send spam. Assigning custom rDNS to properly identify mail servers of responsible customers is also a good practice, for example:
mail.example.com
|
| My customer says it's not them; is that true or an excuse? |
|
Some of the excuses commonly used by spammers and signs they are spammers:
- it was a customer of a customer or a reseller;
- it was affiliates (fake and real);
- the server was hacked (Sanford Wallace' "Hacker X" excuse)
- it's opt-in (the list they bought said so!);
- it's Double Opt In! We have IPs! (may come from "web bugs" in spam)
- it's not us, it's just our business model;
- moving servers around to new IPs or "morphing";
- using lots of domains, often with anonymized "whois";
- they turn servers back on as soon as the heat is off;
- spam is sent from a different network than their web hosting;
- using "VoIP" as an excuse to cover up proxy hijacking;
- insisting that proxy hijack software was installed by a virus (it's not; it is large, dedicated software installed intentionally by a server administrator to spam).
- let me tell you about my business model...
Other commonly seen tricks:
- redirector URLs on throwaway pages land at their "bulletproof" site hosted with you;
- VPN tunnels and port forwarding to hide from packet-sniffing (use traffic flow analysis);
- using multiple small blocks of IPs instead of a single aggregated block to camouflage spam sources, also used to game search engine optimization algorithms;
- asymetric routing via dynamic pools (rare);
- scripts installed on the same server as an MTA to send mail without leaving log tracks;
- firewalling the host's corporate IPs so the host can't see the spammer's website.
Steps to keeping your network free of spammers:
1. Review your new customers before you sell them accounts. Treat unusual requests with suspicions. If an offer sounds too good to be true, it probably is.
2. On your IP addresses, use "reverse DNS" which points to your domain.
3. Be sure to read "abuse@your domain" every day, and have your upstream provide you with spam reports sent to them about your IPs.
4. Establish "feedback loops" with SpamCop, AOL, and other networks as noted on this FAQ page (top), and read your role accounts every day.
5. When spam is reported, take prompt action to stop it.
6. Do not trust spammers; they are inherently dishonorable people.
7. Treat with extra suspicion clients who say their business involves "mailing".
8. Don't give mailer clients large IP address ranges and allow them to use port-25 out on every IP. Limit them with your routers or firewalls. AOL or Hotmail/MSN only use a handful of IPs for tens-of-millions of users and tremendous mail volumes; why would your client need more? |
| How do I control affiliate spammers? |
|
Some Internet businesses use "affiliate" advertising. They pay a commission to partners who drive traffic to their website, for example. While such programs can be effective, they can also be attractive nuisances for spammers. If the spamming remains uncontrolled, such programs may have their IPs listed in SBL as spam support services (SMTP, HTTP, DNS). Here are some ideas for keeping spammers away from your affiliate program:
- Verify each affiliate's real identity and check that they don't have a spammy history before they are allowed in the program.
- Delay commission payments for 30 to 60 days and/or require paid-in-advance forfeitable damage deposit.
- Have a strong Acceptable Use Policy which prohibits spam and terminate promptly for spam with no payment nor refund of deposit. (see http://www.spamhaus.org/isp/ )
- Maintain your role accounts and feedback loops and process them daily.
- Register affiliate sending IPs, domains and the domains they will use for URLs, and update www.abuse.net to report those domains to you (and the domain's ISP).
- Monitor webserver logs for unusual traffic bursts from particular affiliates.
- Monitor "referer" headers in webserver logs for unusual traffic bursts from unexpected sources.
- Don't accept HTTP referals from domains in domain blocklists, nor from IPs in SBL or XBL.
- Be suspicious of freshly registered domains and don't allow anonymized whois or bogus registration info among your affiliates' domains.
- Point URLs for terminated affiliates' accounts to a "404" or similar non-promotional page which shows that you do terminate them and that you aren't trying to drum up traffic via disposable spam accounts. (That's mandatory for SBL removal.) |
| We're a USA based ISP and a spammer is threatening to sue us if we block his spam. Can he? |
|
In the USA, it's easy to sue anyone for anything, frivolous suits abound. But in this case, the US Congress put into the otherwise poor CAN-SPAM law a provision that states an ISP cannot be held liable for any "good faith to block the transmission or receipt of unsolicited commercial e-mail". The full text of this section is quite clear:SEC. 4 (c)(1) ISP HELD HARMLESS FOR GOOD FAITH PRIVATE ENFORCEMENT- An ISP is not liable, under any Federal or State civil or criminal law, for any action it takes in good faith to block the transmission or receipt of unsolicited commercial e-mail.
Any spammer bringing such an action or threatening it probably knows the law very well. The filing of such an action could be considered a frivolous suit or a SLAPP suit. Based on this, one may wish to ask for additional punitive damages beyond the court costs when one requests the dismissal of any such suit. |
| Some tips on IP allocation and identification |
|
https://www.arin.net/resources/request/reassignments.html
"ARIN requires organizations to submit information for all IPv4 reassignments of /29 and larger and IPv6 reassignments of /56 or shorter prefix within seven days of the sub-delegation...There are two options for reporting reassignment information: SWIP and Rwhois."
Provide proper rDNS to distinguish dynamic from static ranges. Lack of rDNS normally means dynamic.
Mark your outbound mail hosts with SPF. Another handy SPF tools is here. |
|
