TheUberOverLord

1. Make sure the static IP Address is actually being assigned in the cameras configuration using the Router/AP's local IP Address for the Gateway and DNS values in that configuration vs. by any MAC Address games in the Router/AP. 2. Make sure that UPnP is disabled in the cameras configuration. 3. Double/Triple check your static IP Addresses ("Especially those assigned by MAC Address in the Router/AP") and Port Forwarding entries, to make sure there are no conflicts/duplicities. Check any current UPnP entries in the Router/AP's UPnP tables and delete any that are still referencing any cameras. Don

Price points and budget can make people choose this or that brand. Here are live demos of All Foscam models being sold. Both MJPEG and H.264 models. These demos are using automatic refreshed Snapshots. To help minimize bandwidth usage. The live demo cameras are located in the U.S. but if you use the link below at the bottom of that page, it will also show the China demo cameras. You can also see live demo cameras in China, at the same time. This helps to see live demo cameras of the same model, during the day and using IR at the same time. Since the time zone difference is 13 hours from one set of demo cameras to the other: http://107.170.59.150/foscam/FoscamUS.htm If you want to see a HD model at 1280x720 that has 3x zoom. Please see this since the other demos are at 640 widths for demonstration purposes. All the HD demo cameras used here. Support a maximum resolution of 1280x960: http://107.170.59.150/foscam/SecureImageDisplayControl.htm The goals were to allow people to view and control demo cameras quickly. Without any need to login, install any plugins or additional software and to allow all the cameras to be viewed and controlled from any device that is Internet browser capable. So that you can quickly and easily see how they look on the devices of your choice. Don

More here: http://www.news.com.au/technology/experts-warn-bash-bug-poses-catastrophic-threat-to-devices-in-the-home/story-e6frfrnr-1227070183296 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271 Don

There are now Seven not Six any longer "Bash" AKA Shellshock vulnerabilities which have been located as of 10/04/2014 4:00 PM CTD time. More here: https://shellshocker.net/ These are NEW items added to the list. Please also see the post above of other list items. McAffee Products has fixes for Bash AKA Shellshock now: https://kc.mcafee.com/corporate/index?page=content&id=SB10085#status Symantec Products has fixes for Bash AKA Shellshock now: http://www.symantec.com/outbreak/?id=shellshock Avaya Products has fixes for Bash AKA Shellshock now: https://support.avaya.com/helpcenter/getGenericDetails?detailId=C2014926131554370002 Kace Endpoint Systems Management Products has fixes for Bash AKA Shellshock now: http://www.kace.com/support/resources/kb/solutiondetail?sol=133716 Riverbed Products has fixes for Bash AKA Shellshock now: https://supportkb.riverbed.com/support/index?page=content&id=S24997 Untangle Products has fixes for Bash AKA Shellshock now: https://support.untangle.com/hc/en-us/articles/203518036-What-is-ShellShock-Are-Untangle-products-vulnerable- pfSense Products has fixes for Bash AKA Shellshock now: https://www.pfsense.org/security/advisories/pfSense-SA-14_18.packages.asc Additional Bash Flaws Show Weakness of Original Shellshock Patch now: http://www.infosecurity-magazine.com/news/additional-bash-flaws-original/ Windows What to understand and know about Bash AKA Shellshock vulnerabilities: http://grandstreamdreams.blogspot.com/2014/10/shellshockbash-bug-news-and-linkage.html Bash AKA Shellshock vulnerabiltiy determined to have been present since at least 12/08/1991. Investigation contunues on how far back it goes: http://www.openwall.com/lists/oss-security/2014/10/04/2 Don

