To shift this to a more operational tone...
Networks make choices. One choice is to declare their dynamic space and put
the duty of ignoring emails from dialups users on the receiving networks.
Another choice is to filter port 25. Filtering port 25 has its own costs -
some users are offended/bothered by this, since they can't use their own
corporate mail servers, in some cases.
If a network makes the choice of putting the duty of filtering on the
receiving party, they need to accept that this will upset some of those
receivers. Today's security environment means that spam-sending viruses are
common.
The only responsible thing to do is filter port 25, smarthost for your
users, and inform them about using the alternate submission port with
authenticated SMTP in order to work with enterprise mail servers - or IPSec
VPNs, for that matter. This is simply the best practice, at this point in
time. Using humans ("dedicated staff person") to stop spam isn't scalable -
automated processes are sending this stuff, we need systematic ways to fight
it - black/white lists, SPF, port 25 filtering, bayesian filtering and other
tools.
I'd add on to this in one area. Dan's text is good as far as it goes. What I'd add is:
Implement Reasonable and Easily Handled INADDR
1) By this I mean provide PTR records for all ports
2) for dialup, DSL and Cable users on dynamic ports who should not generally be running servers, name the INADDR with something like:
w-x-y-z.dialup.example.net
w-x-y-z.dynamic.example.net
or similar. I don't care what scheme you want to use to the LEFT of 'dialup.example.com' or 'dynamic.example.com' but please put the information about these being dynamic blocks in a place where they can be filtered using simple mechanisms (i.e. without regex overheads).
With the naming above, it's easy to filter out dialup.example.com in the access lists of mail servers without any worries. Users coming in from those addresses using authenticated connections to the submission port will work fine, while spam direct from those machines will not work.
Many ISPs do this quite well. While it's still some work for the receiving systems vs. port 25 filtering, it sure beats guessing about remote topologies.
Also note that while some large ISPs have handed out IP address ranges of dynamically assigned address in the past, telling others they can block from those addresses, this results in stale data almost instantly. Keeping this type of thing based on PTR records in DNS means the owner of that space has the job of maintaining the designations, as it should be, and avoids pushing that task onto recipients.
3) Provide proper PTR records for your business customers. A PTR record of .biz.example.net sure looks a lot more questionable than office.example.com (where example.com is a small business, let's say).
4) Think about the other guy. If you have issues identifying what to block on your inbound flows, perhaps you might think about how your naming and other policies affect how others see your outflow. Cooperation makes things better for everyone.
<snip good info>
2) for dialup, DSL and Cable users on dynamic ports who should not
generally be running servers, name the INADDR with something like:
w-x-y-z.dialup.example.net
w-x-y-z.dynamic.example.net
or similar. I don't care what scheme you want to use to the LEFT of
'dialup.example.com' or 'dynamic.example.com' but please put the
information about these being dynamic blocks in a place where they can be
filtered using simple mechanisms (i.e. without regex overheads).
With the naming above, it's easy to filter out dialup.example.com in the
access lists of mail servers without any worries. Users coming in from
those addresses using authenticated connections to the submission port will
work fine, while spam direct from those machines will not work.
Many ISPs do this quite well. While it's still some work for the receiving
systems vs. port 25 filtering, it sure beats guessing about remote
topologies.
FYI - I've been tracking rDNS naming conventions for many ISPs for the
past year and a half. (Basically, if your network is secure, I don't
know about you - I only track rDNS for hosts that relay spam or spew
viruses at me). Of the approximately 4800 networks (by domain) I've
tracked, 1935 are known to be in the US, Mexico, or Canada. Of those,
509 have some form of RHS-friendly rDNS. Roughly 26%. Better than last
year, but still pretty bad.
cgocable.ca cabletv.on.ca aci.on.ca eastlink.ca
powergate.ca primus.ca sympatico.ca ubc.ca
uoguelph.ca uniserve.ca utoronto.ca videotron.ca
netidea.bc.ca ulaval.ca ualberta.ca dal.ca
uottawa.ca uwo.ca connection.ca terago.ca
accesscomm.ca ucc-net.ca sfu.ca yorku.ca
ncf.ca rushcomm.ca eol.ca mcgill.ca
oricom.ca vdn.ca amdsb.ca umontreal.ca
cyberus.ca knet.ca magma.ca mcmaster.ca
usherbrooke.ca cgi.ca unb.ca sprintdsl.ca
aol.com aracnet.com atlantabroadband.com attbi.com
insightbb.com mchsi.com bbtel.com ccapcable.com
cerfnet.com charter.com dancris.com execulink.com
mindspring.com nexband.com rcn.com redshift.com
ripnet.com rogers.com rr.com theplanet.com
wideopenwest.com xmission.com cablenet-va.com charter-ala.com
cox-internet.com quik.com gvtc.com bah.com
lan2wan.com westelcom.com power1.com mdsg-pacwest.com
eschelon.com gvtel.com nettally.com octapus.com
firstlink.com hbci.com iinet.com naxs.com
ntplx.com tfb.com srtnet.com theriver.com
vcn.com visi.com webhostplus.com winbeam.com
gtlakes.com varian.com royaume.com primarydns.com
netdoor.com registeredsite.com bearingpoint.com core.com
tvc-ip.com teksavvy.com opt2opt.com quiknet.com
srt.com pcspeed.com cadvision.com mynethost.com
800hosting.com scrtc.com speede.com warpdriveonline.com
wavecable.com lightyearcom.com midmaine.com prairieweb.com
c2bandwidth.com innercite.com cintelecom.com hyperusa.com
seanet.com cwia.com mcttelecom.com osp-chicago.com
primenet.com fire2wire.com calltech.com anobi.com
telus.com hyatthsiagx.com spiritone.com aesirnetworks.com
foxinternet.com willscot.com acetechusa.com aeanetwork.com
alabanza.com arishost.com calpop.com computechnv.com
datapeer.com fatcow.com iwaynetworks.com linuxwebnet.com
mobilenetics.com skybitz.com tir.com unitedcolo.com
zedcom.com zoolink.com crestviewcable.com mipops.com
neteze.com wilnet1.com conninc.com asu.edu
berkeley.edu brown.edu bucknell.edu cmich.edu
cmu.edu colorado.edu columbia.edu cornell.edu
csulb.edu csuohio.edu dartmouth.edu duke.edu
ecu.edu fsu.edu furman.edu gac.edu
gatech.edu harvard.edu hawaii.edu indiana.edu
msu.edu ncsu.edu nodak.edu pepperdine.edu
psu.edu purdue.edu rit.edu siu.edu
swt.edu tamu.edu ttu.edu ua.edu
ucla.edu ucsd.edu uga.edu uh.edu
uidaho.edu uiowa.edu uiuc.edu umass.edu
umd.edu umich.edu unc.edu unt.edu
upenn.edu uri.edu usf.edu utexas.edu
utk.edu utoledo.edu uwec.edu vt.edu
wsu.edu wwu.edu drexel.edu brockport.edu
macalester.edu ou.edu arizona.edu mnscu.edu
wustl.edu ilstu.edu uci.edu clarkson.edu
missouri.edu ncat.edu usc.edu uky.edu
yale.edu ufl.edu vanderbilt.edu clemson.edu
du.edu kent.edu trinity.edu upr.edu
csuchico.edu depaul.edu bloomu.edu cmsu.edu
msoe.edu neu.edu utah.edu uaf.edu
alaska.edu trincoll.edu marshall.edu pitt.edu
northwestern.edu temple.edu maine.edu albany.edu
uno.edu virginia.edu cwru.edu emich.edu
tcu.edu buffalo.edu byu.edu uconn.edu
rpslmc.edu emory.edu vcu.edu unco.edu
cabrini.edu wm.edu pdx.edu carleton.edu
jhu.edu mtu.edu utc.edu ualr.edu
colostate.edu washington.edu uwp.edu nyu.edu
gsu.edu smu.edu wisc.edu wilkes.edu
roch.edu uchicago.edu iupui.edu okstate.edu
cablered.com.mx podernet.com.mx avantel.net.mx infosel.net.mx
alestra.net.mx 1st.net 21stcentury.net acsalaska.net
adelphia.net airmail.net algx.net allstream.net
alltel.net ameritech.net att.net attwireless.net
bellatlantic.net bresnan.net bright.net btitelecom.net
centurytel.net cgocable.net chartertn.net comcast.net
comporium.net cnc.net coretel.net covad.net
cox.net cypresscom.net dsl.net earthlink.net
eatel.net enter.net frontiernet.net genuity.net
globetrotter.net graceba.net grandecom.net grouptelecom.net
gtei.net gte.net igs.net ij.net
infoave.net iowatelecom.net level3.net madisonriver.net
mcleodusa.net mnsi.net mountaincable.net mts.net
navix.net netins.net networktel.net nextweb.net
ntelos.net nvbell.net one.net optonline.net
pacbell.net personainc.net ptd.net prserv.net
quickclic.net qwest.net ricochet.net rmci.net
shawcable.net sigecom.net snet.net speakeasy.net
starband.net surewest.net swbell.net tds.net
telus.net telusplanet.net tht.net twtelecom.net
uslec.net uswest.net uu.net verizon.net
voyager.net warwick.net xo.net e-nt.net
k-state.net sprint-canada.net sprint-hsd.net terranova.net
nauticom.net socket.net ziplink.net epix.net
kci.net kmcmail.net abac.net earthnet.net
gwtc.net ctsmail.net accessus.net aloha.net
beld.net above.net stargate.net redwing.net
chilitech.net uswo.net logical.net golden.net
win.net verio.net tachyon.net chartermi.net
sherbtel.net charterpipeline.net mercury.net lmi.net
concentric.net airstreamcomm.net alerondial.net arrival.net
atlantech.net atlantic.net bluegrass.net charlevoix.net
corecomm.net evertek.net frii.net garlic.net
hargray.net hicv.net inter.net intermonde.net
internorth.net iquest.net mwt.net prairieinet.net
rcnetworks.net restel.net wcom.net velocitus.net
wt.net vnet.net brightok.net spacestar.net
digitalpath.net hexcom.net shentel.net qx.net
comcastbusiness.net volcano.net qis.net fcc.net
dandy.net interdial.net psi.net lan2wan.net
pacificcoast.net impulse.net incentre.net forethought.net
sover.net itlnet.net grandenetworks.net llix.net
openband.net tns.net dsl-only.net metalink.net
mich.net dasia.net hereintown.net cwis.net
sunset.net thebiz.net donobi.net mw.net
nac.net speedfactory.net sbcglobal.net texas.net
alliancecom.net westpa.net uiowa.net rrv.net
bway.net axs2000.net centennialpr.net cfu.net
kansas.net anc.net acceleration.net ao.net
aoltw.net alter.net cari.net eli.net
sfl.net dti.net santel.net exatt.net
swva.net fastfreedom.net mzima.net rnetinc.net
hiwaay.net imaginenet.net cloud9.net ncia.net
infocrossing.net inreach.net lincon.net mags.net
mfnx.net mcisi.net sagonet.net servint.net
sitestream.net worldspice.net shreve.net xtelegent.net
island.net means.net relia.net hickorytech.net
brtc.net luhs.org pmt.org wbdl.org
carrollton.al.us
NOTE: not everyone listed here uses RHS-friendly rDNS consistently, these
are just the folks we've managed to discover are using it at all.
<snip even more good info>
The company I work for hand out static IP addresses to all DSL subscribers
(one IP only per subscriber in all cases). Is there a BCP as to what to do
with this regarding registering with RBL etc, so we won't get our entire
netblock blacklisted when a single subscriber gets
backdoored/trojaned/virusinfected?
[snip]
Another choice is to filter port 25. Filtering port 25 has its own
costs - some users are offended/bothered by this, since they can't
use their own corporate mail servers, in some cases.
[snip]
SUBMIT, SASL, etc. This is a solved problem; if MS "Lookout! Virus
Express!" supports it, your know it isn't rocket science.
SMTP 25 is for inter-server traffic. There is absolutely no reason
for end-user pseudo-MTAs to use it. Some networks will enforce it.
Expect that and move on.
The only responsible thing to do is filter port 25,
> smarthost for your users, and inform them about using the
> alternate submission port with authenticated SMTP in order
> to work with enterprise mail servers - or IPSec VPNs, for
> that matter. This is simply the best practice, at this point
> in time. Using humans ("dedicated staff person") to stop
> spam isn't scalable - automated processes are sending this
> stuff, we need systematic ways to fight it - black/white
> lists, SPF, port 25 filtering, bayesian filtering and other
> tools.
Let's put this in perspective. Say a hypothetical sysadmin were to
disable any and all authentication on his SSH server. And that
someone then used SSH from your network to run code that sysadmin
didn't like on that machine. Would you then consider it reasonable if
the sysadmin proposed:
The only responsible thing to do is filter port 22, smarthost for
your users, and inform them about using the alternate submission
port with authenticated SSH in order to work with enterprise SSH
servers - or IPSec VPNs, for that matter. This is simply the best
practice, at this point in time.
For that matter would anyone take seriously someone who then proposed
as a solution to the "breakin"[1] that:
we need systematic ways to fight it - black/white lists, SSH
Permitted From, port 22 filtering, bayesian filtering and other
tools
in order to filter out "harmful commands" while allowing anything else
to get through without ever once suggesting enabling passwords or SSH
keys?
If you don't want to accept mail from anyone and everyone then make
them use a password or a key to send mail to you. There are several
ways to do this right now. (For example, procmail is your friend.)
If you don't like something that arrives in your house figure out a
way to put a lock on your door. Don't insist everyone else is at
fault because they wouldn't put bars over their own.
:Let's put this in perspective. Say a hypothetical sysadmin were to
:disable any and all authentication on his SSH server. And that
:someone then used SSH from your network to run code that sysadmin
:didn't like on that machine. Would you then consider it reasonable if
:the sysadmin proposed:
:
: The only responsible thing to do is filter port 22, smarthost for
: your users, and inform them about using the alternate submission
: port with authenticated SSH in order to work with enterprise SSH
: servers - or IPSec VPNs, for that matter. This is simply the best
: practice, at this point in time.
:
Apples & oranges; thanks for playing, please try again...
OK, now let's make it more in line with modern practice:
Say a protocol more or less completely lacked server-server
authentication, or a way to distinguish between client and server, and
that then every day, for ten years, hundreds and thousands of
professional criminals used weaknesses in the monopoly OS to plant
software completely under their control on fifty million (or so) of
these vulnerable hosts, and then took advantage of the aforementioned
weakness in the protocol to own anywhere from a quarter to 90% of all
inbound transmissions to your server- all selling illegal, immoral, or
extralegal services and products, to the point that some users of that
protocol literally drown in said deluge, and also that a major
proportion of said submissions were addressed to users who don't exist,
never existed, only exist because of inventive viruses (see "monopoly
OS"), or completely fictional and created by aforementioned professional
abusers, and sold to other naive abusers, or were the helpful notices
provided to said forged addresses after accepting the submissions,
rather than rejecting at submission time. Oh, and outbound connections
aren't expected from the vast majority of those hosts.
Yes, I think this a reasonable response to use everything at our
disposal to refuse the majority of the unwanted submissions.
But hey, I'm just a mail admin with 65% inbound mail identified as
abusive. Obviously I don't have any of these hypothetical concerns.
OK, now let's make it more in line with modern practice:
> Say a protocol more or less completely lacked server-server
> authentication, or a way to distinguish between client and
> server, and that then every day, for ten years, hundreds and
> [...]
> after accepting the submissions, rather than rejecting at
> submission time. Oh, and outbound connections aren't
> expected from the vast majority of those hosts.
Are you saying that since you have never had to lock your door before
you shouldn't be required to install one now?
> Yes, I think this a reasonable response to use everything at
> our disposal to refuse the majority of the unwanted
> submissions.
Wouldn't "everything at our disposal" include developing and
installing locks? Wouldn't that be an obvious first step? Would your
first reaction to finding your house burgled be to phone all the
builders of houses in your neighborhood and demanding they make it
impossible for anyone else to leave their house?
> thousands of professional criminals used weaknesses in the
> monopoly OS to plant software completely under their control
> on fifty million (or so) of these vulnerable hosts,
For email viruses the monopoly OS is not the only cause of blame
(although its manufacturer helped a lot in other ways). If one allows
someone to use an MUA that executes code in Turing complete languages
one has already essentially done what our hapless hypothetical
sysadmin did with authenticationless SSH. The only difference is that
our hypothetical sysadmin will have implemented an interactive system
whereas such MUAs will have implemented a batch system with an awkward
JCL called MIME. Viruses (of the email type that is) spread so easily
because we have not made it clear enough that using one of these MUAs
has the same security implications as letting any user start an
anonymous telnet server.
Yet here too all sorts of strange recommendations are made[1].
Suggestions that would never even be considered if a sysadmin was
actually faced with a user running an anonymous telnet server.
Suggestions which by and large avoid doing what we all would do in an
instant if we were faced with this problem in its telnet guise:
requiring authentication. Does your security policy allow users to
implement authenticationless command servers? If not do you prohibit
the batch command servers that many MUAs have become?