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/ > >