QNAP NAS Front-Ends have fixes for Bash AKA Shellshock now: http://forum.qnap.com/viewtopic.php?f=12&t=98167&sid=4c0f42e64b3a9887911370dedca360ee http://forum.qnap.com/viewtopic.php?f=187&t=98188 http://forum.qnap.com/viewtopic.php?f=12&t=98031&sid=4c0f42e64b3a9887911370dedca360ee HomeTroller Zee Front-End has fixes for Bash AKA Shellshock now: http://board.homeseer.com/showpost.php?p=1139412&postcount=1 Synology Front-End has fixes for Bash AKA Shellshock now: https://www.synology.com/en-global/support/security/bash_shellshock Synology support forum: http://forum.synology.com/enu/index.php Note: If you have added Optware/Entware installed on any of the above devices. You should use the support forums for those devices. Above. If you have Optware/Entware installed in your Router/AP as a custom add-on you should also go to the support forum for that Router/AP because both Optware/Entware do use "Bash" even if the Router/AP does not use "Bash" as its default shell and both Optware/Entware can be vulnerable to these "Bash" vulnerabilities. Depending on how you set them up and any custom scripts you may allow to access them remotely. Netgear Front-Ends: ReadyNAS, ReadyDATA, ProSECURE UTM firewall and ProSAFE FVS318N have fixes for Bash AKA Shellshock now: http://kb.netgear.com/app/answers/detail/a_id/25703 OpenVPN Issues to be aware of: http://www.theregister.co.uk/2014/09/30/openvpn_open_to_shellshock_researcher/ VMware Issues to be aware of: http://s1.securityweek.com/vmware-releases-software-updates-fix-shellshock-bug Cisco/Oracle Issues to be aware of: http://www.computerworld.in/news/cisco,-oracle-find-dozens-of-their-products-affected-by-shellshock McAffee Products has fixes for Bash AKA Shellshock now: https://kc.mcafee.com/corporate/index?page=content&id=SB10085#status Symantec Products has fixes for Bash AKA Shellshock now: http://www.symantec.com/outbreak/?id=shellshock Avaya Products has fixes for Bash AKA Shellshock now: https://support.avaya.com/helpcenter/getGenericDetails?detailId=C2014926131554370002 Kace Endpoint Systems Management Products has fixes for Bash AKA Shellshock now: http://www.kace.com/support/resources/kb/solutiondetail?sol=133716 Riverbed Products has fixes for Bash AKA Shellshock now: https://supportkb.riverbed.com/support/index?page=content&id=S24997 Untangle Products has fixes for Bash AKA Shellshock now: https://support.untangle.com/hc/en-us/articles/203518036-What-is-ShellShock-Are-Untangle-products-vulnerable- pfSense Products has fixes for Bash AKA Shellshock now: https://www.pfsense.org/security/advisories/pfSense-SA-14_18.packages.asc Additional Bash Flaws Show Weakness of Original Shellshock Patch now: http://www.infosecurity-magazine.com/news/additional-bash-flaws-original/ Windows What to understand and know about Bash AKA Shellshock vulnerabilities: http://grandstreamdreams.blogspot.com/2014/10/shellshockbash-bug-news-and-linkage.html Bash AKA Shellshock vulnerability determined to have been present since at least 12/08/1991. Investigation continues on how far back it goes: http://www.openwall.com/lists/oss-security/2014/10/04/2 Outstanding known not public vulnerabilities I use a standard protocol when I encounter vulnerabilities with devices/software which I have used for many years when doing security research testing. I allow the Manufacturers/Vendors 30 days before I go public with my findings. Worse case I may give a 15 day extension if the Manufacturer/Vendor works with me, to help better prove they are actively working on a fix. Example: http://www.kb.cert.org/vuls/id/265532 I am aware of three other embedded devices which include other Front-Ends and one IP Camera. Which while testing I found had exposure to the current "Bash" vulnerabilities and am waiting on responses from the Manufacturers/Vendors. Based on each Manufacturers/Vendors response will help me decide if I will create a formal CVE for the vulnerability. Which sometimes I don't do and work with the Manufacturer/Vendor privately. If they don't play games. If they do play games, then I do file a formal CVE as the above CVE example link shows. Foscam has never played any games with me other than the first time. Which is sometimes normal. Since then, I have worked privately with Foscam to fix many vulnerability issues I have found since. Personally, I would rather work privately then file a formal CVE. I will add other Front-Ends and/or IP Cameras to this list as their Manufacturers/Vendors provide fixes that I locate and find here as well. Don

