RE: LOGS: GIAC GCIA Version 3.4 Practical Detect IanEaton

        These answers are excellent.  Remember that you are supposed to
include
        comments from the list, and responses.  I had the general thought
that you
        had an excellent discussion of the attack - but the point is for you
to
        show the "how's" of how you got said info.. Your material is really
first rate;.

        I caution you on page length - if all of your detects are 10+ pages,
and you have
        a 15 page IDS paper / white paper, you don't leave enough room for
Part 3 - the
        real cow and spuds of the practical.....  Also - consider time
management.  How
        much time are you spending on this detect? how much on others? where
are you in
        the five month period?  DON"T let part 3 sneak up on you ... you
should ba 
        analyzing data 60 days out from your submission ....

        Best of luck - you are definitely heading into honors territory with
your
        analysis and response.  

        - djm - 

> -----Original Message-----
> From: intrusions-bounces@xxxxxxxxxxxxxx 
> [mailto:intrusions-bounces@xxxxxxxxxxxxxx] On Behalf Of Ian Eaton
> Sent: Sunday, May 23, 2004 1:05 PM
> To: Intrusions List (GCIA Practicals)
> Subject: RE: [Intrusions] LOGS: GIAC GCIA Version 3.4 
> Practical Detect IanEaton
> 
> 
> Don,
> 
> I really do appreciate your time and effort used to review my detect.
> 
> Half your comments seem related to the lack of supporting 
> information embedded in the detect, I agree the paper does 
> need more of this.  In my attempt to keep the detect length 
> to a minimum (in MS Word it is already 14 pages) I think I 
> missed some important and easily inserted information that 
> would make this detect more complete and standalone.  I will 
> expand as suggested for the final paper.
> 
> Some further responses to your specific questions are next
> 
> Regards, Ian
> 
> 
> 
> In these files almost all the 
> > > packet streams are in their entirety, for example the full
> > > TCP three way hand shake to its close is intact.
> > 
> >     don - "hand shake to its close is intact" - doesn't make
> >     to much sense?
> > 
> 
> This sentence should have been more like
> 
> "In these files almost all the packet streams are in their 
> entirety, for example TCP connections from  the initiating 
> three way hand shake through to the connection close (i.e. 
> the whole communication data
> stream) is intact "
> 
> 
> > There is the remote chance that the attacker is sniffing the
> > > packets crossing the wire and spoofing every response packet,
> > > though this is not even remotely likely and would be and ..
> > > extremely advanced technique.  The attacker does not make an 
> > > effort to hide the attack as it is easily detectable, it 
> > > would be a waste of effort to do this and then make the 
> > > attack obvious.
> > 
> >     don - hmmm.... do you mean sniffing locally on the
> >     wire or doing a man in the middle kind of thing?
> >     
> 
> In this case I was referring to the possibility that an 
> attacker could be sniffing the network traffic with a sniffer 
> anywhere on the path between the two communicating hosts, 
> listening to the traffic as it passes performing a non blind 
> form of the Mitnik attack.  I figure as long as the address 
> used to perform the attack is either not assigned to a real 
> host or the real host is silenced (i.e. by a DoS) the 
> attacker could maintain a full TCP communication with the 
> target as long as they can see every return packet.
> 
> 
> > server respn =>             220 lazy FTP server (Version w
> > > attack reqst =>           USER anonymous
> > > server respn =>           331 Guest login ok, send your 
> > > attack reqst =>           PASS nessus@xxxxxxxxxx
> > > server respn =>           230 Guest login ok, access res
> > > server respn =>           221 You could at least say goo
> > 
> >     don - ok, so you draw the conclustion that its nessus,
> >     but what did you look at in the nessus app to correlate..
> >     is there a particular assessment that matches the "goo"?
> >     in other words, does the nessus scanner have a ftp test
> >     that uses this email addr?
> > 
> 
> Performing a quick grep (grep -rin "nessus@xxxxxxxxxx" *) on 
> the nessus plugins for the login string "nessus@xxxxxxxxxx" 
> allows me to add this to the detect.
> 
> Nessus is a fully featured open source Vulnerability 
> Assessment tool that provides an ever increasing set of tests 
> to asses the security posture of a target host from over the 
> network.  Nessus uses plugins to supply information for each 
> of these tests.  One of the plugins "logins.nasl" does not do 
> any security checks by itself but does provide default login 
> configuration information for other plugins to use.  
> 
> Plugin information http://cgi.nessus.org/plugins/dump.php3?id=10870
> 
> The source for this plugin has these settings by default 
> http://cvsweb.nessus.org/cgi-bin/cvsweb.cgi/~checkout~/nessus-
> plugins/scripts/logins.nasl?content-type=text/plain
> 
> default_ftp_login = "anonymous";
> default_ftp_password = "nessus@xxxxxxxxxx";
> default_ftp_w_dir = "/incoming";
> 
> 
> > I suspect this environment has been setup to allow people to
> > > test their attack techniques so system countermeasures are
> > > not implemented to make the environment a little easier to attack.
> > 
> >     don - at this point I don't recall all of the text above,
> >     but didn't you show that they were thwarted at some points?
> 
> I don't think I show the attacks are thwarted but more the 
> attacks did not always complete successfully, I am not an 
> expert in performing these types of attacks on hosts but I 
> suspect due to the nature of buffer overflow attacks and the 
> like they would not always work as expected 100% of the time.
> 
> 
> > How many packets does nmap send to a host when trying to
> > > identify the OS type given the -O command line option:
> > > a.        6
> > > b.        7
> > > c.        8
> > > d.        9
> > > 
> > > Answer: c   (T1 - T7 which are TCP tests, and a UDP test)
> > 
> >     don - you need to explain your answer.  that is
> >     necessary, and I imagine a required point for the
> >     practical...
> 
> Nmap sends 8 specially crafted packets to a target host when 
> trying to determine the OS type.  There are 7 TCP based 
> packets that contain varying combinations of TCP flags and 
> options set, in the hope of eliciting a specific response 
> that can be used to identify the target. 
> The eighth packet is of type UDP.
> 
> 
> Thanks again for you time.
> 
> 
> 
> 
> 
> 
> On Sun, 2004-05-23 at 03:52, Don Murdoch wrote:
> >     Comments inline below.
> >     Don M, GCIA Local mentor
> > 
> > > -----Original Message-----
> > > From: intrusions-bounces@xxxxxxxxxxxxxx
> > > [mailto:intrusions-bounces@xxxxxxxxxxxxxx] On Behalf Of 
> Ian Eatonfor example the full 
> > > TCP three way hand shake to its close is intact.
> > 
> >     don - "hand shake to its close is intact" - doesn't make
> >     to much sense?
> > > Sent: Saturday, May 22, 2004 8:47 AM
> > > To: intrusions@xxxxxxxxxxxxx
> > > Subject: [Intrusions] LOGS: GIAC GCIA Version 3.4 Practical
> > > Detect Ian Eaton
> > > 
> > > 
> 
> 
> _______________________________________________
> Intrusions mailing list
> Intrusions@xxxxxxxxxxxxxx 
> http://www.dshield.org/mailman/listinfo/intrusions
> 

_______________________________________________
Intrusions mailing list
Intrusions@xxxxxxxxxxxxxx
http://www.dshield.org/mailman/listinfo/intrusions