-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Well, it sounds like you have the hard work done. Convincing your network team that they're sound.
Now if you can deploy enough of them to capture all the traffic you want, you'll be in good shape. I don't know about your network or the traffic you're looking to monitor but typically, VLANs span multiple switches. If you want to see the entire conversation using taps you'll need to be physically connected at a point within the network that allows you to see all the communications. If your not sitting on a span port, you will not see communications between two hosts that are on the same physical switch. Now you need to make certain your hosts IDS is fully deployed.
As I said, I don't know your environment, but the above has been my experience.
Ken.
Thierry B�le wrote:
| 1)Taps are not single point of failure and does no impact traffic | flow, indeed, they are by design fault-tolerant (the IDS Taps have | proprietary circuitry pre-process that closes the circuit when | power fails, maintaining the network link), so there is no problem | with my networking team and they prefer taps instead of span ports | on their switches (overload of the span port and of the switch) ... | | | 2) Mosts of taps are bi-directional traffic, the IDS taps allow the | IDS to transparently inject TCP reset into the stream. | | | IMHO, taps are the relevant components to provide you transparency | for your network ans scalability for your IDS architecture (and not | only a cost concern) | | regards | | Thierry | | | | Ken Kempster wrote: |
| IMO the big problem with any device that sits in line of the | traffic is there is always the concern of it being a single point | of failure. Selling to your networking team that the device will | not become a bottle neck or failure point is difficult at best. | Also, if you're looking to do RS kills, you will need another | physical path to send them when using taps. When you're comparing | the pros and cons of deploying them, you need to factor in the | criticality of the network you will be tapping into. | | If cost is a concern, then taps are probably a good approach but I | would confirm that the physical infrastructure is designed so that | a physical failure of the tap does not affect traffic flow; | multi-path. | | It has been my experience that the best approach is to design your | security infrastructure so that if there were a total failure of | your monitoring environment, it will not impact production | networking/traffic flow. This is typically the more expensive | approach but the safest one. | | Ken. | | | Thierry B�le wrote: | | | Hi Ken, | | I guess you speak about the IDS Balancer because | Toplayer don't | have taps supporting traffic aggregation ( maybe | they will ...) but | I'm not interested in load-balancing traffic | between multiple | sensor. | | The goal with taps supporting | traffic aggregation is to simplify | IDS architecture and to save | cost: | | With normal taps, you need to use Network Sensor with | integrated | full-duplex segment monitoring or to use layer 7 | switches (IDS | balancer for example) to aggregage traffic for your | Network Sensor. | Now, you can connect your Network Sensor | directly to the port | aggregator tap. | | I would be interested to | have your feedback on using such devices | and especially if they | really deconflict collisions as it can be | described in the | datasheets (taps are normally passive devices) | | Thierry | | | | | Ken Kempster wrote: | | | | Have you looked at TopLayer? I've tested the product a few years | | ago and it looked good for aggregating ports/traffic, load | balance | between multiple sensors and still retain an aggregated | port for | your sniffer. | | Ken. | | Thierry B�le wrote: | | | | Hello, | | Has anyone tested taps supporting traffic aggregation | | with ISS | products (with the capability to mirror the traffic only | | on one | link) ? | | I'm aware of the bandwidth limitations we | can | have: if the 2 | network ports are operating at 100mbps and | the IDS | port is | operating at 100mbps as well, then under | sustained | aggregate | bandwidth of greater than 100mbps, packets | will get | dropped. | | I guess it should cause no problems with | dropped | packets if I'm | monitoring internet links with low | utilisation. | | | Any feedback appreciated. | | Thierry | | | | _______________________________________________ ISSForum mailing | | | list [EMAIL PROTECTED] | | TO UNSUBSCRIBE OR CHANGE YOUR | | SUBSCRIPTION, go to | https://atla-mm1.iss.net/mailman/listinfo | | |> |> | |> |>
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFAFpjan19jIc8Mw3IRAnvyAKCgQuQzNmruRfGhcCMOFN/ZrddZMgCgrFm1 tCG/Hok3ODslKlpcU5lzd/o= =DpX4 -----END PGP SIGNATURE-----
_______________________________________________ ISSForum mailing list [EMAIL PROTECTED]
TO UNSUBSCRIBE OR CHANGE YOUR SUBSCRIPTION, go to https://atla-mm1.iss.net/mailman/listinfo