Here are some more in depth details about this vulnerability: http://seclists.org/oss-sec/2014/q3/650 http://www.troyhunt.com/2014/09/everything-you-need-to-know-about.html https://www.webmaster.net/shellshock-fix-bash-vulnerability-bug-and-determine-if-your-system-is-vulnerable/ Don

IMHO. When purchasing cheap IP Cameras. If you are not technically inclined as in willing to do whatever it takes when a IP Camera has software/hardware issues that may require time and effort to be resolved. It's best to make sure that you purchase in country and from a supplier/seller that has at least some kind of warranty that ideally should cover the cost of IP Camera return/replacement shipping as well. For some finite period of time. Even a 30 day window and you have done some research that they in fact have honored that when their IP Cameras need to be replaced. You might be able to locate the same camera near the price you find it with the above included. You might not. The issue is IF you purchase out-of-country and you the buyer are responsible to pay for shipping for camera repair or replacement. The costs and/or the delay waiting on having a functional IP camera, may not be worth the price of what "Looks" like a deal. Secondly. Many if not most IP Cameras have security vulnerabilities which become published in the public domain. From time to time. If the IP Camera manufacturer is not going to be updating firmware on a regular basis to at least deal with this when/if it happens? Then you risk exposing any data stored in the IP Cameras camera configuration data. Including but not limited to any Email and/or FTP User credentials. Used for this IP Camera. If you intend to expose those IP Cameras directly to the Internet. Suddenly $36.00 U.S. including shipping. Is not such a good idea when that purchase may cause you to spend the many hours to deal with the "Identity Theft" that occurred, by your choice of IP Camera. Don

I personally don't know what URL can be used directly from a browser window to pull a snapshot from this camera model. Maybe someone else here knows? The end-goal is to not need to go to the logon page first. Don

Just a heads up. Ports 80, 8080 and 8090 are some of the worse ports you can use for an IP Camera. In many cases it can cause port conflicts with your local network equipment when trying to use them for remote access to your IP Cameras. You would be much better off changing the port to port 90 as an example. Of course this will require you to change both the cameras port configuration as well as your port forwarding setup. Don

Thanks. What URL ("If any") works currently for your camera when using it from a browser window directly to your camera for a snapshot? You can replace any private data with made up data. Don

Hello, So I think you can see your camera without the restrictions in place? Assuming that the HTML file you are using is "SecureImageDisplay.htm" You should try accessing that with the restrictions commented out in "SecureImageDisplay.php" to make sure that works. Once that is working. Then to force the logon to the camera you need to access the camera using "SecureImageDisplayLogin.php" and not "SecureImageDisplay.htm". Once that is working. You need to change "RestrictToSecureImageDisplayLogin.php" to match your website and folder location. If your end-goal is to restrict access to the camera by forcing the logon page to be always used. Once that is done correctly you should no longer be able to use "SecureImageDisplay.htm" to see your camera and the only way to see your camera should be by using "SecureImageDisplayLogin.php" when you have uncommented the reference to "RestrictToSecureImageDisplayLogin.php" in "SecureImageDisplay.php". Note: You can send me a PM ("Private Message") and I will give you my email address if you need more help or instructions. I don't want to take this Forum thread off topic. I simply wanted the original poster here to understand there are many methods one can use to do what they are trying to do. Don

In your case. It looks like the cameras URL may not be a scripting language URL. Meaning, it may not allow or support using parameters to be part of the URL. So. You want to change this line in SecureImageDisplay.php: $ipcam_url = "http://DDNSorISPIPAddress:PortForCamera/snapshot.cgi?&user=admin&pwd=YourPassword&cnt=".microtime(true); To be ("Using your example(s) above"): $ipcam_url = "http://admin:12345@IP:80/onvif/snapshot"; or $ipcam_url = "http://admin:12345@IP:80/Streaming/channels/1/picture"; I am assuming that you already have used the check included in SecureImageDisplay.php to determine the web servers current setup: 1. That php curl and GD methods are currently installed on this web server? 2. That the web server is currently allowing the port for your camera to be opened as an outbound port using php curl and GD methods? Also. You make no mention of what this "same error" is and has been showing? Don

