Category: security

Network Access Control

Steel mountain Data centre- protected by Network ACLs

ACL controls what can establish a TCP/IP socket connection to specific ports which means ACLS control what services you can get to on a network

ACL Nut

ACLS have a mask which determines what gets passed and what gets dropped

They use an inverse mask , an example of this is 0.0.0.255 , where ever there is a 0 you must consider the network address wherever there is a 1 you can ignore it so the inverse of a normal mask

for example if you got an ACL that looks like this

10.1.1.0 0.0.0.255

the network address to be processed is 10.1.1.0 in binary is

00001010 .00000001.00000001.00000000

and the mask in binary is

00000000.00000000.00000000.11111111

  • 0 indicates that the network address must be considered (exact match)
  • 1 in the mask is a don’t care

10.1.1.”we don’t care what’s in this last octet since here it is all ones “so the address we process starts with 10.1.1.1 and stops with 10.1.1.255

you can subtract the normal mask from 255.255.255.255 to get the inverse mask

255.255.255.255-255.255.255.0 = 0.0.0.255

ACL cuts

source 0.0.0.0 / wildcard 255.255.255.255 means “any ” how so ?? because basically we are flying all 1’s against 0.0.0.0 it can be any value between 0 and 255 so that’s pretty much everything

if we got a source/wildcard 10.1.1.2/0.0.0.0 that means we got to match exactly in every position so that means the same as host 10.1.1.2

192.168.32.0/24 (192.168.32.0 – 192.168.32.255)

192.168.33.0/24 (192.168.33.0-192.168.33.255)

192.168.34.0/24 you get the idea

192.168.35.0/24

192.168.36.0/24

192.168.37.0/24

192.168.38.0/24

192.168.39.0/24

in these addresses the first two octets and the last octet is the same for each of these networks

Decimal1286432168421
3200100000
3300100001
3400100010
3500100011
3600100100
3700100101
3800100110
3900100111
The first five bits match that is to say there is no differences in these columns

This means that those 8 original networks can be summarized as one

If you look at the anatomy of a network acl or NACL it looks a bit like this

access-list 10 permit 192.168.146.0 0.0.1.255

this permits traffic from 192.168.146.0 – 192.168.147.254

access-list 11 permit 192.168.148.0 0.0.1.255

this permits traffic from 192.168.148.0-192.168.149.254

How ACLS are processed

Traffic that comes into a router via an interface is compared to the ACL entries based on the order that they have been configured in , so they run from the top ACL statements to the last ACL statement of an access-list

new statements are added to the end of the list

The router will process network traffic until it gets to the end of the list , this traffic would be denied ( since no match in the configured ACL)

“There is an implied deny for traffic that is not permitted”

for this reason you should have the frequently hit entries at the top of the list

A single ACL entry with only 1 deny has the effect of denying all traffic , you must have at least one permit statement

these two ACLS have the same effect

access-list 101 permit ip 10.1.1.0 0.0.0.255 172.16.1.0 0.0.0.255

!--- This command is used to permit IP traffic from 10.1.1.0 !--- network to 172.16.1.0 network. All packets with a source !--- address not in this range will be rejected.

access-list 102 permit ip 10.1.1.0 0.0.0.255 172.16.1.0 0.0.0.255

access-list 102 deny ip any any

!--- This command is used to permit IP traffic from 10.1.1.0 !--- network to 172.16.1.0 network. All packets with a source !--- address not in this range will be rejected.

In this example, the last entry is sufficient. You do not need the first three entries because TCP includes Telnet, and IP includes TCP, User Datagram Protocol (UDP), and Internet Control Message Protocol (ICMP).


!--- This command is used to permit Telnet traffic !--- from machine 10.1.1.2 to machine 172.16.1.1.

access-list 101 permit tcp host 10.1.1.2 host 172.16.1.1 eq telnet


!--- This command is used to permit tcp traffic from !--- 10.1.1.2 host machine to 172.16.1.1 host machine.

access-list 101 permit tcp host 10.1.1.2 host 172.16.1.1


!--- This command is used to permit udp traffic from !--- 10.1.1.2 host machine to 172.16.1.1 host machine.

access-list 101 permit udp host 10.1.1.2 host 172.16.1.1


!--- This command is used to permit ip traffic from !--- 10.1.1.0 network to 172.16.1.10 network.

access-list 101 permit ip 10.1.1.0 0.0.0.255 172.16.1.0 0.0.0.255

you can use ports and traffic types in ACLS , which is where we can control what the IP networks can access so for example

access-list 102 permit ICMP host 10.1.1.1 host 172.16.1.1 14

becomes

access-list 102 permit ICMP host 10.1.1.1 host 172.16.1.1 Timestamp-Reply

Where to place ACL’s

It is a good practice to apply the ACL on the interface closest to the source of the traffic. As shown in this example, when you try to block traffic from source to destination, you can apply an inbound ACL to E0 on router A instead of an outbound list to E1 on router C. An access-list has a deny ip any any implicitly at the end of any access-list.

