How to protect the IP camera from the Mirai botnet with Flussonic Agent
The recent series of record DDoS attacks against terabit has excited those who seem to be used to it. It is possible that the situation will recur in the near future, and with significantly greater force, because the basic causes of the emergence of such a powerful botnet as Mirai are not eliminated.
In fact, the lack of IP cameras is generally an open secret and there are many reasons for this: it is the historical practice of working with them, the difficulty of accessing them, the inertia of the manufacturers.
I want to talk about some aspects of this problem and what steps can be taken to alleviate this problem.
')
So, now in the world millions of IP cameras are sold. The very first link from the Internet says about 200 million security cameras, and this figure looks quite reasonable.
Not all CCTV cameras are IP; a huge number of analog cameras are still being sold. Analog cameras are understandable, kind of convenient, predictable: after all, they do not have any buggy software, everything is hardware. But even despite the last burst of AHD and HDCVI , IP cameras, due to better picture quality and greater flexibility, are replacing the analogue (an excellent reason to reasonably discuss such an interesting question in the comments).
An IP camera consists of a sensor, a video processing and coding chip, a processor for general processing, GPIO, SDcard and Ethernet type peripherals, software inside it, a lens and a housing.
Despite the seemingly huge variety of IP cameras on the market (it seems that there are at least many thousands of “manufacturers”, maybe even more), in fact, there are very few people who actually do something inside. If you lower the price bar, having thrown out from consideration such respected giants as Axis, then in the price range, for example, “up to $ 150 per camera” there will be very few companies.
About 3-4 manufacturers of sensors, 4-6 manufacturers of chips + processors (this is a combined chip), several of those who collect everything for a fee. Shells - and those are not particularly diverse, but the whole of Shenzhen of those who are ready to assemble it, twist and paste the desired logo on the box. But the most interesting thing is those who make software. In many ways, their engineering solutions opened the way for Mirai.
There are too few of them, it didn’t happen here to grow to a large number of manufacturers. All information is quite hidden and this is the source of the problem. Inside almost all cameras there is an ordinary Linux with modules to the core. These modules allow you to configure the chip that processes video from the sensor and receive this video in the program's memory. There are cameras that are without Linux: there is actually one big program that lives in ring 0 (if you can talk about ARM like that), but this is very expensive to develop and is rare today. Then send the video to the network is a matter of technology, and this is exactly the matter rather mediocre.
Not only the majority of cheap cameras have mastered the fine art of data loss over TCP, so there is also almost everywhere the same password in the series. What we, in fact, saw from the source of the botnet.
And we will not tell you about the magic magic UDP packets that allow you to change network settings. All that nonsense that we laugh at in Hollywood films about “I entered their system, now I’ll switch their video cameras to a static picture” is not at all nonsense, but a bitter and cruel reality.
Where does such carelessness of manufacturers come from? After all, their behavior causes an association primarily with the joke about Vovochka and a word that does not exist, although the object itself seems to be as it is. It is very and very difficult to get from the manufacturer of the firmware any specific information about the guts of the camera, they, as a rule, adhere to the position that this is a closed device, in which there is no way like Linux. And maybe there is, but this does not concern you, do not look there, look at our handouts.
We will try to think about what could lead to this.
Firstly, the subject of video surveillance traditionally revolves around isolated networks. All this grew out of 4 cameras connected directly to the monitor in front of the security guard in a mosaic (by the way, we are able to do server mosaics and very cool, but all of a sudden it is not for the security guard, but to save space). The guard sits with a baton in his hands the entire shift and within 1250 milliseconds breaks in the direction of any problem. The neural network handles any abnormalities worse than your Nvidia Tesla. The truth sometimes likes to drink or take a nap, which is great spoils the whole picture.
Connecting to such a network requires a physical presence to begin with, and against this it is possible to cover the path of the cable passage with the same cameras. It is said that in gloomy people these cables are almost buried in hermetic tubes with increased pressure, so that the pressure sensor will be triggered when drilling to the cable.
It is important to understand: until now, almost no one offers even TLS video encryption, leaving the cameras! The whole subject of video surveillance is not particularly designed for the internal security of the video infrastructure itself. At least, not as much as those who gladly take money to fight with terrible threats inflate their cheeks.
Secondly, IP cameras are usually still part of an entire infrastructure for solving security tasks and are part of a software-hardware-human-service complex. Those. Traditionally, the IP camera is stuck into the recorder, to it a guard, a guard to the button, to the button a rapid response team. The fact that today all of a sudden people began to hang cameras on their doorstep, and the cities were hung up on the streets by the thousands - all this goes a bit counter with what it was all planned for. Those. There are new formats for the use of very successful devices for which this device is not particularly intended.
Thirdly, the IP camera is a very isolated device. It is extremely difficult to take an IP camera in your hands and configure it specifically, because there are practically no I / O interfaces.
This is a topic for a separate article and we will tell about it, but let's just remember this moment: it’s really inconvenient to configure an IP camera.
So, IP cameras suddenly became needed as an OTT device, with online access to them. The term OTT - over the top - means that the service is not in a controlled network, but through the public Internet, or at least through the junction of several networks. Those. in conditions when there will be no guarantee of speed and it is possible to speak only about a rather ephemeral concept, like “Internet speed”. However, as we have already found out, the “Internet speeds” from the camera in Brazil to the Dyn servers were quite enough for them to lift their heads.
Where previously an isolated system was hung up, terminated on a security guard, a device now appeared, which is accessed via the Internet for video. See: how is it going in your little shop, is it still worth the mailbox in front of the house, how are the children in the kindergarten playing. Of course, camera manufacturers (mostly Chinese, because only their cameras can be afforded) answered the challenge of the market. There are mobile applications (on IP cameras today, there is practically no opportunity to see video without ActiveX, so web cameras do not offer web access to video cameras), which go directly to the camera and show video.
Then an interesting situation arose: people began to accustom people to accessing ports outside for online access. Many of these clients do not even use the standard RTSP protocol,
instead of it, they are chasing video on an interesting and exotic thing that follows protocol 34567 (we are slowly sorting out its structure), but who cares about this when it's easier to put all the ports out. And who may need my little camera, which looks at the parking in front of the house?
Those. an important prerequisite for the launch of Mirai was the fact that manufacturers for providing online access massively forced people to figure out the port forwarding and massively put devices that could generate dozens of megabits of traffic to the Internet, and most of them were devices with the same root password. Just fine, is not it? All this wealth lay here under the feet of the last 5 years at least.
How this problem will be solved now is still unclear, and this is not entirely our competence. You can go through all the cameras found on the Internet en masse and turn them into bricks, you can patch them en masse, you can force providers to block them. We want to talk about something else: how not to turn a camera into a member of such a botnet today.
Progress does not stand still and today there are two basic ways to access IP cameras online: directly and through a server on the Internet.
Access is directly reasonable in the case of a local network, but as we have already found out, to go directly to a modern IP camera via the Internet is not always a good idea. Even when security issues are resolved, there will still be a problem with simultaneous access to cameras. So, for example, in kindergartens, the administrator's request to parents does not look at the cameras for more than four at a time.
Today there is a lot of ADSL Internet, the key feature of which is A, asymmetric. You can download a lot, but give a lot already hard.
So let's talk about online services that provide access to cameras.
An online camera access service (VSaaS, video surveillance as a service) in addition to being able to watch the camera remotely can offer some interesting features, the most important of which is the remote recorder. Very often the DVR, the device on which the video is written, first suffers during illegal actions. When the video immediately leaked to the Internet, it is already very difficult to get it from there, a task of approximately the same nature as an attempt to cram a bribe into a traffic camera. Yes, it certainly will not save the cameras themselves and still the recording will be interrupted, but the chance to take the photos of the intruders to the police is growing.
Say expensive to write all the videos on the Internet? More recently, one thought about watching movies online was scary and made me grab my wallet, but today this is the norm instead of shelves from a CD. The same is with unused reverse traffic: why not download, especially if the service is provided by your provider. Some write to the cloud in motion, but here and to this day there are arguments both for and against. What will it cost to save a couple thousand rubles, if the camera does not record those 10 minutes that were needed? On the other hand, for many cases, switching the camera to motion detection recording mode makes the cloud service itself almost free for its supplier.
How do Internet services get to the cameras, especially OTT, i.e. not owning the communication channel to the camera?
How can you make a camera connection more secure with an online service without exposing it outside? Through the communication channel directly with the service.
Let's raise something like a VPN tunnel or publish video from the camera to the server and then remove the problem with mirai. Some Chinese here went further and sell cameras that allegedly work only with their service. Here, however, the situation is again like Vovochka and the forbidden word, because despite the assurances of Chinese managers, such cameras still have an RTSP server, and a login with a standard password.
Our dear southeastern neighbors here create a host of other interesting sources for future problems. For example, we got into the hands of a camera with an online service for accessing this camera on board. The camera had such a wonderful opportunity as sending mail when a motion detector was triggered. The camera manufacturer decided to go backendless by stitching the same username and password from one account on 163.com (this is such a Chinese mail.ru) to all the cameras. As you understand, you can not only see what other buyers of this camera have interesting, but also send something interesting and very active to buyers of such a camera.
But let's return to a more standard situation today: online access to the camera complements the traditional work with the registrar, and the camera itself behind the NAT is not visible from the outside.
We have seen two basic ways to get video from the camera: some kind of software on the camera publishes the video to the server, i.e. is the initiator of the beginning of the video transmission, and some software on the camera makes the camera available to the server on the Internet (read the VPN tunnel).
The second method is almost always much more practical, since it allows the server to decide for itself when to take the video, what quality, or even to take screenshots from the camera.
In the first case, it is necessary to think through complex feedback mechanisms so that you can always say “a pot, do not cook”, otherwise you will make yourself a micro-mirai: 1000 cameras trying to fill the megabit stream not where it is needed, quite pulls on solid the problem.
Let's take a little look at what options are there to organize a VPN tunnel or something similar.
The easiest option is traditionally OpenVPN. The server part is free and relatively easy to configure when you need to make 100-300 cameras. The main plus of openvpn is that it is already out of the box in the buildroot project, with the help of which the firmware of most cameras are assembled.
The OpenVPN client runs on the camera, somehow, at the first start, it receives a certificate and then goes to the service. There is a streaming server on the other side, which sees that the camera is connected, and starts to take video, screenshots or other things from it.
The VPN approach is also convenient because all the variability of logic on the service side. There it is much easier and more convenient to update, maintain, change something than on camera. The price of an error on the camera is the loss not only of the camera, but also of the client, and even fun and enjoyable discussions on the forums.
This approach has its drawbacks.
VPN is still a powerful mechanism for solving very common tasks and is quite resource-intensive for a server. Unfortunately, we have not received any practical data on whether it is possible to receive gigabit traffic through OpenVPN on one server and send it to the streaming server, but apparently this is a brute force.
Absolutely, we can say that using OpenVPN is at least doubling the server infrastructure compared to a regular system, because you need to drive traffic first to a separate OpenVPN server, and then to a streaming server.
We in Erlivideo have developed our own solution for accessing cameras for NAT, requiring the installation of our agent on the camera. It works differently.
So, we set ourselves the goal to develop some software that is placed on the camera in order to get to the camera from a server on the Internet.
We abandoned the idea of ​​doing a separate VPN server, a separate streaming server - after all, traffic is expected to be large for each server, why duplicate it between different software. Our agent connects directly to Flussonic and sends the video from the camera immediately to the RTSP parsing function, i.e. This is not a generalized transport, but a specialized piece for delivering video and screenshots from the camera to Flussonic with minimal costs.
We also solved a few questions, namely: what address to go to this agent and what to do if Flussonic turns off.
With the shutdown of Flussonic, we decided to enter a two-phase protocol scheme: first, the agent connects to the coordinator (endpoint in our terminology) and then from him goes to the streaming server. If the endpoint fell after connecting to the streamer, then that's okay, the work continues.
With the endpoint address, the situation is trickier. Since we are not a service company, but a software company, we sell software to people to organize their services. Thus, we can not sew one fixed address in the agent, it is necessary that it be customizable. Here we also thought out an uncomplicated technical solution that allows you to send an agent to the right address during the initial activation.
As a result, we have our own simple mechanism for gaining access to a camera located behind a NAT. Even with encryption enabled, it is less resource-intensive than low-level OpenVPN, and, unlike the latter, it helps to solve the “ bug that doesn’t exist, ” because all data is quickly taken by our agent, and from it, using the household libevent, is poured into the Internet.
On the server, Flussonic himself decides, according to his settings, that he needs to go to the camera and pick up a video or a screenshot from it, or even start a reverse audio broadcast.
Such approaches (full-time vpn, camera publishing, self-made tunnel) reduce the risk of placing the camera on the Internet. In the following articles we will talk about how we fill our agent with cameras, how it works in the service of providing video from cameras to users, what interesting moments there are with its setting and what is most interesting, how the camera is attached to the user - there is a whole lot options. Even in the drafts there is about your own IP camera firmware - write in the comments, which is more interesting.
In fact, the lack of IP cameras is generally an open secret and there are many reasons for this: it is the historical practice of working with them, the difficulty of accessing them, the inertia of the manufacturers.
I want to talk about some aspects of this problem and what steps can be taken to alleviate this problem.
')
Current state of affairs
So, now in the world millions of IP cameras are sold. The very first link from the Internet says about 200 million security cameras, and this figure looks quite reasonable.
Not all CCTV cameras are IP; a huge number of analog cameras are still being sold. Analog cameras are understandable, kind of convenient, predictable: after all, they do not have any buggy software, everything is hardware. But even despite the last burst of AHD and HDCVI , IP cameras, due to better picture quality and greater flexibility, are replacing the analogue (an excellent reason to reasonably discuss such an interesting question in the comments).
An IP camera consists of a sensor, a video processing and coding chip, a processor for general processing, GPIO, SDcard and Ethernet type peripherals, software inside it, a lens and a housing.
Despite the seemingly huge variety of IP cameras on the market (it seems that there are at least many thousands of “manufacturers”, maybe even more), in fact, there are very few people who actually do something inside. If you lower the price bar, having thrown out from consideration such respected giants as Axis, then in the price range, for example, “up to $ 150 per camera” there will be very few companies.
About 3-4 manufacturers of sensors, 4-6 manufacturers of chips + processors (this is a combined chip), several of those who collect everything for a fee. Shells - and those are not particularly diverse, but the whole of Shenzhen of those who are ready to assemble it, twist and paste the desired logo on the box. But the most interesting thing is those who make software. In many ways, their engineering solutions opened the way for Mirai.
There are too few of them, it didn’t happen here to grow to a large number of manufacturers. All information is quite hidden and this is the source of the problem. Inside almost all cameras there is an ordinary Linux with modules to the core. These modules allow you to configure the chip that processes video from the sensor and receive this video in the program's memory. There are cameras that are without Linux: there is actually one big program that lives in ring 0 (if you can talk about ARM like that), but this is very expensive to develop and is rare today. Then send the video to the network is a matter of technology, and this is exactly the matter rather mediocre.
Not only the majority of cheap cameras have mastered the fine art of data loss over TCP, so there is also almost everywhere the same password in the series. What we, in fact, saw from the source of the botnet.
And we will not tell you about the magic magic UDP packets that allow you to change network settings. All that nonsense that we laugh at in Hollywood films about “I entered their system, now I’ll switch their video cameras to a static picture” is not at all nonsense, but a bitter and cruel reality.
Where does such carelessness of manufacturers come from? After all, their behavior causes an association primarily with the joke about Vovochka and a word that does not exist, although the object itself seems to be as it is. It is very and very difficult to get from the manufacturer of the firmware any specific information about the guts of the camera, they, as a rule, adhere to the position that this is a closed device, in which there is no way like Linux. And maybe there is, but this does not concern you, do not look there, look at our handouts.
Prerequisites
We will try to think about what could lead to this.
Firstly, the subject of video surveillance traditionally revolves around isolated networks. All this grew out of 4 cameras connected directly to the monitor in front of the security guard in a mosaic (by the way, we are able to do server mosaics and very cool, but all of a sudden it is not for the security guard, but to save space). The guard sits with a baton in his hands the entire shift and within 1250 milliseconds breaks in the direction of any problem. The neural network handles any abnormalities worse than your Nvidia Tesla. The truth sometimes likes to drink or take a nap, which is great spoils the whole picture.
Connecting to such a network requires a physical presence to begin with, and against this it is possible to cover the path of the cable passage with the same cameras. It is said that in gloomy people these cables are almost buried in hermetic tubes with increased pressure, so that the pressure sensor will be triggered when drilling to the cable.
It is important to understand: until now, almost no one offers even TLS video encryption, leaving the cameras! The whole subject of video surveillance is not particularly designed for the internal security of the video infrastructure itself. At least, not as much as those who gladly take money to fight with terrible threats inflate their cheeks.
Secondly, IP cameras are usually still part of an entire infrastructure for solving security tasks and are part of a software-hardware-human-service complex. Those. Traditionally, the IP camera is stuck into the recorder, to it a guard, a guard to the button, to the button a rapid response team. The fact that today all of a sudden people began to hang cameras on their doorstep, and the cities were hung up on the streets by the thousands - all this goes a bit counter with what it was all planned for. Those. There are new formats for the use of very successful devices for which this device is not particularly intended.
Thirdly, the IP camera is a very isolated device. It is extremely difficult to take an IP camera in your hands and configure it specifically, because there are practically no I / O interfaces.
This is a topic for a separate article and we will tell about it, but let's just remember this moment: it’s really inconvenient to configure an IP camera.
Online
So, IP cameras suddenly became needed as an OTT device, with online access to them. The term OTT - over the top - means that the service is not in a controlled network, but through the public Internet, or at least through the junction of several networks. Those. in conditions when there will be no guarantee of speed and it is possible to speak only about a rather ephemeral concept, like “Internet speed”. However, as we have already found out, the “Internet speeds” from the camera in Brazil to the Dyn servers were quite enough for them to lift their heads.
Where previously an isolated system was hung up, terminated on a security guard, a device now appeared, which is accessed via the Internet for video. See: how is it going in your little shop, is it still worth the mailbox in front of the house, how are the children in the kindergarten playing. Of course, camera manufacturers (mostly Chinese, because only their cameras can be afforded) answered the challenge of the market. There are mobile applications (on IP cameras today, there is practically no opportunity to see video without ActiveX, so web cameras do not offer web access to video cameras), which go directly to the camera and show video.
Then an interesting situation arose: people began to accustom people to accessing ports outside for online access. Many of these clients do not even use the standard RTSP protocol,
instead of it, they are chasing video on an interesting and exotic thing that follows protocol 34567 (we are slowly sorting out its structure), but who cares about this when it's easier to put all the ports out. And who may need my little camera, which looks at the parking in front of the house?
Those. an important prerequisite for the launch of Mirai was the fact that manufacturers for providing online access massively forced people to figure out the port forwarding and massively put devices that could generate dozens of megabits of traffic to the Internet, and most of them were devices with the same root password. Just fine, is not it? All this wealth lay here under the feet of the last 5 years at least.
How this problem will be solved now is still unclear, and this is not entirely our competence. You can go through all the cameras found on the Internet en masse and turn them into bricks, you can patch them en masse, you can force providers to block them. We want to talk about something else: how not to turn a camera into a member of such a botnet today.
Modern camera access
Progress does not stand still and today there are two basic ways to access IP cameras online: directly and through a server on the Internet.
Access is directly reasonable in the case of a local network, but as we have already found out, to go directly to a modern IP camera via the Internet is not always a good idea. Even when security issues are resolved, there will still be a problem with simultaneous access to cameras. So, for example, in kindergartens, the administrator's request to parents does not look at the cameras for more than four at a time.
Today there is a lot of ADSL Internet, the key feature of which is A, asymmetric. You can download a lot, but give a lot already hard.
So let's talk about online services that provide access to cameras.
An online camera access service (VSaaS, video surveillance as a service) in addition to being able to watch the camera remotely can offer some interesting features, the most important of which is the remote recorder. Very often the DVR, the device on which the video is written, first suffers during illegal actions. When the video immediately leaked to the Internet, it is already very difficult to get it from there, a task of approximately the same nature as an attempt to cram a bribe into a traffic camera. Yes, it certainly will not save the cameras themselves and still the recording will be interrupted, but the chance to take the photos of the intruders to the police is growing.
Say expensive to write all the videos on the Internet? More recently, one thought about watching movies online was scary and made me grab my wallet, but today this is the norm instead of shelves from a CD. The same is with unused reverse traffic: why not download, especially if the service is provided by your provider. Some write to the cloud in motion, but here and to this day there are arguments both for and against. What will it cost to save a couple thousand rubles, if the camera does not record those 10 minutes that were needed? On the other hand, for many cases, switching the camera to motion detection recording mode makes the cloud service itself almost free for its supplier.
How do Internet services get to the cameras, especially OTT, i.e. not owning the communication channel to the camera?
Camera connection
How can you make a camera connection more secure with an online service without exposing it outside? Through the communication channel directly with the service.
Let's raise something like a VPN tunnel or publish video from the camera to the server and then remove the problem with mirai. Some Chinese here went further and sell cameras that allegedly work only with their service. Here, however, the situation is again like Vovochka and the forbidden word, because despite the assurances of Chinese managers, such cameras still have an RTSP server, and a login with a standard password.
Our dear southeastern neighbors here create a host of other interesting sources for future problems. For example, we got into the hands of a camera with an online service for accessing this camera on board. The camera had such a wonderful opportunity as sending mail when a motion detector was triggered. The camera manufacturer decided to go backendless by stitching the same username and password from one account on 163.com (this is such a Chinese mail.ru) to all the cameras. As you understand, you can not only see what other buyers of this camera have interesting, but also send something interesting and very active to buyers of such a camera.
But let's return to a more standard situation today: online access to the camera complements the traditional work with the registrar, and the camera itself behind the NAT is not visible from the outside.
We have seen two basic ways to get video from the camera: some kind of software on the camera publishes the video to the server, i.e. is the initiator of the beginning of the video transmission, and some software on the camera makes the camera available to the server on the Internet (read the VPN tunnel).
The second method is almost always much more practical, since it allows the server to decide for itself when to take the video, what quality, or even to take screenshots from the camera.
In the first case, it is necessary to think through complex feedback mechanisms so that you can always say “a pot, do not cook”, otherwise you will make yourself a micro-mirai: 1000 cameras trying to fill the megabit stream not where it is needed, quite pulls on solid the problem.
Let's take a little look at what options are there to organize a VPN tunnel or something similar.
Openvpn
The easiest option is traditionally OpenVPN. The server part is free and relatively easy to configure when you need to make 100-300 cameras. The main plus of openvpn is that it is already out of the box in the buildroot project, with the help of which the firmware of most cameras are assembled.
The OpenVPN client runs on the camera, somehow, at the first start, it receives a certificate and then goes to the service. There is a streaming server on the other side, which sees that the camera is connected, and starts to take video, screenshots or other things from it.
The VPN approach is also convenient because all the variability of logic on the service side. There it is much easier and more convenient to update, maintain, change something than on camera. The price of an error on the camera is the loss not only of the camera, but also of the client, and even fun and enjoyable discussions on the forums.
This approach has its drawbacks.
VPN is still a powerful mechanism for solving very common tasks and is quite resource-intensive for a server. Unfortunately, we have not received any practical data on whether it is possible to receive gigabit traffic through OpenVPN on one server and send it to the streaming server, but apparently this is a brute force.
Absolutely, we can say that using OpenVPN is at least doubling the server infrastructure compared to a regular system, because you need to drive traffic first to a separate OpenVPN server, and then to a streaming server.
We in Erlivideo have developed our own solution for accessing cameras for NAT, requiring the installation of our agent on the camera. It works differently.
Flussonic agent
So, we set ourselves the goal to develop some software that is placed on the camera in order to get to the camera from a server on the Internet.
We abandoned the idea of ​​doing a separate VPN server, a separate streaming server - after all, traffic is expected to be large for each server, why duplicate it between different software. Our agent connects directly to Flussonic and sends the video from the camera immediately to the RTSP parsing function, i.e. This is not a generalized transport, but a specialized piece for delivering video and screenshots from the camera to Flussonic with minimal costs.
We also solved a few questions, namely: what address to go to this agent and what to do if Flussonic turns off.
With the shutdown of Flussonic, we decided to enter a two-phase protocol scheme: first, the agent connects to the coordinator (endpoint in our terminology) and then from him goes to the streaming server. If the endpoint fell after connecting to the streamer, then that's okay, the work continues.
With the endpoint address, the situation is trickier. Since we are not a service company, but a software company, we sell software to people to organize their services. Thus, we can not sew one fixed address in the agent, it is necessary that it be customizable. Here we also thought out an uncomplicated technical solution that allows you to send an agent to the right address during the initial activation.
As a result, we have our own simple mechanism for gaining access to a camera located behind a NAT. Even with encryption enabled, it is less resource-intensive than low-level OpenVPN, and, unlike the latter, it helps to solve the “ bug that doesn’t exist, ” because all data is quickly taken by our agent, and from it, using the household libevent, is poured into the Internet.
On the server, Flussonic himself decides, according to his settings, that he needs to go to the camera and pick up a video or a screenshot from it, or even start a reverse audio broadcast.
Such approaches (full-time vpn, camera publishing, self-made tunnel) reduce the risk of placing the camera on the Internet. In the following articles we will talk about how we fill our agent with cameras, how it works in the service of providing video from cameras to users, what interesting moments there are with its setting and what is most interesting, how the camera is attached to the user - there is a whole lot options. Even in the drafts there is about your own IP camera firmware - write in the comments, which is more interesting.
Source: https://habr.com/ru/post/314146/
All Articles