Re: Mainframe FTP Failed Logins

[paul stark <starkp () gmail com>]

Just wanted to say thanks to all for the help.  The issue was due to
the fact that the traffic was going in one interface and taking a
different path back to the client.

While probably not the most efficient rule, I ended up using the rule
below which seemed to pick up the failed login that I was attempting
to alert on:

alert tcp $HOME_NET 21 -> $EXTERNAL_NET any (msg:"ET SCAN Potential
Mainframe FTP Brute-Force attempt"; dsize:<100;content:"|35 33 30 20
50 41 53 53|";threshold: type threshold, track by_dst, count 5,
seconds 300; classtype:unsuccessful-user; sid:9008711; rev:1; )

On Wed, May 12, 2010 at 5:14 PM, Seth Art <sethsec () gmail com> wrote:
> If the pcap itself also only shows traffic only in one direction, my
> guess is that one of the following is true:
>
> 1) You using a non aggregating tap (two output ports -- one for
> ingress and one for egress), but only sniffing on one of the
> interfaces?
>
> 2) The traffic is asynchronous and the ingress traffic evilghost
> mentioned is taking a different path back to the client.
>
>
> If 1 -- The solution is simple.  Bond both ports from the TAP together
> and sniff on the bonded traffic.
>
> If 2 -- You need to find and sniff the link that the ingress traffic
> is taking back to the client and aggregate the two feeds together the
> same way as above.
>
> I am pretty sure that currently this traffic will not even be passed
> to the main detection engine, because stream5 will never actually see
> a 3 way handshake.  Someone please correct me if that is inaccurate.
>
> -Seth
>
>
> On Wed, May 12, 2010 at 2:03 PM, evilghost () packetmail net
> <evilghost () packetmail net> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > paul stark wrote:
> > > The issue appears to occur because for some reason snort does not see
> > > the 530 failed login code that is returned. The 220 status codes also
> > > do not appear to be detected.
> >
> > Hi Paul, looking at the dump traffic you provided I only see the egress client communication with the FTPd, I don't 
> > see any ingress from the FTPd itself, hence no 220 banner,
> > status codes, etc.  Does /root/debug.pcap contain bi-directional traffic?
> >
> > That ET sig with the PCRE, we may be able to write a better (performance/detection) rule for your environment if 
> > you're targeting a specific FTPd product/version...
> >
> > - -evilghost
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.9 (GNU/Linux)
> >
> > iQIcBAEBAgAGBQJL6u2MAAoJENgimYXu6xOHnpUP/3gZ7LA/5plp+DUkI9hrL8V6
> > d4uTVuGhk7PfyIe8497oiyQnMLIRSm+kQD8k3Tar2nWTfRwif9glRauxraZMJRS0
> > /V8A7jRgz1xpUOKH2b+TnlIwwDbi4sY0WZbxJzDwVJF92aPwIw8KRH8DY+2VhwaD
> > DSIsJETGlFbHLTHZreoekgg+ds2JPrUvYzM70BJqknnwkgVPtty5bMIhMOl8SjVd
> > TGhqXrx5zPnhrss7j18EHa0QrDGy/dEuYkXjc+VTvIuk/bp5fJamPCYRJN59XbLa
> > dI2uAWZ9ubtL6VUh1L0S/45C8GXZiugiyuiLjUn4RW2p88oviHrEmHKc3WV574dJ
> > xI2ajTv2CSqcn78AtM1Go8EIrzpygcy2J2sJNeGQHh0ZeX/M1GspNa+AIl1STr6q
> > yhQMTJvowwYb5aPif/zE1byV+YSfnOLw1IVHo7kRM0H0uwFD+4rmJq7CntLrosPL
> > wIzsfh/tf+oXHdZmBGcDs8dbJN3Rn7ldnaNlM2cYu7V4MvB47QYUbBJgyM6gwfKi
> > hddSsQnTMP6EGJh70sDOPBh6Nv9NTjcJT3K3hLT1fo+7RdNIJsyuqwg7UcYecmmy
> > A2w+FcBFWY5AeQ6D/kqJqjhzHeE0DLq6UqQ/1K/yMyh3SRrV+xjL4ZMl9abDZtUC
> > drjelLmw0+O2Gd+RMAgz
> > =PH3c
> > -----END PGP SIGNATURE-----
> >
> > ------------------------------------------------------------------------------
> >
> > _______________________________________________
> > Snort-sigs mailing list
> > Snort-sigs () lists sourceforge net
> > https://lists.sourceforge.net/lists/listinfo/snort-sigs

------------------------------------------------------------------------------

_______________________________________________
Snort-sigs mailing list
Snort-sigs () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-sigs