[unisog] Re: {SPAM?} Re: [unisog] sendmail vulnerability / impact

Ken Connelly Ken.Connelly at uni.edu
Fri Mar 7 20:00:28 GMT 2003


Phil.Rodrigues at uconn.edu wrote:

>What are the issues with blocking outbound port 25 traffic except from 
>"registered" or known mail servers?  I am interested in doing it to help 
>block outbound viral infections that use email to spread (like most of 
>them).
>
>One concern I heard voiced is that it would impact people's ability to pop 
>their mail from an external server.  Any others?
>
???  POP3 would have a destination port of 110 (995 for the encrypted 
flavor).  Blocking outbound 25 would have no impact on that at all...

- ken

>
>Phil
>
>PS - We aggressively scanned for sendmail servers on campus, and are 
>working with their admins to get them patched.  We have no plans to block 
>inbound port 25 based on the sendmail vulnerability alone.  If a 
>wide-scale exploit was available our stance would change.
>
>=======================================
>Philip A. Rodrigues
>Network Analyst, UITS
>University of Connecticut
>
>email: phil.rodrigues at uconn.edu
>phone: 860.486.3743
>fax: 860.486.6580
>web: http://www.security.uconn.edu
>=======================================
>
>
>
>
>
>"H. Morrow Long" <morrow.long at yale.edu>
>03/07/2003 11:39 AM
>
> 
>        To:     Robin Anderson <robin at umbc.edu>
>        cc: 
>        Subject:        {SPAM?} Re: [unisog] sendmail vulnerability / impact
>
>
>We have a plan to block all TCP port 25 traffic into our campus network
>beginning this summer.  We are just in the planning stage.  We plan to
>offer MX records for any hosts/departments who insist that they need to
>run their own Email servers and receive email on them.  The MX records
>would provide for automatic relaying via our main campus email relays.
>We already offer this as a service to departments (having mail for their
>hosts/domains relayed from the Internet to/them via our relays and MX).
>In a very few cases we may 'punch' TCP port 25 'holes' through the block
>to some servers.  We are looking at automating the request procedure for
>requesting MX record and relaying and/or an exception to the port 25 
>block.
>
>BTW, though security plays a part (particularly since the sendmail 
>security
>hole) the primary reason we are interested in this is to prevent more 
>spamming
>via open relays when people accidently bring up SMTP servers.
>
>H. Morrow Long
>
>Robin Anderson wrote:
>  
>
>>In response to the most recently published sendmail vulnerability, we 
>>    
>>
>were
>  
>
>>given permission to block inbound port 25 traffic at our ResNet border.
>>To date, we've only received one complaint about this action, but our 
>>    
>>
>CIO
>  
>
>>wants us to ask other university security folks about what they have 
>>    
>>
>done.
>  
>
>>So here goes:
>>
>>1) Has anyone else summarily blocked port 25 traffic (in or out) for
>>   their ResNet?
>>
>>  a) If you have NOT blocked port 25, have you had problems/incidents
>>     relating to the sendmail vulnerability?  Do you have a generally
>>     laissez-faire approach to ResNet, or do you try to alert them to 
>>    
>>
>new
>  
>
>>     vulnerabilities, fixes, etc?
>>
>>  b) If you HAVE blocked port 25, do you have any data to support it as 
>>    
>>
>a
>  
>
>>     good decision?  (I know it's hard to prove a negative and that "we
>>     haven't been hacked, so it must be working" is sometimes the best 
>>    
>>
>we
>  
>
>>     can offer.)  Any complaints?
>>
>>
>>2) Has anyone seen evidence of the exploit (successful or not) at their
>>   site?
>>
>>Basically, our CIO is considering lifting the port 25 ban if no one has
>>seen activity related to the sendmail hole.  Even evidence of a couple
>>compromised systems or broad probes for the hole across multiple sites
>>might keep the lockdown in place.  Thanks in advance!
>>
>>---
>>Robin Anderson  Unix SysAdmin, Specialist / Security
>>Office of Information Technology               Univ. of MD, Baltimore 
>>    
>>
>County (UMBC)
>  
>
>>PGP fingerprint: (resumbc99) 1024/5B5A87A
>>DA F3 7F 1E D3 75 28 9F  75 7D 6A 0C 10 8D CE 35
>>
>>"Pulvis et umbra sumus." (We are but dust and shadow.)  --  Horace
>>    
>>
>
>
>
>
>
>  
>

-- 
- Ken
===========================================================================
Ken Connelly (KC152) Systems and Operations Manager, ITS - Network Services
University of Northern Iowa                     Cedar Falls, IA  50614-0121
email: Ken.Connelly at uni.edu    phone: (319) 273-5850    fax: (319) 273-7373






More information about the unisog mailing list