TCP Syns to 445 and 11768
Title: TCP Syns to 445 and 11768 Hi. Anyone notice an increase of TCP Syns to port 11768, and 445 across random internet IPs? I googled the port, and found a similar posting here: http://www.trustedmatrix.org/portal/forum_viewtopic.php?7.954 We located the source on our network, updated DATs, and WindowsUpdate hotfixes, but the problem persists. ___ Thanks, Rick Cheung This message, including any attachments, contains confidential information intended for a specific individual and purpose and is protected by law. If you are not the intended recipient, please contact sender immediately by reply e-mail and destroy all copies. You are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The sender accepts no liability for any damage caused by any virus transmitted by this email. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission.
RE: identifying application type of network traffic
Title: RE: identifying application type of network traffic I believe NBAR stats are accessible via SNMP, so you can use MRTG to graph application utilization. http://vermeer.org/display_doc.php?doc_id=6 ___ Thanks, Rick Cheung -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Adam Atkinson Sent: Thursday, December 16, 2004 11:17 AM To: NANGO Subject: RE: identifying application type of network traffic > Currently, I use (protocol, port_number) as indicator > of application. Referring to rfc on wellknown protocol > and port allocation, I can only identity about 50% of > traffic type. > > Is there a complete (protocol, port_number) list ? or > is there a better way to identify application type > based on netflow data? Cisco's "Network Based Application Recognition" can recognise quite a few things, particularly a fair few p2p applications. It looks at the actual contents of packets, not just the port numbers. This message, including any attachments, contains confidential information intended for a specific individual and purpose and is protected by law. If you are not the intended recipient, please contact sender immediately by reply e-mail and destroy all copies. You are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The sender accepts no liability for any damage caused by any virus transmitted by this email. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission.
RE: remote reboot power strips
Title: RE: remote reboot power strips We use Baytechs with much success. Not only does it allow remote reboots via the modem, it supports connectivity to the console ports via serial cables; ideal for troubleshooting or Xmodem-ing new code if necessary. http://www.baytechdcd.com/ Rick Cheung -Original Message- From: Alexei Roudnev [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 20, 2004 1:50 AM To: Roy; 'Nanog List' Subject: Re: remote reboot power strips The same. - Original Message - From: "Roy" <[EMAIL PROTECTED]> To: "'Nanog List'" <[EMAIL PROTECTED]> Sent: Monday, April 19, 2004 10:10 AM Subject: RE: remote reboot power strips > > > We use a number of both the APC Masterswitch and the WTS NPS-115 with good > results. I don't think either of them have had a failure. > > Roy > > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of > Christopher J. Wolff > Sent: Monday, April 19, 2004 8:24 AM > To: 'nanog list' > Subject: remote reboot power strips > > > > Hello, > > Last time I researched remote reboot power strips it seemed like most of the > power strips were garbage. Any recommendations for a solid performer would > be appreciated. Thank you. > > Regards, > Christopher J. Wolff, VP CIO > Broadband Laboratories, Inc. > http://www.bblabs.com > > > This message, including any attachments, contains confidential information intended for a specific individual and purpose and is protected by law. If you are not the intended recipient, please contact sender immediately by reply e-mail and destroy all copies. You are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The sender accepts no liability for any damage caused by any virus transmitted by this email. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission.
RE: Portable Fire Suppression
Title: RE: Portable Fire Suppression Well, aren't fire extinguishers supposed to explode anyway upon high temperature? Rick Cheung NPI IT Wan Team, CCNP -Original Message- From: Christopher J. Wolff [mailto:[EMAIL PROTECTED]] Sent: Friday, June 07, 2002 1:00 PM To: [EMAIL PROTECTED] Subject: Portable Fire Suppression Greetings; I would like to protect an unattended server enclosure in a remote location with some variety of fire suppression device. I imagine that some enterprising soul has invented a fire extinguisher with a nozzle that opens at a preset temperature (i.e. exploding head). Thank you in advance for any advice you can provide. Regards, Christopher J. Wolff, VP CIO Broadband Laboratories http://www.bblabs.com
RE: Arbor Networks DoS defense product
Title: RE: Arbor Networks DoS defense product Is it common practice to place your own equipment at the ISP? My thought is that if we are able to have our own routers at the ISP, we'd be in a better position to mitigate the effects of a DDOS. As long as the stream of traffic does not adversely affect our routers from performing properly at the ISP, we can then mitigate the effects through access-lists, QOS, etc. That is if the attack is not too distributed, where the source IPs with the highest amount of syn traffic for example can be easily identified. Rick Cheung NPI IT Wan Team, CCNP -Original Message- From: Pete Kruckenberg [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 15, 2002 2:15 AM To: [EMAIL PROTECTED] Subject: Re: Arbor Networks DoS defense product On Wed, 15 May 2002, Rubens Kuhl Jr. wrote: > If and when > (a) customers don't get exemption for attack traffic > (b) the DoS traffic occurs more than 5% (or 1 - your percentile level) of > the month per customer circuit > (c) the DoS increases bytes transferred like large ICMP packet flood; this > is not the case for all DoS traffic, which can be a bunch of small packets > that actually decreases traffic These might apply to noticeable DoS attacks that occur as specific events. But how much (D)DoS traffic goes unnoticed by the average customer because it's too tough to detect or defend against? The 10% I've measured on my network is primarily reflected DDoS (reflected off my customers, to off-net targets), which is not trivial to detect or defend against. Pete.
RE: PacBell Security/Abuse contact
Title: RE: PacBell Security/Abuse contact Does anyone have an opinion on a decent ISP out there that's proven to work with the customer during a DDOS storm? Rick Cheung -Original Message- From: Jeremy T. Bouse [mailto:[EMAIL PROTECTED]] Sent: Monday, March 25, 2002 2:46 PM To: [EMAIL PROTECTED] Subject: Re: PacBell Security/Abuse contact More specifically I belive this is a Distributed Reflection DoS like what hit GRC.COM back on Jan 11th... Basically a flood of SYN packets to well known ports from IPs which appear to be spoofed. I've actually been riding it out now for over 2 weeks... The tech support is completely inept and trying to contact security/abuse is pointless. Final realization of this was when I was investigating another PacBell customers box which had been compromised via another PacBell customer machine. After the forensics to get back logs and track the intrusion I tried contacting PacBell to no avail and then resulting it tryin to get in contact with their customer directly. Which I managed to do and resolve the issue... I've never dealt with such an inept company before. Jeremy On Mon, Mar 25, 2002 at 11:18:23AM -0800, Daniel M. Spielman wrote: > > At 11:11 PM 3/24/2002 -0800, you wrote: > > > Anyone have a telephone number that can reach a live person > >within Pacific Bell's Security/Abuse department? PacBell's technical > >support is completely inept with trying to help their customers when > >under any form of network attack other than passing you to a toll-free > >number which informs you to send email to an address that goes without > >answer. > > > > Respectfully, > > Jeremy T. Bouse > > UnderGrid Network Services > I've had a similar experience with their tech team. I was being > dos'd from a college in Chicago so I contacted them to have it filtered out > and they had no idea what I meant. They suggested I email the Admin at the > college to get it resolved. I started screaming at them how am i going to > email someone when I am being attacked. Then they transferred me to their > supervisor who was even more inept then they were. Frankly i gave up and > just waited out the dos attack which lasted 2 1/2 days. >
