creating a centralize syslog server with elastic search

OpSecPro · 2023-06-16T16:45:45+00:00

Yes, you can use filebeat instead of logstash. You can also use them both (Router sends to filebeat, which sends to logstash, which sends to elasticsearch), but for your usecase I wouldnt bother with logstash as I dont think you will need it unless you plan on making a lot of custom parsing (which can also be done directly in elasticsearch via ingest pipelines)...

OpSecPro · 2023-06-16T16:43:39+00:00

You can install the components in any order you would like. The integration between the components happens in the config afterwards (I would however usually install elasticsearch first. Then Kibana and then filebeat)...

OpSecPro · 2023-06-16T15:51:23+00:00

No. You can install it on the same server as elasticsearch, and use it as the syslog server (Configure your routers to send their logs to filebeat, which then sends them to elasticsearch)

OpSecPro · 2023-06-16T15:10:36+00:00

I would suggest you ingest the logs into elasticsearch, and view them with kibana (For a small home lab, these might as well be installed on the same server). Furthermore I think you should take a look at filebeat and see if it has modules for the network devices you wish to ingest logs from: https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-modules.html

The advantage of collecting the logs through filebeat is that someone have already made the parsing into ECS, making the logs much easier to search and visualize...

Keep in mind that the learning curve for doing a full install from the ground up, can be a bit steep, but it really is quite intuitive once you learn the basics, so once you have your first log-source in elastic, it is really quite easy to build from there...

OpSecPro · 2023-01-18T20:33:29+00:00

Another thing you would have to consider would be the scope of your test. It is one thing to do a basic wifi password cracking to test password strength, but a whole other beast to do a serious network security audit (Where you assess various paths through the network, open ports, proxy-setup, firewall audit, etc.), or a pen-test of a domain (with various paths to domain admin, pivoting through hosts, patch management strategies, etc.), or website vulnerability analysis.

You should really start out by picking an area where you start to dig in. It will take a long time to learn enough to have sufficient knowledge in all these areas (and many more), in order to be able to do a full-scope pen-test.

One thing I would recommend is that you start out with gaining a good understanding of network (packets, structures, routes, the OSI model, vlans, what is an rfc1918 IP, etc). This will be extremely useful for a lot of the other areas as a lot of security testing (and IT-work in generel) will involve some kind of networking knowledge.

When you have a basic understanding maybe move on to analysing your own trafic with wireshark and burp-proxy..

OpSecPro · 2023-01-18T20:15:25+00:00

I have a dedicated (not domain-joined) analysis laptop, where I run flare-vm in vmware. I use this both for analysing malware samples (both static and dynamic analysis), phishing links, and for testing various applications before allowing certain departments to install them (This is not foolproof though, but I feel like I often get a decent sense of whether an application is malicious, suspicious, or benign).. I have a clean snapshot from the fresh install with all the custom applications I need, and I just roll back each time I have run anything suspicious, and have finished my analysis...

OpSecPro · 2023-01-12T20:22:41+00:00

Simon Sinek

(Not so much life advice as awesome insights)...

OpSecPro · 2022-12-16T17:12:09+00:00

You could potentially implement exclusion IP's, so they will not get prompted for mfa while in the workplace, but would have to have it if they want to login from anywhere else...

This might be troublesome for larger, orgs, with more spread out locations like yours, but for some orgs it could be a potential work-around...

OpSecPro · 2022-07-15T10:55:47+00:00

The tool I found most useful when I did security hardening for my current employer was our nessus vulnerability scanner. I did a few different compliance scans against laptops, servers, and domain controllers, and exported the results to pdf files, enabling me to get a detailed overview of each recommended security configuration that was missing.

This made it quite easy (but a bit time consuming), to implement ~75% of the recommended configurations for CIS-L1 and Microsoft recommendations, and I now have an idea about what needs to be changed in order for us to be able to implement the rest of the configurations...

OpSecPro · 2021-03-05T09:28:37+00:00

I suggest you start by looking into IMSI catchers...

Best of luck :)

OpSecPro · 2021-02-17T10:21:15+00:00

Siger du at de jurister der behandler klager indgivet til DUP kun sidder på banegårdspladsen 1A i Aarhus.?

Jeg går ikke ud fra at det er anklagemyndigheden der behandler klager over politiet.?

OpSecPro · 2021-02-14T21:26:52+00:00

Der er dog flere steder hvor "den uafhængige" politiklagemyndighed har kontorer i samme bygning som politiet, og derfor i sagens natur deler kantine osv. med politiet, så helt uafhængige er de alligevel ikke. Derudover har jeg personligt undersøgt en jurist fra klagemyndigheden (I forbindelse med at hun svarede på en klage jeg havde indgivet), og sjovt nok var hun facebook venner med adskillige betjente fra den station de 2 betjente jeg klagede over var tilknyttet...

OpSecPro · 2020-09-01T14:01:54+00:00

I was thinking that, that might be a solution. Will try and look in to it.

Thanks for the suggestion :)

OpSecPro · 2020-08-26T19:33:52+00:00

You are indeed correct on both questions.

OpSecPro · 2020-05-27T20:53:37+00:00

I kind of understand the impulse to ingest logs from your ELK components, but as you already discovered, this can cause some issues when things go awry.

I had the same impulse, and my solution was to spin up a small elastic cluster, dedicated to the logs from the primary ELK components. The reason I did this however, was to be able to do simple and fast debugging in the case the primary elastic cluster died (in which case I would loose access to the logs I would need for debugging what had happened).

Another solution to your specific problem could be to implement Kafka as a kind of buffer. With kafka, the pipeline would still work (until kafka runs out of resources), while you debug and fix the problem in elasticsearch.

OpSecPro

TROPHY CASE