# Is there a quickstart method? **URL:** \ **Category:** Zeek\ **Created:** [November 28, 2006, 4:42pm UTC](https://community.zeek.org/t/is-there-a-quickstart-method/1062 "2006-11-28T16:42:33Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![David\_Caldwell](https://avatars.discourse-cdn.com/v4/letter/d/57b2e6/32.png) [@David\_Caldwell](https://community.zeek.org/u/David_Caldwell)\ **Post date:** [November 28, 2006, 4:42pm UTC](https://community.zeek.org/t/is-there-a-quickstart-method/1062/1 "2006-11-28T16:42:33Z")
I am seeking a quickstart method to perform the following. The intended purpose of the Bro install I am working on is to monitor incoming traffic only. To break it down simply I want to track only those incoming events that would appear to be malicious (ssh, telnet, etc). We are trying to upgrade our security situation here, and in order to get our customer to go along with it we have to show good reason why we need it. Using Bro to capture malicious attempted traffic will help us clarify the need for stiffer security measures than we currently implement. I am reading the manuals, and looking for the info I need to do just that. In the case of you, if I can get some pointers to where to look to do just what I have intended it would speed up the process for what I have in mind. We don't however wish to police our own outgoing and responding traffic. I know this is possible with Bro, and am trying to get this system up and running asap. Can anyone provide pointers in the manuals, or other locations for such a setup? ---
**Author:** ![robin](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/robin/32/599_2.png) [@robin](https://community.zeek.org/u/robin)\ **Post date:** [November 29, 2006, 3:35am UTC](https://community.zeek.org/t/is-there-a-quickstart-method/1062/2 "2006-11-29T03:35:34Z")
In general, it's not really possible to restrict Bro's \*analysis\* to only incoming traffic. The main reason here is that from Bro's policy-neutral perspective it's hard to tell what "incoming" actually means. Three ideas, depending on what exactly you want to achieve (which is not completely clear to me): First, you can filter the \*alerts\* so that only activity regarding local hosts is reported. That's possible by writing a corresponding notice-policy (see notice-policy.bro, or ask me again if you need more details). Second, if you're interested in a log of all incoming connections (or incoming connections to certain ports like ssh etc.), conn.log marks locally initiated connections with an "L" and remotely initiated ones with an "X" (once you've configured your local networks in site.bro). This is easily grep'able (or you can hack conn.bro to not even output the local connections[1]). Third, firewall.bro allows you to define "firewall-like" rules (e.g., "no external hosts are allowed to connect to any local telnet port") and raises alerts if one is violated. It's not well documented (um, not at all?), so again please ask for details if you're interested in this functionality. Does this help? Robin [1] In general you could hack any script to suppress its output for local connections but by default they don't provide this functionality. ---
**Author:** ![Christian\_Kreibich3](https://avatars.discourse-cdn.com/v4/letter/c/4af34b/32.png) [@Christian\_Kreibich3](https://community.zeek.org/u/Christian_Kreibich3)\ **Post date:** [November 29, 2006, 7:12am UTC](https://community.zeek.org/t/is-there-a-quickstart-method/1062/3 "2006-11-29T07:12:56Z")
David, just two quick additions to what Robin said: - Our marketing department just might fire me for saying this, but if you just want to show people how bad things are then you might not need anything as sophisticated as Bro. For example, compare the number of valid connection requests in your sshd log to invalid ones -- my little DSL-connected box at home got hit around 400 times per day with malicious log-in attempts before I moved sshd to a different port. Looking at Apache logs might give you a similar picture. - Speaking of different ports, a scenario in which Bro definitely \*could\* shine is detecting app-layer protocols on unusual ports, thanks to the new DPD framework:   [http://www.bro-ids.org/wiki/index.php/DynamicProtocolDetection](http://www.bro-ids.org/wiki/index.php/DynamicProtocolDetection) As an example, you could use the IRC detector to find IRC-based botnets on arbitrary ports that way. Cheers, Christian. ---
**Author:** ![David\_Caldwell](https://avatars.discourse-cdn.com/v4/letter/d/57b2e6/32.png) [@David\_Caldwell](https://community.zeek.org/u/David_Caldwell)\ **Post date:** [November 29, 2006, 8:10pm UTC](https://community.zeek.org/t/is-there-a-quickstart-method/1062/4 "2006-11-29T20:10:03Z")
Running FreeBSD, while being a good idea from all sides considering that was what it was developed on, puts me in a position where I have to relearn a whole operating system and be abel to function half way responsibly right this minute. I don't have that option.....yet. Bro actually won't be parsing data the way we are setting it up. I am mirroring the ports between the switch outside the firewall (input to the switch), and the interface of the bro machine. Now the bro machine is going to be sitting completely outside the firewall, with no internal connections at all. the admin interface (eth2) will also be outside the firewall. I will have to ssh to it from wherever. If I am thinking correctly it really does not matter what ip address I assign to the bro listening interface because in promiscuous mode the interface will not really have an ip address anyway.....it just listens on this interface (please correct me if I am wrong). the second interface I can set up a quick iptables ruleset to deny all and allow only internal (to the box) requests. So while I am not too terribly concerned about this box being used to circumvent my security inside the firewall, I am concerned about the box being taken over. Any of you have a suggestion as to how to keep this from happening, or is my logic sound on my thinking here? David ---
**Author:** ![Seth\_Hall4](https://avatars.discourse-cdn.com/v4/letter/s/dfb087/32.png) [@Seth\_Hall4](https://community.zeek.org/u/Seth_Hall4)\ **Post date:** [November 29, 2006, 9:04pm UTC](https://community.zeek.org/t/is-there-a-quickstart-method/1062/5 "2006-11-29T21:04:27Z")
You have to keep in mind that since bro will be parsing packets that are passing over your network and if someone crafts a packet that crashes one of the protocol analyzers, there is potential for compromise. Wireshark (ethereal) has run into this issue many times recently and they have always strongly advised upgrading because people will tend to run it as root, especially on linux. And if someone compromises your IDS as the root user, it makes the attackers job of hiding their activity much easier. Open source software isn't the only software affected by this problem either, ISS's IDS had this problem recently too, and many of their customers were compromised by malicious packets. Here's the CERT advisory about it.. [https://www.kb.cert.org/vuls/id/150326](https://www.kb.cert.org/vuls/id/150326) Fortunately, Bro is heading down the path of becoming less vulnerable to these attacks with binpac ([http://bro-ids.org/wiki/index.php/BinPAC](http://bro-ids.org/wiki/index.php/BinPAC)). I would advise following Robin's advice and running bro as a user other than root. That offers a little protection, but keep in mind that closely monitoring the server is suggested so that if you are compromised you may be able to detect it and recover quickly. later,    .Seth ---
**Author:** ![Jean-Philippe\_Luigg2](https://avatars.discourse-cdn.com/v4/letter/j/aeb1de/32.png) [@Jean-Philippe\_Luigg2](https://community.zeek.org/u/Jean-Philippe_Luigg2)\ **Post date:** [November 30, 2006, 12:27am UTC](https://community.zeek.org/t/is-there-a-quickstart-method/1062/6 "2006-11-30T00:27:07Z")
Hello, > \> be outside the firewall. I will have to ssh to it from wherever. If I > am thinking correctly it really does not matter what ip address I > assign to the bro listening interface because in promiscuous mode the > interface will not really have an ip address anyway.....it just   There is no relation between the fact to have or not an IP address and the   fact to run in promiscuous mode.   You can listen (promiscuous or not) the traffic on an interface, with an   IP ou without one.    > listens on this interface (please correct me if I am wrong). the > second interface I can set up a quick iptables ruleset to deny all > and allow only internal (to the box) requests. >    >   Yes, it's a possible workaround. > So while I am not too terribly concerned about this box being used to > circumvent my security inside the firewall, I am concerned about the > box being taken over. Any of you have a suggestion as to how to keep > this from happening, or is my logic sound on my thinking here?   As i said before Bro does'nt run as network service.   And the some ideas :   - use firewall (iptables) to block offending traffic.   - use ssh on a different port than 22.   - use complex password, disable direct root login (example of conf   following): ---
**Author:** ![system](https://canada1.discourse-cdn.com/flex011/uploads/zeek/original/1X/f09d732bc2cc7c7cc7e35db67cf4e1d5233ce7a7.png) [@system](https://community.zeek.org/u/system)\ **Post date:** [May 6, 2022, 3:38pm UTC](https://community.zeek.org/t/is-there-a-quickstart-method/1062/7 "2022-05-06T15:38:03Z")