TO UNSUBSCRIBE: email "unsubscribe issforum" in the body of your message to [EMAIL PROTECTED] Contact [EMAIL PROTECTED] for help with any problems! ----------------------------------------------------------------------------
That's the return packet (probably a SYN-ACK) establishing the second half of the connection -- ie when a client sends a SYN to a server to open a connection, the server responds with a SYN-ACK that simultaneously acknowledges the connection request and sets up the return half of the conversation. This is why the next XPU (which will hopefully contain the signatures for this worm) is being awaited so anxiously... -----Original Message----- From: "rajesh vasudevan" <[EMAIL PROTECTED]> Sent: Tuesday, May 28, 2002 10:28 AM To: [EMAIL PROTECTED];[EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: Connection event for port 1433 (Sent by [EMAIL PROTECTED] on behalf of "rajesh vasudevan" <[EMAIL PROTECTED]> ) TO UNSUBSCRIBE: email "unsubscribe issforum" in the body of your message to [EMAIL PROTECTED] Contact [EMAIL PROTECTED] for help with any problems! ---------------------------------------------------------------------------- HI, I am also facing the same problem, network sensors are capturing port 1433 events in a " Reverse Way" !!! Here we are getting events with source port 80 and destination port 1433, but in real the tcp connection was established in a reverse way ( ie source port 1433 and destination port 80). A fundamental mistake in the connection events entries ? Regards Rajesh >From: [EMAIL PROTECTED] >To: "Rob Moore" <[EMAIL PROTECTED]> >CC: [EMAIL PROTECTED] >Subject: RE: Connection event for port 1433 >Date: Thu, 23 May 2002 12:14:37 -0500 > > >TO UNSUBSCRIBE: email "unsubscribe issforum" in the body of your message to >[EMAIL PROTECTED] Contact [EMAIL PROTECTED] for help with any >problems! > ---------------------------------------------------------------------------- > >No no no. Go back to my original post at the bottom here. I said that the >firewall is logging the packet correctly. It is the connection event in >ISS that logs it 'backwards'. I'm trusting the firewall log and not the >ISS event to be correct. > >Kurt C Anderson > > > > > "Rob Moore" > <[EMAIL PROTECTED] To: ><[EMAIL PROTECTED]> > om> cc: > Subject: RE: Connection >event for port 1433 > 05/23/2002 12:06 > PM > > > > > > >Has anyone suggested the possibility of someone spoofing the source, >your perimeter router should be confd to deny your public address as >inbound traffic > >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] >Sent: Wednesday, May 22, 2002 6:19 AM >To: iss >Subject: RE: Connection event for port 1433 > > > >TO UNSUBSCRIBE: email "unsubscribe issforum" in the body of your message >to [EMAIL PROTECTED] Contact [EMAIL PROTECTED] for help with any >problems! >------------------------------------------------------------------------ >---- > >Yes, the sensor is in front of the firewall. I consider this my >'attack' detector. I still need to find out why the event reports our >public IP's as the source? Management is asking for me to clarify the >ISS reports. > >Kurt C. Anderson > > > > "Chong Kah Sing (HLB)" > > <[EMAIL PROTECTED] To: >"'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> > > ong.com.my> cc: > > Subject: RE: >Connection event for port 1433 > > 05/21/2002 09:32 PM > > > > > > > > > >where is the placement of WGM and Checkpoint? My guess is that u placed >your network sensor in front of Checkpoint at the time being. > > > ---------- > > From: [EMAIL PROTECTED][SMTP:[EMAIL PROTECTED]] > > Sent: Wednesday, May 22, 2002 5:00 AM > > To: [EMAIL PROTECTED] > > Subject: Connection event for port 1433 > > > > > > TO UNSUBSCRIBE: email "unsubscribe issforum" in the body of your > > message to [EMAIL PROTECTED] Contact [EMAIL PROTECTED] for help > > with any problems! > > >------------------------------------------------------------------------ >-- > > -- > > > > I've created a connection event to monitor activity on port 1433. The > > > source addr is ANY, the destination addr is ANY, and the destination > > port is 1433. Now, my Checkpoint logs show the destination as our > > public IP addresses, but WGW show the events as just the opposite. > > The source is our public IP addresses. > > > > Why? Is it not sensing the inbound traffic, only the return traffic? > > > I need to explain this to my management. > > > > Kurt C Anderson > > > > > > > > >This email (and any files attached) is confidential and may be subject >to priviledge and is not for circulation or dissemination unless stated >otherwise. If you have received this email in error, please notify the >sender by reply e-mail and immediately delete it from your system. Thank >you. > > > > > > > > > > > >From [EMAIL PROTECTED] Tue May 21 21:34:11 2002 >Return-Path: <[EMAIL PROTECTED]> >Received: from phoenix.iss.net (phoenix.iss.net [209.134.161.8]) > by email.iss.net (8.9.3+Sun/8.9.3) with ESMTP id VAA05134 > for <[EMAIL PROTECTED]>; Tue, 21 May 2002 21:34:11 -0400 (EDT) >Received: by phoenix.iss.net (Postfix) > id 3C2D516021; Tue, 21 May 2002 21:33:31 -0400 (EDT) >Delivered-To: [EMAIL PROTECTED] >Received: from atla-mx1.iss.net (atla-mx1.iss.net [209.134.161.6]) > by phoenix.iss.net (Postfix) with ESMTP id D01AA16034 > for <[EMAIL PROTECTED]>; Tue, 21 May 2002 17:39:16 -0400 >(EDT) >Received: from maileast2.usps.gov (maileast2.usps.gov [56.0.96.22]) > by atla-mx1.iss.net (8.12.2/8.12.2) with ESMTP id g4LLdESv029264 > for <[EMAIL PROTECTED]>; Tue, 21 May 2002 17:39:14 -0400 (EDT) >Received: (from fwtk@localhost) > by maileast2.usps.gov (8.10.1/8.10.1) id g4LLdDh11684 > for <[EMAIL PROTECTED]>; Tue, 21 May 2002 21:39:14 GMT >Received: from samtcavds01.usps.gov( 56.14.0.170) by maileast2 via smap >(V2.1) > id xma011596; Tue, 21 May 02 21:38:55 GMT >Received: by samtcavds01.usps.gov; id VAA02072; Tue, 21 May 2002 21:38:54 >GMT >Received: from unknown(56.88.29.101) by samtcavds01.usps.gov via smap >(V4.0) > id xma001721; Tue, 21 May 02 21:38:08 GMT >Received: by rlghncmx001.usps.gov with Internet Mail Service (5.5.2653.19) > id <KTK7W5Z9>; Tue, 21 May 2002 17:38:07 -0400 >Message-ID: <[EMAIL PROTECTED]> >From: "Maxham, Douglas P - Raleigh,NC" <[EMAIL PROTECTED]> >To: "Owner-Issforum Mail List (E-mail)" <[EMAIL PROTECTED]> >Subject: RE: Filtering Protocols >Date: Tue, 21 May 2002 17:38:07 -0400 >MIME-Version: 1.0 >X-Mailer: Internet Mail Service (5.5.2653.19) >Content-Type: text/plain; > charset="iso-8859-1" >Status: RO >Content-Length: 2736 >Lines: 60 > >You are confusing two types of protocols - communication protocols and >application protocols that are incorporated into network sensor in two very >different ways. See way cool OSI model at //www.lex-con.com/osimodel.htm > >You have demonstrated that you know one way that Network Sensor (NS) deals >with Layer 3 -Network and Layer 4 -Transport protocols (drop down menus). >Network Layer and transport layer protocols you cited were UDP, ICMP, and >TCP. ESP (Encapsulated Security Payload {50}) as described in RFC1827 is a >one of the many protocols that are referred to as "next level protocols" >for >Internet Protocol Version 4 (IPv4). IP is the primary protocol found in >Layer 3 - the Network Layer. The same "next level protocol" info is called >the "Next Header field" in IPv6. Someone more knowledgeable than I will >have >to address creating new policy to filter on IP "Next level protocol" ESP >header info. I would deduce that one would use the canned "Protocol >Analyzer" policy that ships with NS and edit it to do the job. SUGGESTIONS >ANYONE? > >As to the HTTP that's a horse of a different color and a protocol in a >higher stack, I might add. HTTP is considered (mostly) to be in Layer 7 - >the Application Layer. It is an application protocol (as are FTP & Telnet). >Let me point out that the OSI model is a theoretical thing and there is >some >blurring about how much these application protocols dip down into layers 6 >and 5 but that's irrelevant to this discussion. You can create policies >for >HTTP using the canned "Web Watcher" policy that comes with NS. If you want >to check on FT, SMTP (email), and NNTP (NetNews) edit a new policy from the >canned "Session Recorder" policy. > >May you find what your looking for and escape drowning deluge of sensors >spewing spurious session stats! > >V/R, >Doug >____________________________________________ >Doug Maxham, >"Delivering Trust In a Changing World" > > >-----Original Message----- >From: [EMAIL PROTECTED] at INTERNET >Sent: Tuesday, May 21, 2002 1:18 PM >To: Maxham, Douglas P - Raleigh,NC; Viviano, Glenn J - Raleigh, NC; >Lassiter, Kenneth M - Raleigh,NC; Roberson, Kevin C - Raleigh,NC; >Gilmore, Russell W; [EMAIL PROTECTED] at INTERNET >Subject: Filtering Protocols > > >Hi All: > > When trying to filter certain traffic on a Network Sensor (RS6.0), >there are three types of Protocols that show up on the drop down menu, UDP, >ICMP, and TCP. Where are other Protocol choices, like HTTP? Is there a >table somewhere where these can be added, or defined? For example, what if >I wanted to filter Protocol ESP (50), how and where would I do that? >Thanks. > > Latricia > >File item 2 original document name: Not specified >File item 2 document type: UNKNOWN >File item 2 size (bytes): 842 > > > _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx
