Transcript Anti-Spam SMTP Implementation

Anti-Spam SMTP
Implementation
for anonymous Dial-In
SwiNOG #5, 25.09.2002
Fredy Künzler, Init Seven AG
SPAM is a serious problem.
Better fight it at it‘s origin.
Anonymous Dial-In:
 Customer is not known
 Customer can hide his identity
(Rufnummerunterdrückung)
 In case of abuse, effort for prevention is high
and unpaid
 Complaints: Spamcop etc.
 In case of abuse, it’s only a reaction, and SPAM
has already been distributed
How Spammer abuse
anonymous Dial-in (1)
 New strategy by Spammers, as the classical Spam delivery
technique is not effective anymore (abusing an open SMTP
relay). Open SMTP relay servers are disappearing more
and more.
Reason: M$ is delivering it’s SMTP servers with default
«relay denied» these days.
How Spammer abuse
anonymous Dial-in (2)
 Spam-PC dials over ISDN (Channel Bundling, PPP Multilink)
 Spam-PC runs it's own SMTP server. Mail delivery is being done
directly to the respective MX server of the recipient. This
technique is common by well known Swiss spammers as
M.F. (Nachtsichtgeräte, overpriced digital cameras,
Brockhaus software, GPS equipment etc.) and B.W.L.
(Pfefferspray, Graphic gallery software etc.)
 as the spamming SMTP server get's the dynamic IP of the
provider, complaints will go to the providers abuse desk
Prevention (Solution #1) (1)
 disallow SMTP traffic (Port 25) leaving own backbone
 Implementation (let's assume provider has 192.168.128.0/19 and
the dial range is 192.168.136.0/24):
access-list
access-list
access-list
access-list
100
100
101
101
remark
permit
deny
permit
SMTP Block of Dial-in-Customers
tcp 192.168.136.0 0.0.0.255 192.168.128.0 0.0.31.255 eq smtp
tcp 192.168.136.0 0.0.0.255 any eq smtp
ip any any
interface FastEthernet 0/0
description connected to Internet (Upstream Provider)
ip access-group 100 out
Prevention (Solution #1) (2)
Advantage of Solution #1:
 Spammer cannot do direct MX-Delivery
Disadvantages of Solution #1:
 User must use provider’s SMTP server, even if he has a GMX or
another freemail address
 User asks support how to handle «relay denied» error messages
 Spammer still can abuse providers’s SMTP server, as it must relay
mail traffic from dial-in connections
Prevention (Solution #2) (1)
 same as solution #1, but with protected SMTP server of the
provider
 Dial-Spam-Block is used for SMTP server protection
 Dial-Spam-Block counts the number of recipients of mail delivery
for each dynamically assigned IP address
 Dial-Spam-Block stops relaying mail after limit of recipients has
been reached in a certain time frame (default: 50 recipients
per 30 minutes allowed)
Prevention (Solution #2) (2)
 potential Spammer reaches limit within 1 minute and gets a «relay
denied»
 counter is reset if dial-in user logs off (radius server sends signal to
Dial-Spam-Block)
 Dial-Spam-Block currently works with Sendmail (writes into
access.db, therefore no sendmail.cf quirk required) and
Freeradius. Communication between the two servers is
done over SSH.
Prevention (Solution #2) (3)
Advantages of Solution #2:
 Spammer cannot do direct MX-Delivery
 SMTP Server of provider is protected
Disadvantages of Solution #2:
 User must use provider’s SMTP server, even if he has a
GMX or another freemail address
 User asks support how to handle «relay denied» error
messages
Prevention (Solution #2) (4)
Dial-Spam-Block
 Concept by Fredy Künzler, Init Seven AG
(thanks to the Interconnection people)
 Developed by Marco Steinacher, Init Seven AG
 GPL (General Public License)
 Runs since March 2002 without problems in the
environment of Init Seven AG.
 Available at dial-spam-block.sourceforge.net
Prevention (Solution #3) (1)
 Redirect SMTP traffic from dial-in user to providers SMTP server.
This will ease the configuration of SMTP client. Support must
no longer handle «relay denied» questions, as any valid
hostname (i.e. mail.bluewin.ch at Init Seven’s dial-in) works
up to the limit of the dial-spam-block.
Prevention (Solution #3) (2)
 Implementation (let’s assume provider has 192.168.128.0/19 and
the dial range is 192.168.136.0/24, and the IP address of the SMTP
server is 192.168.128.10)
access-list 102 remark SMTP Redirect to SMTP server from Dial-in-Customers
access-list 102 permit tcp 192.168.136.0 0.0.0.255 any eq smtp
route-map SMTP-Redirect permit 10
match ip address 102
set ip next-hop 192.168.128.10
interface FastEthernet 0/0
description connected to Internet (Upstream Provider)
ip policy route-map SMTP-Redirect
Note that the SMTP server must not be in the IP range of dial
customers!
Prevention (Solution #3) (3)
 Configuration of SMTP server:
(requirement: kernel of SMTP server must support iptables)
iptables -A PREROUTING --table nat --protocol tcp --source \
192.168.136.0/24 --dport 25 -j DNAT --to 192.168.128.10
(Init script for Linux available at www.init7.net/anti-spam/)
Prevention (Solution #3) (4)
*) Protected with Dial-Spam-Block
Prevention (Solution #3) (5)
Advantages of Solution #3:
 Spammer cannot do direct MX-Delivery
 SMTP Server of provider is protected
 Support is no longer bothered by «relay denied» questions
(Minor) Disadvantage of Solution #3:
 'telnet host 25' no longer possible from dial-in range
Solution #3 is operational since August 2002 in the environment of Init
Seven AG
Further development
(proposed solution #4)
 Dial-Spam-Block is able to work as a «Teergrube». Instead of a hard
limit as «relay denied after 50 recipients» the SMTP delivery
could gradually slow down. For instance the first 20 recipients
are delivered instantly, than wait 2 seconds for each address
for the next 20 recipients, than wait 5 seconds etc. etc.
Links (1)
SMTP-Redirect Implementation
www.init7.net/anti-spam/
Dial-Spam-Block
dial-spam-block.sourceforge.net
Teergrube
http://www.iks-jena.de/mitarb/lutz/usenet/teergrube.en.html (English)
http://www.iks-jena.de/mitarb/lutz/usenet/teergrube.html (German)
Links (2)
Freeradius
www.freeradius.org
Sendmail
www.sendmail.org
Iptables
www.iptables.org
Questions?
Thank you.