Also. Here are secure methods to do this. That can also support allowing PTZ controls as well better bandwidth control: http://foscam.us/forum/showing-secure-methods-using-php-to-display-your-ip-cameras-t8721.html While the demonstrations above are using Foscam IP Camera models. They do work for any other IP Camera models or Imaging devices that support HTTP or HTTPS access methods. The methods allow any Internet browser capable device running on any Operating System and using any browser to be able to see your IP Camera. Without the need to download/install anything or be required to have specific media players installed on any device, to do so. Don

Depending on your needs? You could use methods like this using 1 line of HTML, per IP Camera/Imaging Device. If those devices support pulling snapshots from those devices using HTTP or HTTPS access methods. This can be done securely when using a web server or server to proxy the requests or insecurely without using any server. By accessing the IP Cameras/Imaging Devices directly from the HTML. The HTML can be stored on the device itself or a server or accessed from a Email attachment from any device. Methods like this, will use considerably less battery life and also much less CPU and memory resources on mobile devices. You also won't require quick access to a fire extinguisher, when viewing many different IP Cameras/Imaging Devices, at the same time. While this example uses Foscam IP Camera models for demonstration. It will work with any IP Camera/Imagining Device, that can supply snapshots as mentioned above. Here are 14 live IP Cameras at the same time. With the ability to also view and/or control ("If they support PTZ 'Pan/Tilt/Zoom'") any of the IP Cameras individually: http://107.170.59.150/foscam/FoscamUS.htm You can try the above demonstration, using any Internet browser capable devices of your choice. You can change the browser window size during the demonstration to stack the 14 IP Cameras differently if needed. The demonstration is using the secure method ("No information of any kind is exposed for any of the 14 IP Cameras"). There is no finite limit to how many IP Cameras can be shown at the same time. Images sizes and refresh rates on a per camera basis, can be changed as needed. Don

This is a pretty backhanded thing to say. IMO, knowing a password prefix makes any secure password no less secure. If anything, it makes it more secure to the uninitiated who don't know the prefix. And for those who DO know the prefix, and they know/cracked the admin password, then they would have probably gotten into the box eventually anyway. @hdo26 - I think he's trying to give you **** about divulging this prefix. Still not 100% sure why, though. Security through obscurity is not security. I, for one, would like to say thanks! IMHO. I think "iTuneDVR" gets upset because knowledge = lost sales. In other words he sells fixes/firmware that use this information. So, it's never a good idea to him to expose methods where you can do the same yourself for free. Which may also allow others to do the same. But, just a guess. Don

