This week i’ve understood that an out of the box deployment is never what you want. Especially for an NSM solution. Tunning Snort accordingly to your needs is the key to a succesfull deployment and to stopping attackers.
I’ve managed to place a SmoothSec running machine in a class, attached to a switch that will mirror all the traffic to it. The reason for this is to see how is it managing with traffic coming from more than 1-2 PCs and what kind of alerts does it generate. It is also a good testing ground for new rules. The following network diagram shows the system and how can i connect to the monitoring server.
- the schools wired network is splitted into several VLAN and subnets
- my PC can access the pfsense router directly, passing through the VLANs
- the monitoring server is connected to the mirror port on the pfsense inside-LAN (192.168.1.0/24), alongside the other student PCs
- my PC can access the monitoring server through the pfsense router (using portforwarding i can acess the web interface on the routers IP and i can establish a SSH connection – 10.165.0.129:22443 and 10.165.0.129:22022). This way i can check on the server without pshysically being there.
So far, not that many interesting alerts, only those that show some port scanning and failed ssh logins (that’s me). What i’ve found interesting is some weird alert that popped-up way too many times (15262 times to be exact).
Like i was saying at the beggining of the log, tunning your deployment is clearly needed in any situation – especially if you want to avoid that many logs for a false-positve.
This is part of a series of blogposts that serve as my weekly log for my professional special subject project. It has documentation purposes and it is a nice way to present your work to the teachers. For further information about my work and what i’ve learned and did follow the inbound/outbound links within these posts.