ftp
variablesThe standard script defines the following redefinable variables:
ftp_guest_ids : set[string]
Default: { "anonymous", "ftp", "guest", }
.
ftp_skip_hot : set[addr, addr, string]
Default: empty.
Example: redefining ftp_skip_hot
using
redef ftp_skip_hot: set[addr, addr, string] += { [[bob1.dsl.home.net, bob2.dsl.home.net], bob.work.com, "root"], };
would result in Bro not alerting on FTP connections as user "root"
from either bob1.dsl.home.net
or bob2.dsl.home.net
to the
server running on bob.work.com
.
ftp_hot_files : pattern
Default: aggdrop
a pattern that matches various flavors of password files, plus
any string with eggdrop
in it. Note: Eggdrop is an IRC management
tool often installed by certain attackers upon a successful break-in.
ftp_not_actually_hot_files : pattern
ftp_hot_files
. It turns out
that a pattern like /passwd/
generates a lot of false hits,
such as from passwd.c
(source for the passwd utility;
this can turn up in FTP sessions that fetch entire sets of utility sources
using MGET
) or passwd.html
(a Web page explaining how to enter
a password for accessing a particular page).
Default: /(passwd|shadow).*.(c|gif|htm|pl|rpm|tar|zip)/
.
ftp_hot_guest_files pattern
skip_unexpected : set[addr]
PORT
or PASV
directive, then if either the original host
or the new host is in this set, no message is
generated. The idea is that you can specify multi-homed hosts that
frequently show up in your FTP traffic, as these can generate innocuous
warnings about connections from unexpected hosts.
Default: some hp.com
hosts, as an example. Most are specified
as raw IP addresses rather than hostnames, since the hostnames
don't always consistently resolve.
skip_unexpected_net : set[addr]
skip_unexpected
, except addresses are masked to /24 and
/16 before looked up in this set.
Default: empty.
In addition, ftp_log
holds the name of the FTP log file to
which Bro writes FTP session summaries. It defaults to
open_log_file("ftp")
.
Here is an example of what entries in this file look like:
972499885.784104 #26 131.243.70.68/1899 > 64.55.26.206/ftp start 972499886.685046 #26 response (220 tuvok.ooc.com FTP server (Version wu-2.6.0(1) Fri Jun 23 09:17:44 EDT 2000) ready.) 972499886.686025 #26 USER anonymous/IEUser@ (logged in) 972499887.850621 #26 TYPE I (ok) 972499888.421741 #26 PASV (227 64.55.26.206/2427) 972499889.493020 #26 SIZE /pub/OB/4.0/JOB-4.0.3.zip (213 1675597) 972499890.135706 #26 *RETR /pub/OB/4.0/JOB-4.0.3.zip, ABOR (complete) 972500055.491045 #26 response (225 ABOR command successful.)
Here we see a transcript of
the 26th FTP session seen since Bro started running. The first line
gives its start time and the participating hosts and ports. The
next line (split across two lines above for clarity) gives the server's
welcome banner. The client then logged in as user “anonymous
”,
and because this is one of the guest usernames, Bro recorded their
password too, which in this case was “IEUser@
” (a useless
string supplied by their Web browser). The server accepted this
authentication, so the status on the line is “(logged in)
”.
The client then issues a request for the Image file type, to which the
server agreed. Next they issued a PASV
directive, and received a
response instructing them to connect to the server on port 2427/tcp
for the next transfer. At this point, after issuing a SIZE
directive
(to which the server returned 1,675,597 bytes), they send RETR
to
fetch the file /pub/OB/4.0/JOB-4.0.3.zip. However, before the
transfer completed, they issued ABOR
, but the transfer finished
before the server processed the abort, so the log shows a status of completed
. Furthermore, because the client issued two commands without
waiting for an intervening response, these are shown together in the log
file, and the line marked with a “*
” so it draws the eye. Finally,
because Bro paired up the (completed)
with the multi-request line, it
then treats the response to the ABOR
command as a reply by itself,
showing in the last line that the server reported it successfully carried
out the abort.
The corresponding lines in the red file look like:
972499885.784104 565.836 ftp 118 427 131.243.70.68 64.55.26.206 RSTO L #26 anonymous/IEUser@ 972499888.984116 165.098 ftp-data ? 1675597 131.243.70.68 64.55.26.206 RSTO L
The first line summarizes the FTP control session (over which the client
sends its requests and receives the server's responses). It includes
an addl
annotation of “#26 anonymous/IEUser@
”,
summarizing the session number (so you can find the corresponding records
in the ftp
log file) and the authentication information.
The second line summarizes the single FTP data transfer, of 1,675,597 bytes.
The amount of data sent by the client for this connection is shown as
unknown because the client aborted the connection with a RST (hence
the state RSTO
). For connections that Bro does not look inside
(such as FTP data transfers), it learns the amount of data transferred from
the sequence numbers of the SYN and FIN connection control packets, and
can't (reliably) learn them for the sender of a RST. (It can for the
receiver of the RST.)
They also aborted the control session (again, state RSTO
), but
in this case, Bro captured all of the packets of the session, so it
could still assign sizes to both directions.