[Snort-sigs] Mainframe FTP Failed Logins
sethsec at ...2420...
Wed May 12 17:14:29 EDT 2010
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
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.
On Wed, May 12, 2010 at 2:03 PM, evilghost at ...3397...
<evilghost at ...3397...> 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)
> -----END PGP SIGNATURE-----
> Snort-sigs mailing list
> Snort-sigs at lists.sourceforge.net
More information about the Snort-sigs