On 9/21/04 1:00 PM, "james edwards" <hackerwacker@cybermesa.com> wrote:
Sheesh. Get over /yourself/. Your network is rude by its very existence, if it lets spammers relay crud by way of it. Your own arrogance in thinking it's not your problem to fix is astounding.
I did no say it is not my problem, we have a 10 year history of being very pro-active for all abuse issues and have a dedicated staff person to deal with these issues. Slaming my mail admin because a dial up user has a virus is rude, period. Our dial up address space is listed, if people choose to block mail from that space.
james
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. -- Daniel Golding Network and Telecommunications Strategies Burton Group
At 01:29 PM 9/21/2004, Daniel Golding wrote:
On 9/21/04 1:00 PM, "james edwards" <hackerwacker@cybermesa.com> wrote:
Sheesh. Get over /yourself/. Your network is rude by its very existence, if it lets spammers relay crud by way of it. Your own arrogance in thinking it's not your problem to fix is astounding.
I did no say it is not my problem, we have a 10 year history of being very pro-active for all abuse issues and have a dedicated staff person to deal with these issues. Slaming my mail admin because a dial up user has a virus is rude, period. Our dial up address space is listed, if people choose to block mail from that space.
james
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. -- ----------------------------------------------------------------- Daniel Senie dts@amaranth.com Amaranth Networks Inc. http://www.amaranth.com
on Tue, Sep 21, 2004 at 02:11:11PM -0400, Daniel Senie wrote: <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> -- join us! http://hesketh.com/about/careers/web_designer.html join us! hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com join us! http://hesketh.com/about/careers/account_manager.html join us!
On Tue, 21 Sep 2004, Daniel Senie wrote:
w-x-y-z.dialup.example.net w-x-y-z.dynamic.example.net
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? -- Mikael Abrahamsson email: swmike@swm.pp.se
On Tue, Sep 21, 2004 at 01:29:44PM -0400, Daniel Golding wrote: [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. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE
Daniel> The only responsible thing to do is filter port 25, Daniel> smarthost for your users, and inform them about using the Daniel> alternate submission port with authenticated SMTP in order Daniel> to work with enterprise mail servers - or IPSec VPNs, for Daniel> that matter. This is simply the best practice, at this point Daniel> in time. Using humans ("dedicated staff person") to stop Daniel> spam isn't scalable - automated processes are sending this Daniel> stuff, we need systematic ways to fight it - black/white Daniel> lists, SPF, port 25 filtering, bayesian filtering and other Daniel> 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. --------- [1] A curious term since it's hard to imagine a way to leave the door open much wider than our hapless hypothetical sysadmin has.
: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...
on Tue, Sep 21, 2004 at 05:52:12PM -0600, Allan Poindexter wrote:
Daniel> The only responsible thing to do is filter port 25, Daniel> smarthost for your users, and inform them about using the Daniel> alternate submission port with authenticated SMTP in order Daniel> to work with enterprise mail servers - or IPSec VPNs, for Daniel> that matter. This is simply the best practice, at this point Daniel> in time. Using humans ("dedicated staff person") to stop Daniel> spam isn't scalable - automated processes are sending this Daniel> stuff, we need systematic ways to fight it - black/white Daniel> lists, SPF, port 25 filtering, bayesian filtering and other Daniel> 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.
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. -- join us! http://hesketh.com/about/careers/web_designer.html join us! hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com join us! http://hesketh.com/about/careers/account_manager.html join us!
Steven> OK, now let's make it more in line with modern practice: Steven> Say a protocol more or less completely lacked server-server Steven> authentication, or a way to distinguish between client and Steven> server, and that then every day, for ten years, hundreds and Steven> [...] Steven> after accepting the submissions, rather than rejecting at Steven> submission time. Oh, and outbound connections aren't Steven> 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? Steven> Yes, I think this a reasonable response to use everything at Steven> our disposal to refuse the majority of the unwanted Steven> 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? Steven> thousands of professional criminals used weaknesses in the Steven> monopoly OS to plant software completely under their control Steven> 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? --------- [1] Suggestions like "we will filter mail for viruses". If an employee was running anonymous telnet at your place of business would your response be to attempt to write a filter that would delete any "bad scripts"? I'm pretty sure at most places the employee would be forced to stop.
participants (7)
-
Allan Poindexter -
Brian Wallingford -
Daniel Golding -
Daniel Senie -
Joe Provo -
Mikael Abrahamsson -
Steven Champeon