You do not understand the phrase. (don't increase fly to elephant) You just do not dramatize the situation and everything will be fine! Anyway. I am more then familiar on how to change firmware with many different devices. Including many different brands and models of IP Cameras that are Linux based firmware devices. Many people have been doing the same, for many decades. Myself included. So the potential risks I mention here, have nothing to do with drama, inflation or paranoia. They are based on my experience and the experiences of others I know and/or have worked with doing the same. I think you have a sellers bias in this, since you also sell a version of this. So I comprehend why some of the responses you injected here are phrased, as they are. Each individual IP Camera owner, can make an informed decision and decide on what's drama, inflation or paranoia and what's not. Note: Your websites copyright statement has a date of 2013 Don

Yes. I am aware that you also sell a version of this and because of that, there maybe some seller bias involved on your part. When it comes to mentioning addtional potential risks not already mentioned here. That said. Risk assessment is never a bad thing. So, no ("Inflation") going on here. Just mentioning some additional potential risks, that have been conveniently avoided being mentioned here. Each IP Camera owner can make their own informed decision. That's the way it should be. As I clearly stated here in my first post here. I have nothing against patching firmware. But some potential risks were not mentioned and after waiting for some time. I thought it was a good idea to bring them up, since those potential risks were not brought up in the past. Nothing more, nothing less. Don

Yes and at least now all the risk cards are "Face Up" on the table. Nothing wrong with that. That said. Can't see how that can/could be referred to as "Spears and Arrows". Because you also sell a version of this. I do understand your sensitivity on mentioning potential risks previously not mentioned here about this. Don

Hello. I apologize. I did not intend for this to go on, as it has. Yes. I understood that. My point about remaining current with firmware upgrades was/is about how important it would be to continue to stay current with future firmware changes when/if security vulnerabilities are found and published in the public domain, in whatever firmware release a IP Camera owner is running. Not to simply base their decision on if this were to happen, to stay on what firmware they have. Without understanding all the potential risks that come with that, by doing so. In other words. Many IP Camera owners may simply review firmware upgrade release notes and assume that because there is no mention about any security vulnerability fixes being included. That if they encounter firmware upgrade issues, while trying to install newer firmware upgrades. That they simply decide to stay on the firmware they have presently installed in their IP camera because, after all "Everything is working fine anyway". Yet there maybe methods in the public domain that show how or even have tools to exploit the firmware version they have currently installed in their IP Camera. Don

Yes. I am simply using Hikvision terminology. Which it would appear, they referrer to as "Unauthorized Distributors". Which is what I mean/meant by "Unauthorized Resellers". More here as one example: http://www.hikvision.com/en/us/UnauthorizedDistributors.asp So, to clarify. It's possible that if these "Distribution Partners" and/or others, were to place enough pressure on Hikvision. That could cause them as a manufacturer, to take some action on patched cameras: http://www.hikvision.com/en/us/distributionPartner-usa.asp?cid=17 Don

Hello, Yes my concerns are more that IP Camera owners be aware that the manufacturer could stop future firmware releases to be able to installed based on some check they implement on if they can tell if the IP Camera was patched. If I was a betting man. I am sure a check like this could be easily created by the manufacturer, if enough pressure was put on them by their authorized resellers. Whereas unpatched IP Camera might not have any firmware upgrade issues in the future, with that same firmware upgrade. FTP Server wise. I think it's important that IP Camera owners keep their ear to the ground about any security vulnerability that maybe found in the future since the FTP server at least at present is not being maintained, supported or dealt with for security fixes, since it was removed by the manufacturer. Because of this. Most likely, it's not a good idea to leave the FTP server enabled when not needed. If not for those reasons alone. I have no doubt your intentions are and were always good ones. I just wanted to make some points that for whatever reasons were never mentioned. Don

Some simple words of caution. First. I understand the issue. Someone buys a IP Camera and all the menus are in Chinese. They don't read and/or don't want Chinese menus for their IP Cameras control interface. Maybe they did it to save money, maybe they never understood their purchased IP Camera was set for the Chinese region. Regarding the initial patch I think it's more fair and honest to at least state that while the region change has nothing to do with a specific version of firmware or currently released versions of firmware that the manufacturer can at any time decide to change methods ("The region structure") using the magic word ("Potentially") causing issues in the future for people who have used the patch. The manufacturer could do this out of spite. Since most likely they have in their minds a logical reason for doing what they have, based on how the cameras region is initially set. Odds are good that the manufacturer will not allow this to continue, as in forever, while they get hammered by their authorized resellers who are losing sales in what normally would be IP Cameras sold in those English regions. So IMHO, it's at least important to admit, that it could become impossible to resolve whatever actions the manufacturer does quickly or in a timely manner. If and when that were to occur. The manufacturer could justify these actions to protect their authorized resellers with a clear conscious and no pangs of any guilt while doing so. Causing for example, newer firmware releases to NOT be able to be installed in patched IP Cameras, based on some method they create to determine if the camera was/is really from x region or not. Causing IP Camera owners with the patch, to NOT be able to upgrade to current and/or newer firmware releases until a workaround for this now new issue, was created. Which could happen anytime in the future. Which might be fine, unless/until some future firmware upgrade is required to protect a IP Camera from a security vulnerability, which is now in the public domain. Then IP Cameras with this patch would remain vulnerable until/unless another patch could be made to resolve this. Regarding not staying current with current or future firmware releases because of this or that IMHO. It's much better to continue to ("patch") current releases of firmware then to fallback to older versions. This is because many, if not most, IP Camera owners don't realize the potential risks involved when going backwards in firmware releases or even not installing current firmware releases. Which still won't save you from the above mentioned potential manufacturer situation, occurring sometime in the future or some known security vulnerability or soon to be found security vulnerability with the FTP server, that is no longer being modified for potential security vulnerabilities it may presently have. Since it no longer is supported, in current firmware versions by the manufacturer. In many, if not most cases. New firmware releases also include security vulnerability fixes. These fixes are not always documented or present, in the release notes. When you lag behind in doing firmware upgrades because of not wanting to lose specific features. You truly maybe unwillingly continuing to expose yourself to security vulnerabilities which are now fixed. As a IP Camera owner. It's important to realize that if whatever vulnerabilities that have been resolved in newer versions of firmware are not resolved in your IP Camera, that you are much more at risk to have the configuration data exploited in your IP Camera. Again ("Potentially") allowing others to gain access as some examples, to the user credentials of any Email or FTP users and their passwords which are currently stored in your IP Camera configuration. This is NOT speculation on my part. I have seen this happen many times with many different IP Camera Owners of many different IP Camera brands and models over the years. Personally, I am aware of IP Camera owners who have had this happen and some still are trying to recover from the damages of their Email and/or Web Servers accounts being taken over many months afterwards. Because they fell back to older firmware or stayed on specific firmware releases. Not realizing that their IP Cameras were exposed to security vulnerabilities, until it was too late. So. I am not wanting or wishing to rain on anyone's parade here. But I have waited and waited for many weeks for a true honest summary of the risks involved when implementing something like this. I agree that all IP Camera owners should be allowed to do what they wish with their IP Cameras. But, I also equally feel that those of us who create patches for others, also are obligated and need to be honest about ALL the potential risks involved, when implementing them. Not just ("Some of the risks"). I hope you can understand that. I wish you luck. I hope you find employment. Don

These are just a few reasons why if you are using HTTP access methods to access your IP Cameras to not access your IP Cameras directly, over unsecure Internet connections. Here are some methods you can use to use php on a web server or server to ("Act as a proxy") front-end access to your IP Cameras. That can be used from any Internet browser capable devices. Without plugins or any need to install software on any device. While the live examples shown below are using Foscam IP Camera models. It's very easy to implement and apply the same concepts and methods to any IP Camera brands and models that allow pulling snapshots using HTTP or HTTPS access methods. At least this allows you to not expose the DDNS, IP Address, Port and any User credentials for your IP Cameras: http://foscam.us/forum/showing-secure-methods-using-php-to-display-your-ip-cameras-t8721.html Note: The methods shown above are not meant to be your only solution to accessing your IP Cameras. They are simply another tool for the toolbox for your IP Cameras. That can be used when and as needed. After all, do you only have one type and size of screwdriver in your toolbox of tools? Why should tools for IP Cameras be any different? Especially more so, when they are free. Also. I suggest, if your IP Camera supports HTTPS access methods. I would only port forward the HTTPS port for the IP Camera and not the HTTP port for the IP Camera, for remote access. That said. If someone was sniffing packets, they could still see what DDNS/IP Address and port was being accessed, even when using HTTPS access methods. In the cases mentioned here, allowing them to still be able to access your cameras snapshots and/or video feed. So the php proxy solution above, is a much more secure access method, when using unsecure Internet connections. There is also, a free tool at the link above, that will allow you to easily see what information is exposed when communicating with your IP Cameras when using HTTP and HTTPS access methods. You may be or become very surprised what's normally being exposed, that could and can be sniffed by others, as you access your IP Cameras. This is most certainly a case of "What you can't see CAN hurt you!". Don

Worse case you can use methods and concepts like this. If your IP Cameras have the ability to pull snapshots from the IP Cameras, using a HTTP or HTTPS URL. While the live demonstrations use Foscam IP Cameras as their examples. The many different methods shown and used below, can be done for any IP Camera. To be able to view those IP Cameras together or individually, from any Internet browser capable device. Without the need to install any plugins or special software, to do so. More here: http://foscam.us/forum/showing-secure-methods-using-php-to-display-your-ip-cameras-t8721.html Note: The above methods can also be very helpful when you have different IP Camera brands and/or models that you wish to view together at the same time. There are both totally secure and unsecure methods with live examples shown above. Depending on how fancy you want to get. It's also possible to use IP Camera controls and/or change camera configuration settings, again without the need to install any plugins or additional software on the device, being used to view the IP Cameras. Any device viewing the IP Cameras, simply needs to be a Internet browser capable device. Don

There are many other free methods which include being more secure ("Not exposing any DDNS/IP Address, Port or User credentials for the IP Camera in the webpage. Which could be abused by others") and being able to better throttle bandwidth. It's also easy to do this using one line of HTML as well. Here are live working demos and many different live working examples. That show many different ways, to go about this. In real-time: http://foscam.us/forum/showing-secure-methods-using-php-to-display-your-ip-cameras-t8721.html#p42139 Notes: While all the working live example demos above, are using Foscam IP Cameras. Most of the methods shown above, can by used with any IP Camera or imaging device that allows pulling snapshots using HTTP or HTTPS access methods. What's also important is that none of these methods require anyone viewing your webpage using any Internet browser capable device to download/install anything and that any Internet browser capable device visiting your webpage, will be able to always see your IP Camera. Instantly. Most IP Cameras have a finite number of ("Long-Term such as video or formally logged in") concurrent connection limit. Depending on the IP Camera brand and model. This limit can be as low as a maximum of (4). So if you go full-motion video and your website is busy. You may need to use some type of video streaming service which uses one connection to your IP Camera and does the broadcasting of your IP Camera to your website visitors. As already stated here. In many cases that's not free when you need to support x concurrent viewers or the bandwidth exceeds a limit. If you provide the full-motion video streaming yourself. You may also need to take into consideration your ISP upload bandwidth and any bandwidth per month limitations or additional charges when those limits are exceeded that the ISP where your IP Camera is located, may have. Even if you configure and operate your own video streaming server. From the IP Camera location and/or a web server, depending on the bandwidth the IP Camera will use. If the IP Camera provides the full-motion video directly to your website visitors. It's unlikely that any of them will have a pleasant experience when 5+ website visitors are attempting to view the IP Cameras full-motion video at the same time. Even if the ISP at the IP Cameras location can support the bandwidth for those website visitors attempting to view the IP Cameras full-motion video simultaneously. Because IP Cameras generally use ARM based CPU's with limited horsepower and limited internal memory for buffering, that can become overtasked easily. When IP Cameras are pushed beyond their normal limits. I have a saying that sometimes offends IP Camera owners. But it's no less false because of that. Displaying full-motion video from a IP Camera on a websites webpage, can be like "Watching paint dry at 15-30 FPS ("Frames Per Second")". But more expensive to you, as others do just that. Unless your IP Camera is viewing interesting activity 24/7/365? Then it may not be worth any added or additional cost required to stream full-motion video. When there are other free methods you can use instead. Last, but far from least. Virtually any device directly exposed to the Internet, will have vulnerabilities found and exposed at some point during their lifetime. In the case of IP Cameras, this can be more dangerous than some other devices. Especially, if your IP Camera configuration data for example contains Email and/or FTP User and Password credentials. Because if someone due to a vulnerability, now or in the future, gains access to that information. Then someone ("Owns") you, not just your IP Camera. Potentially, causing you much unneeded stress for many days, weeks, months or longer to recover from that resulting abuse. Because of this. IMHO. Exposing nothing in a webpage about the location or User credentials of your IP Camera is best practice. To do otherwise, is inviting trouble with open arms. From multiple sources worldwide. Your IP Camera becomes a worldwide test bed and playground for others that have too much free time on their hands and it's always open for use and abuse 24/7/365. Catering to any and all time zones. Don