I do not want to give up the title. After all, he performs his task - attracts attention. I sincerely ask you not to be angry if the content of the article did not meet your expectations. The time is now. “Such materials,” they said, “need to be posted on forums for amateurs, and at Habré only the highly intelligent IT public talks about what you never understand and you don’t need to understand.” However, Glory to Habra! He is quite democratic.
Something caught me in the topic of network security in terms of analyzing network traffic and detecting unauthorized network activity (hereinafter referred to as NSA).
Aspects of the NSA that interest me:
- unauthorized scanning of resources (ports, web-targets) of the protected network (hereinafter referred to as ES) from an open network (hereinafter referred to as OS);
- - unauthorized traffic from / to ES. This is an independent network application activity;
- unauthorized insertion of unwanted content (hereinafter - NC). This is advertising, content of dubious content.
- known types of network attacks (hereinafter - SA).
What I do not care: everything that does not concern the network. These include anti-virus protection directly of workstations and servers, email spam, password cracking, etc. etc.
Why did I decide to reinvent the wheel? After all, there is a lot of hardware and software that seems to perform the same functions and does not seem to be bad. But the question is: we spend huge sums of money on hyperconvergent superferwals of the next generation, but there’s no point. An update came and flooded all the PCs. Users sit with admin rights, poke into ads in browsers and catch coders. “Oh, we are closed today for technical reasons,” the business owner has to say. Admins release a fresh server on the Network to update with all open ports, it immediately and "update as it should." And then the network starts to slow down, the domain gets into spammers and other delights of IT life. Well, Business somehow tries to pay admins to move. They move, but not for long - get used to it. Everyone knows that IT incidents always happen suddenly like winter for public utilities. As for the public sector, then as usual - "fools and roads." On the one hand, the huge costs of “network modernization”, the purchase of expensive equipment, which can cause nothing but justified suspicions of budget cuts. On the other hand, low remuneration of IT specialists, which leads to staff turnover and the general low professional level of administrators. As a result, we have expensive equipment and a student who does not know how, does not know, and does not want to know what to do with it. That is the problem of security is not in the gland. The human factor is what determines the overall security of systems.
What is it for me? In addition, it is probably interesting for every business owner to have an “admin” performing his duties equally well 24/7 practically “for food”.
That's exactly the kind of “iron admin” that I want to implement.
I decided to start with network security. To limit or eliminate external influence on the AP is already 50% of the case.
So, the general concept:
The main initial (ideal?) Conditions:
- Low cost. The hardware, in the basic version, should be affordable for all categories, from an individual user with one PC and higher.
- The piece of iron should not require the constant attention of qualified personnel to perform its duties. Put and forget.
- The piece of iron should be easily replaced without requiring additional configuration.
- The piece of iron must be interactive - report to a predetermined circle of people about current or perceived threats, their condition, and make decisions independently based on an analysis of the situation. That is, not the admin should constantly look into the log, and Zhelezka should report that something went wrong and what he did to fix this “wrong”.
- The interaction interface with Zhelezka should be simple and clear even for the novice IT specialist. No consoles or regular expressions. Leave the sky to the birds.
This is what concerns the Strategic Goals. Now back to earth. Let Zhelezka will consist of Collectors collecting information, and the Center for Analysis and Decision Making (hereinafter referred to as CAPR). There are some analogies with the "Smart Home", IoT. Let it be a "smart octopus" (fu, disgusting). But, why not? It seems after all - Collectors are tentacles, and the brain is a CAPR
Several variants of CAPR are assumed:
- Integrated - Collector and CAPR on one piece of iron.
- Local - working with a limited list of equipment. Assume within the same organization or territory.
- Global is an Internet resource that works with Collectors within the Internet.
- Regional (optional) - to distribute the load of the Global.
All lower-level DACCs can interact with the Global DACS, which stores the most complete base of the features of the NCA.
Act One. We create an integrated CARP-Collector for the control of the NSA.
What is the NSA Collector at this stage? This is, in fact, a Linux computer placed in a 1U package. The collector has 3 network interfaces. Two included across the network. One management interface. CAPR is located on the same platform.
Here is the current wiring diagram:
Any external interaction of the collector is only through the control interface. For Internet traffic, the Collector is transparent.
Since now we are engaged in the development of the basic algorithm of this stand is enough. Of course, the finished product will have more advanced iron and resiliency tools.
What does the collector do? Collects specified traffic parts. Headers and, if necessary, the contents of the packages. This is configured by the rules. It makes no sense to collect all the traffic. Traffic data for a short period of time (depending on the load and size of the working disk, week-month) is stored on the collector. Thus, the Collector can act as a simultaneous replacement of the source, the collector and the system displaying statistics of the Netflow type. Of course, since the Collector contains information about each session, it is not intended to store statistics for long periods of time. If there is a need for this, the statistics can be reset to the network storage or to a plug-in disk as files, and further analyzed and displayed by means of the DAC.
The collector is not stupid. It analyzes traffic based on certain DACR rules and sends information to the DAC in the event of trigger filters determined by DACR. In addition, the Collector independently filters traffic.
Something like this.
As we worked on the Collector, the idea came to load it with other functions. I will not tell about all planned functions. But there is a desire to integrate the server and the SNMP Trap collector into the SYSLOG collector. This is necessary, including to analyze the correlation of some events.
As a side, commercial product, let's say, a bad piece of hardware that can handle traffic out of the box, collect logs, network statistics, ladders and display all of this in a simple and understandable way with event notifications?
The project is open to participation.
If anyone has their own interesting developments on the topic of SYSLOG, SNMP, write in a personal, create a joint product.
General conditions:
- No “on the basis of ...”, only its own, unique, and if there is a front-end, then it must be user-friendly! To be able to work without a keyboard. No braking and java curves. Zabbix and Logstash go to Kibane too. C, Python, Perl, PHP, HTML, CSS, JS (clean, without framorkoff. Even without jQuery, yes) are welcome.
- Orientation only on modern OS and browsers. No compatibility with MS-DOS on IBM XT and Internet Explorer 1.0.
- Linux-only.
Business ideas are welcome, but this is not the main thing. At this stage, we need technical ideas, brains and time. If a worthy piece of hardware, how to file and sell will be decided by itself.
For a highly intellectual community, I propose a problem from the Collector (I haven't decided it myself yet):
The original diagram is as in the figure above. The router is connected to the ISP by PPPoE and on it the address is 91.122.49.173. The address is already lit from previous articles. But this is good for testing - there is a constant interest.
This is what the Collector showed:
The red marker is an example of the NSA. In this case, the sign is that neither the source address nor the destination address belongs to the ES. UDP protocol, destination port 5000. The topic about Trojans is known. But the ES has only one external PAT address (91.122.49.173). That is, I expect that in the ISP-Router channel I will only see packets whose source address or destination address is the external address of the router.
Let's see the story for today:
Here we see that, using the same scheme, packets with the same source address, but with different destination addresses fly through our Collector.
How this traffic arrives, I have not figured it out yet. If someone has thoughts - please state in the comments. Encountering such an NSA, the Collector sets a trap on this traffic and, when it next appears, collects more detailed information and then bans it. This is of course only one case. Just for me it is inexplicable for now;
Respectfully,
R_voland.