[Snort-sigs] Mainframe FTP Failed Logins
starkp at ...2420...
Thu May 13 08:13:25 EDT 2010
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 at ...2420...> 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
> 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