DHCP and ACL’s

If traffic is related to a DHCP request and if it is not explicitly permitted, the traffic is dropped because when you look at DHCP request in IP, the source address is s=0.0.0.0 (Ethernet1/0), d=255.255.255.255, len 604, rcvd 2 UDP src=68, dst=67.

Note that the source IP address is 0.0.0.0 and destination address is 255.255.255.255. Source port is 68 and destination 67. Hence,

you should permit this kind of traffic in your access-list else the traffic is dropped due to implicit deny at the end of the statement.

The motor way analogy

Traffic on a IP network is a bit like traffic on a road network and much like those meanings where you get inbound and outbound in response to road blocks for example the same sorts of meanings occur

  • Out—Traffic that has already been through the router and leaves the interface. The source is where it has been, on the other side of the router, and the destination is where it goes.
  • In—Traffic that arrives on the interface and then goes through the router. The source is where it has been and the destination is where it goes, on the other side of the router.
  • Inbound —If the access list is inbound, when the router receives a packet, the Cisco IOS software checks the criteria statements of the access list for a match. If the packet is permitted, the software continues to process the packet. If the packet is denied, the software discards the packet.
  • Outbound—If the access list is outbound, after the software receives and routes a packet to the outbound interface, the software checks the criteria statements of the access list for a match. If the packet is permitted, the software transmits the packet. If the packet is denied, the software discards the packet.

EDITING ACL’s

so this is in bold because there are some rules here that i was not aware and i have fallen foul of

rule 1 – when you edit an ACL entry and delete a specific line from an ACL the whole ACL is deleted

so whenever you are working with an ACL you should take the trouble to make a note of what was there in the first place make the change you need in the editor and then re-apply it

rule 2 – if you are working with a numbered ACL list , if in your edit you attach a number than it will find its place in the ACL

DEBUGGING ACL’s

Use the debug ip packet 101 or debug ip packet 101 detail command in order to begin the debug process.

ACL types

standard;

This is the command syntax format of a standard ACL.

access-list access-list-number {permit|deny} 
{host|source source-wildcard|any}

FS cheat sheet

 

 

Free switch (fs) is basically open source software defined technology stack that supports the following endpoints and is a class 5 soft switch , IVR platform and high quality conference resource and supports principally SIP but also Google talk and Skype

 

Module Types FS

The following modules comprise the FS IP PBX

  • Endpoint for talking to VOIP , PSTN , Google Talk , Skype etc
  • Application  there are hundreds of application modules for conferencing , voicemail , IVR that are contained in the tools module
  • Dialplan responsible for routing calls based on call context information such as caller ID , the default dialplan module is in the XML dialplan
  • Directory provides logins and configurations that users can register with FS
  • Codecs that are used for the encoding of media streams
  • File Formats play audio files whose common common formats are supported by the sndfiles module which is included by default
  • Loggers records log messages such as log file.xml_cdr
  • Languages languages that are supported for scripting javascript is supported

 

Configuration files in FS

All configuration files are written in XML the default configuration that comes with the virtual machine is located in /etc/freeswitch

One of the first differences that is evident between Cisco unified call manager and FS is that FS has inbuilt support for SMS  under the chatplan whereas in the Cisco framework you would have to provision load of middle ware and somewhere would be a node.js app but thats a story for another day

How to register Yealink T21 to FS

Head over to the default directory it will look like this one below , these are all the extensions in the default context which is like the CUCM internal partition

root@freeswitch-vm:/etc/freeswitch/directory/default#
root@freeswitch-vm:/etc/freeswitch/directory/default# ls
1000.xml 1002.xml 1004.xml 1006.xml 1008.xml 1010.xml 1012.xml 1014.xml 1016.xml 1018.xml brian.xml example.com.xml
1001.xml 1003.xml 1005.xml 1007.xml 1009.xml 1011.xml 1013.xml 1015.xml 1017.xml 1019.xml default.xml skinny-example.xml
root@freeswitch-vm:/etc/freeswitch/directory/default#

lets say we want to register under 1yealink_2nd_account

so nano 1000.xml and make the config line up with above xml

so it looks like this

<user id=”1000″>
<params>
<param name=”1000″ value=”$${default_password}”/>    (we set this in the yealink)
<param name=”vm-password” value=”1000″/>
</params>
<variables>
<variable name=”toll_allow” value=”domestic,international,local”/>
<variable name=”accountcode” value=”1000″/>
<variable name=”user_context” value=”default”/>
<variable name=”effective_caller_id_name” value=”Extension 1000″/>
<variable name=”effective_caller_id_number” value=”1000″/>
<variable name=”outbound_caller_id_name” value=”$${outbound_caller_name}”/>
<variable name=”outbound_caller_id_number” value=”$${outbound_caller_id}”/>
<variable name=”callgroup” value=”techsupport”/>
</variables>
</user>
</include>

