North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Even you can be hacked

  • From: Henry Linneweh
  • Date: Fri Jun 11 16:13:00 2004

Here are a list of very active ports that attempt to
hack into peoples systesm from various parts of the
world China in particular. 

I think unassigned ports should be dropped from
routing
tables unless they are registered with the host and or
providers as to their legitimate use....


smpnameres     901/tcp      SMPNAMERES
smpnameres     901/udp     SMPNAMERES
blackjack      1025/tcp    network blackjack
blackjack      1025/udp   network blackjack
cap            1026/tcp   Calender Access Protocol
cap            1026/udp   Calender Access Protocol
exosee         1027/tcp   ExoSee
exosee         1027/udp   ExoSee
#              1124-1154  Unassigned
ssslic-mgr     1203/tcp    License Validation
ssslic-mgr     1203/udp   License Validation
ms-sql-s       1433/tcp   Microsoft-SQL-Server 
ms-sql-s       1433/udp   Microsoft-SQL-Server 
ms-sql-m       1434/tcp   Microsoft-SQL-Monitor
ms-sql-m       1434/udp   Microsoft-SQL-Monitor    
#              6851-6887  Unassigned
monkeycom      9898/tcp   MonkeyCom
monkeycom      9898/udp   MonkeyCom

And I need a list that shows who or what owns Dynamic
and/or Private Ports

-Henry

--- "Laurence F. Sheldon, Jr." <[email protected]>
wrote:
> 
> Andy Dills wrote:
> 
> > On Thu, 10 Jun 2004, Laurence F. Sheldon, Jr.
> wrote:
> > 
> > 
> >>Jeff Shultz wrote:
> >>
> >>
> >>
> >>>But ultimately, _you_ are responsible for your
> own systems.
> >>
> >>Even if the water company is sending me 85%
> TriChlorEthane?
> >>
> >>Right.  Got it.  The victim is always responsible.
> >>
> >>There you have it folks.
> > 
> > 
> > Change the word "victim" to "negligent party" and
> you're correct.
> > 
> > Ignoring all of the analogies and metaphors, the
> bottom line is that ISPs
> > are _not responsible_ for the negligence of their
> customers, and that ISPs
> > are _not responsible_ for the _content_ of the
> packets we deliver. In
> > fact, blocking the packets based on content would
> run counter to our sole
> > responsibility: delivering the well-formed packets
> (ip verify unicast
> > reverse-path) where they belong.
> > 
> > Remember, we're service providers, not content
> providers. Unless your AUP
> > or customer contract spells out security services
> provided (most actually
> > go the other way and limit the liability of the
> service provider
> > specifically in this event), then your customers
> have to pay you to secure
> > their network (unless you feel like doing it for
> free), or they are
> > responsible, period.
> > 
> > As far as I'm concerned, that guy would have a
> better shot at suing
> > Microsoft then challenging his bandwidth bill.
> > 
> > Andy
> > 
> > ---
> > Andy Dills
> > Xecunet, Inc.
> > www.xecu.net
> > 301-682-9972
> > ---
> > 
> 
> 
> How many more of these do I need, do you think?
> 
> -- 
> Requiescas in pace o email
> 
> Ex turpi causa non oritur actio
> 
> http://members.cox.net/larrysheldon/
> 
>