but will end up like this
<include>
<user id=”1000″>
<params>
<param name=”1000″ value=”1000″/>
<param name=”vm-password” value=”1000″/>
</params>
<variables>
<variable name=”toll_allow” value=”domestic,international,local”/>
<variable name=”accountcode” value=”1000″/>
<variable name=”user_context” value=”default”/>
<variable name=”effective_caller_id_name” value=”Extension 1000″/>
<variable name=”effective_caller_id_number” value=”1000″/>
<variable name=”outbound_caller_id_name” value=”$${outbound_caller_name}”$
<variable name=”outbound_caller_id_number” value=”$${outbound_caller_id}”$
<variable name=”callgroup” value=”techsupport”/>
</variables>
</user>
</include>

 

then it will register to the fs

regsitered yealink

The most important concept in FS is ………

the basic construct is a dialplan which is simply a list of actions which is controlled by the digits dialled , a dialplan can be broken into contexts where each context is a group of extensions , each of which contains specific actions can be performed on the call

the dialplan processor uses regular expressions which is a pattern matching system to determine which extensions and actions to execute

<extension name=”example”>

<condition field= “destination_number” expression =”^(10\d\d\)$”>

<action application =”log” data=”INFO dialed number is [$1]”/>

 

This captures the digits dialed and matches them against 10\d\d so this is a range 1000 to 1099 , so if a user dials 1050 this would execute the application called log and print out the digits dialed to the screen , the value $1 would be interpolated or expanded

FS has 3 main contexts

  • default
  • public
  • features

The default context

This can be though of as the internal as it services users who are directly connected to FS

There are some typical PABX type extensions contained within conf/dialplan/default.xml the local extension does many things

  • routes calls between internal users
  • sends calls to the destination users voicemail  on a no answer condition
  • enables in call features with bind_meta_app
  • updates the local calls data base

 

The local extension 

<extension name=”Local_Extension”>
<condition field=”destination_number” expression=”^(10[01][0-9])$”>
<action application=”export” data=”dialed_extension=$1″/>
<!– bind_meta_app can have these args <key> [a|b|ab] [a|b|o|s] <app> –>
<action application=”bind_meta_app” data=”1 b s execute_extension::dx XML features”/>
<action application=”bind_meta_app” data=”2 b s record_session::$${recordings_dir}/${caller_id_number}.${strftime(%Y-%m-%d-%H-%M-%S)}.wav”/>
<action application=”bind_meta_app” data=”3 b s execute_extension::cf XML features”/>
<action application=”bind_meta_app” data=”4 b s execute_extension::att_xfer XML features”/>
<action application=”set” data=”ringback=${us-ring}”/>
<action application=”set” data=”transfer_ringback=$${hold_music}”/>
<action application=”set” data=”call_timeout=30″/>
<!– <action application=”set” data=”sip_exclude_contact=${network_addr}”/> –>
<action application=”set” data=”hangup_after_bridge=true”/>
<!–<action application=”set” data=”continue_on_fail=NORMAL_TEMPORARY_FAILURE,USER_BUSY,NO_ANSWER,TIMEOUT,NO_ROUTE_DESTINATION”/> –>
<action application=”set” data=”continue_on_fail=true”/>
<action application=”hash” data=”insert/${domain_name}-call_return/${dialed_extension}/${caller_id_number}”/>
<action application=”hash” data=”insert/${domain_name}-last_dial_ext/${dialed_extension}/${uuid}”/>
<action application=”set” data=”called_party_callgroup=${user_data(${dialed_extension}@${domain_name} var callgroup)}”/>
<action application=”hash” data=”insert/${domain_name}-last_dial_ext/${called_party_callgroup}/${uuid}”/>
<action application=”hash” data=”insert/${domain_name}-last_dial_ext/global/${uuid}”/>
<!–<action application=”export” data=”nolocal:rtp_secure_media=${user_data(${dialed_extension}@${domain_name} var rtp_secure_media)}”/>–>
<action application=”hash” data=”insert/${domain_name}-last_dial/${called_party_callgroup}/${uuid}”/>
<action application=”bridge” data=”user/${dialed_extension}@${domain_name}”/>
<action application=”answer”/>
<action application=”sleep” data=”1000″/>
<action application=”bridge” data=”loopback/app=voicemail:default ${domain_name} ${dialed_extension}”/>
</condition>
</extension>

<extension name=”Local_Extension_Skinny”>
<condition field=”destination_number” expression=”^(11[01][0-9])$”>
<action application=”set” data=”dialed_extension=$1″/>
<action application=”export” data=”dialed_extension=$1″/>
<action application=”set” data=”call_timeout=30″/>
<action application=”set” data=”hangup_after_bridge=true”/>
<action application=”set” data=”continue_on_fail=true”/>
<action application=”bridge” data=”skinny/internal/${destination_number}”/>
<action application=”answer”/>
<action application=”sleep” data=”1000″/>
<action application=”bridge” data=”loopback/app=voicemail:default ${domain_name} ${dialed_extension}”/>
</condition>
</extension>