Monday, September 29, 2014

A SIP Request Header gotchas

Debugging some sip stuff this last few weeks,  I ran into something that  was a little strange & that I would like to share with you.

My Wiresahrk/Tshark tool was not decoding a sip.request correctly , but  it was due to the upstream SBC was sending a badly format Request & Method field in the header to begin with. So decoding  SIP packets, was reporting some requests as "unknown". In this is case it was a Sip Request OPTIONS.


NOTE: E.g all "Methods" should be uppercase from what I compared to other captured Sip Request

"INVITE"   vrs  "invite",   "BYE"  vrs "bye", "CANCEL" vrs "cancel"

And the same for the Request-Line. ( Request-Line: OPTIONS )

Here's a few snapshot of the header and Methods;

( correct )




( incorrect )




The RFC3261 did not give to much details on the character set & with regards to upper & lower case,  but this is a summary;

http://tools.ietf.org/html/rfc3261#section-7.1

but RFC2543

https://www.ietf.org/rfc/rfc2543.txt



note: In all internet examples, the  Request are always shown in  UPPERCASE  ( INVITE, ACK, BYE, etc... ) In all of my previous trace and pcaps analyzed,  this seemed to held true. 

So keep that in mind when inspecting SIP datagrams and/or decoding sip  datagrams. If wireshark flags these requests as unknown, than a deep inspection of the  header should take place.

The SBC in question Sonus 5100 was still replying with a  status 200 OK . So a tight inspection of the header format was not taking place or it didn't care about the case-sensitivity. The sending SBC is  supposedly  a Acme SBC btw.

I checked a few other SIP devices and they are seems to deploy the Requests in upper case. Even my  x-lite client sends all requests in uppercase.


I hope this helps others who are scratching there heads, & wondering why the sip request are reported as unknown.

Ken Felix
NSE ( network security expert) and Route/Switching Engineer
kfelix  --- a----t ---- socpuppets --- dot --- com

     ^      ^
=(  X   X )=
         o 
        /  \

Sunday, September 28, 2014

Cisco DOM and transceiver matrix

Cisco  DOM supported transceiver listing, the following list give great details on 1/10gig transceivers that support diagnostic optical monitoring.
 
http://www.cisco.com/c/en/us/td/docs/interfaces_modules/transceiver_modules/compatibility/matrix/OL_8031.html

This is a one big single reason why it's best to stick with cisco branded optical transceivers.


Ken Felix
NSE ( network security expert) and Route/Switching Engineer
kfelix  -----a----t---- socpuppets ---dot---com
   ^      ^
=(  $  $ )=
       o 
      /  \

Saturday, September 27, 2014

Three IOS-xr commands that could be useful

Here's 2 IOS-XR command that could come in handy.

1:

How many times have you had a card hangup in a ASR chassis? Will instead of sending somebody to pull or reset the card, just do a reload.

The hw-admin from admin mode will allow you to reload the slot that specified. On CRS you have the option to power off the slot

e.g


note: you can monitor the status using "show platform"

2:

IOS-XR let's you compute  md5  hash for files. It's similar to  IOS  and the /verify


3:

When doing package upgrades and you want to  test the outcome before activate a new build, the activate command with test  option will display the outcome.


Ken Felix
NSE ( network security expert) and Route/Switching Engineer
kfelix  -----a----t---- socpuppets ---dot---com
   ^      ^
=(  *  * )=
       o 
      /  \

Fortigate Best Comon Practices

In  this post we will look at fortinet own published bcp document.






http://docs.fortinet.com/uploaded/files/1954/Best_Practices_52.pdf

At the time of this post Aug-6-2014 is the most updated. It's a very well written doc that commons normal to advance  subjects  from;
  •  management 
  •  firewall policies
  •  vdom
  •  vpn
  •  advance routing 
One of the most common detail missed suggestions  for  HA &  VPN that I would like to highlight;

"Use a non-NPU interface for at least one heartbeat interface to rule out potential NPU"


issues."
"Add blackhole routes for subnets reachable using VPN tunnels. This ensures that if a VPN tunnel goes down, traffic is not mistakingly routed to the Internet unencrypted"

 NOTE: always try to use a lower performing port for HA operations.




Firmware updates are most, so stay up to date & so you an take advantage of new features. I always try to obtain a copy of original software that I'm running b4 any firmware updates in case I need to format the flash.

Perform routine backups b4 any major changes, updates or firewall resets.
 
Try to avoid "any" in firewpolicies for interfaces or services unless that what you intended.


Review the fortinet bcp document and use what's applicable in your design & operations.

Ken Felix
NSE ( network security expert) and Route/Switching Engineer
kfelix  -----a----t---- socpuppets ---dot---com
     ^      ^
=(  @  @ )=
         o 
        /  \

Thursday, September 18, 2014

Controlling fragments across a cisco ASA interfaces

Fragments are not good and could be downright bad if your doing packet inspection and recovery.

The reasons for the bad, there's no L4 header information in any succeeding  fragments. IPS/FIREWALL and  DoS detection gear can freak out and drop these. With UDP and ICMP large payload data is used in a lot for attacks.

note: Some gear will complain and drop flows upon re-assembly if the payload is just flat to big

Ping-of-Death ( aka PoD ) and Smurf took advantage of the typical os stack that allowed large packets and with PoD, windows was greatly effected and could crash.

In this post, we will look at a simple means for eliminating any fragments across interfaces.

1st let's look at the default fragments settings;


Okay the size = 200 chain = 24 and timeout = 5


Okay what this really means, 24 packets of  fragment can be allow and we allow for a total of 200 packets to be buffer for reassembly. The timeout value of 5sec  simpliy means we allow for 5secs for the fragments to be received, just encase some are slow getting back.

note: You might be able to use scappy to craft large packets and delay transmission for testing the delay
http://www.secdev.org/projects/scapy/

Okay let's look at how you drop all fragments across interfaces. Most will try to do something similar to the following;
But as you can see, the size can not less than the chain limit ( default = 24 )

So here's a means for dis-allowing fragments over all interfaces

config t
     fragment  chain 1
    fragment  size 1

end

Now let see a large icmp-ping and what happens when we block fragments ( 6k byte ping )


So when we dis-allow the  fragments, the  ASA drops these fragments. You can use the  show fragment command to get an ideal of fragments statistics.

( example  from a 8kbyte packet size  1 ping )




Ken Felix
NSE ( network security expert) and Route/Switching Engineer
kfelix  -----a----t---- socpuppets ---dot---com
   ^      ^
=(  $  $ )=
       o 
      /  \

Wednesday, September 17, 2014

Howto: quickly generate 8K bit PGP keys ( GNUgpg )

Crafting  large keys on with GNUpgp could become problematic. It Definitely  requires more time

Here's a few means for crafting " random bytes" to speed up your PGP key generation. Smaller  PGP keys can be create in under 10-30secs on a modern PC, but  larger than 4Kb bits could take a considerable amount of time. It's not abnormal to see PGP keys that needs 4-10mins just for creation.


method#1:

A shell loop;


B=0

while [ $B -lt 10 ] ; do ls -lR ; done 

NOTE:  run the above in a  about 3 or more terminal windows on the same host


method#2:

Using unix "dd" command
;


dd if=/dev/random of=/dev/null bs=1k

method#3:

Using unix command find and find junk or random stuff.

A=0

while [ $A -lt 10 ] ; do find / -name " `echo $RANDOM`"  ; done



Now sit back, and drink a cup of cafe.


A  MacBook Air  w/1.3 Ghz I5  took approx 10mins to create a 8192bit pgp key where as a 1024bit key took less than 10secs.



Ken Felix
NSE ( network security expert) and Route/Switching Engineer
kfelix  -----a----t---- socpuppets ---dot---com

     ^      ^
=(  @  @ )=
         o 
        /  \

My nextgenfw has new keys published

GNUpgp was used for publishing and creating new keys.












My access to the key-server was down due to a firewall policy


So now you can find next generation firewall public PGP keys for kfelix.

cli using gpg;


Querying a public key-server;

http://pgp.rediris.es:11371/pks/lookup?search=nextgenfw&op=index



Ken Felix
NSE ( network security expert) and Route/Switching Engineer
kfelix  -----a----t---- socpuppets ---dot---com
   ^      ^
=(  $  $ )=
       o 
      /  \

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: SKS 1.1.3

mQINBFQZXSMBEAC+Dmjld4oFdsXAxYcvWcPCa0bko4V5/7P64wwGx+a4cm9Y/dpJeUkvRTdB
sfLuwwZI31umJ8YZutxFuFS5v9jBDZ8m+F4BSf2w1f8dGzU2bISucoD7QpNan60HJTvF96Tq
3pd7DNwZUActEjDwHuHT3VbpKnRozW5jV6tX+7pQcax2Hex4XBY5Hq1cGLf+j4TZLx7id7ax
TlPJ92jTEyNP/vcoLfzx/dC0X3cMyr3iq8vFLo19lVxH5ackJAQGKJn7Rts8T3jx/waSs0en
kWUHD2Op7PBVdKlTfJEgjCT/Qr2DT2UVhnxqepHqXtAyQ9PDeXCcns1G/7tSwxU3XxjqBKGo
HoI8a7VVI0rddRkbVchso5HUcKKY02nj8PL5qwfyMobI+Yu3C4SbNmoe0W0fQFdefVxU3N5L
44l4g4yWFsgcEKTRWsbJnE2E/vyNyQxNHEdsvDt016qZfKNMP4Q0VoyGb6cB8mjPZEgsSX4w
K59NZJKSCvc7w+E7LlH+scRuPmnuk5OOfOvHF0oHbFWG9RavOep0kItsIzqv2ypQ2kDA2Ui0
U1FfwHm4uJ9ZAQAGtVUHaGiCC+tciDChXYY2rE9BZaXuPIzPHsiz6V8t+NmBUabH2MTCB11p
ITZQ7nyK0R3WYWrJXYcYS8r8VljY4ufc++yLGfDpn8Fo8b9MjQARAQABtD9LZW5uZXRoIEZl
bGl4IChuZXh0IGdlbmVyYXRpb24gZmlyZXdhbGwpIDxrZmVsaXhAbmV4dGdlbmZ3LmNvbT6J
Aj0EEwEKACcFAlQZXSMCGwMFCQeGH4AFCwkIBwMFFQoJCAsFFgIDAQACHgECF4AACgkQLDxS
NEbLMma5Tw/9HOvl/xtdZ9WfHTjyeKt66dBGGXPLDrjY2KmznEFGcCe8NQTJ8+BtGs3My7E0
MkHD4/1J2wiLhQecIlVzybCIMee/lPLyoXVWXj5MCvUsmZH+XW8asDdI0w6e/6l2dOesROY5
6wUy+9dYvQq+M3vxiZ9HRsKgCOdTfR2sUK02X5tBvBVKLPpBuncTJSNTCRf/tEsw4SoDEgji
jkxlKdnT8JMfKa7sfhfG2j/wnGH3ffvkZMPPpXtIWql8shVfUHxQ3K3xZ/vqNkc2Lj/eVDQA
MiiKRaOBpWwwhqynLiqOqS3uEQz7h909zWa/E/GUNDeb+czh4QikEcemDT1eK/EJ9HPtfeNt
b++EBYTTob1m+3ct47Yv+56CdKS1YR0yMzqME1fc0yYlQ859DAlbKzcJ2dgLOIjlievpgpCV
x8/q7l4C+pM5DLw7NxOZyB7ZmbKzV4tQ3POKug4pDwRmm/xyg3pxwv0qKdceP0hCAhE+RWay
U0LG49hrCk0Rt9YjpIu0Is5At/2ypl2cgr5mu5UMIzAne2+DkZ0ZvbbSF+CBZUCcSgffZWlF
H7dhRV1z/V7twYcpyiBSdhnFR9jlFrsWaf7dtMeOkTUExmDx47HoCcUxTuChSf7VBU/ul/gX
uiTLAldjJBjdngEIWEbLbwBpqXa4EJH4IV6zA06qkNkWBTG5Ag0EVBldIwEQANy7S3xqEz1k
j6WRSG3BMul9gkFfCM7fHL9sj6S5IUr5u2F5AJyo9JQU55Td/DgMXnXGjI+fGLVjpeyHcF3k
1R/O4CLfrkjtIQADM+DBNPUjH1BsR5Yw/SC7rbmQVgTmH54mcUdEzFWUQlUKh0X+CCxW0uk8
t+K0AyBe5wFjk3iHTDQnLRaldrbaaOLHPwaGDGY1OM0edJc1n9dzpGlVB4aSQYobJPG30Goz
FJtPEJHiryCWhLuhNteL5qcrWdmRzibHZI6NxAao49S5PdQcbxPdQ3zbj7EptAeFSyqeXnVJ
XTZOuoXpv2qAORPBHxeuzTT4INOYpGZG/Xz2y778R0xhuINGD9WZI1xzMY7RwNHYExR7KnWL
HxT+vw826AKLX2t/RgAoY9NLgAfbFkxyu+Iewi6yqb5FW7KSAuNproR2anMjR7Zq64tIdRkI
UhsRJn0C50KB1epaG2zCiXzsnwEhAbiFMObaL8RURfJwQH3+QRdS4cl6K8gmMN9fcevv4Rra
G7zi93MgC6dahcTOBuESR+HicUmDs8nN5Gm1wOEVSvAx8FuK2MrzaKeB856OeZLg+WtgucN2
lgrXCHsf5Pd+z+gteWKhThAKgcZykEgumxVIHJTq5W33/CwEuMSHdepuUn5IAxJQM/7MRQQp
5JVZoRl9ipHnnZA/AQ1j6XQ5ABEBAAGJAiUEGAEKAA8FAlQZXSMCGwwFCQeGH4AACgkQLDxS
NEbLMmYdeRAAqPHg3VpcqODeTGpn9K8eVkPGR5Py4yhepjqH9UMSxTQ9iJuTSj7R+vBp5rY7
q+1f7bgD7GAQk3qYIVQFFjFwdwqe4oOxxOVfHgDW/VNaW9LD6LZvEw42bfcXgu1sk0Isf7CP
uM5TVpDrkfgmCB5OyGBO3ZLbZHP0W16SQNcyfJjYecld+LNm2VqMd3fd/3g+R1PfHnd+SksX
pG5Halpvf6GUU54WK1a36f3cAzmlMnpk1kpyal4023KsXg6ZPq77VxnT0NmCschFM+WFN4Qd
EFi7TqKFsmMKMnqaNoRuIvY/guoYi+sByGazMKJS6o8cSrHihos5z899PfQlDWJOzKXwmz40
6x+eNR3uJo3s7u2nTh2fgK6Y+aOogYWI6wMV5KOHEjFTt5zcknD77HyzOVOEmeJMKK6hzFZJ
w/KEEKcdVtH5D0aeObE+S4gQucNQTQyOIKisJXBiP4AxdTXfDXCwGK/h8b2ZCCv2h/iYsx/L
uPhDiL8fFA571j+vzJr5Bn6Gv6hd+3So37qBXKktb2t90MPpUEE5OmS3ztTDzuDT7pDgRuUK
2xobNpoGTRx+RDX+PI/TCGN5WOiQ0yEZAKqe3JzdIgvMnGJA+S9wkAFr2RzhPC90PJbkZV4B
MWp6pKQQ2Fbni5Tw5gh6YeGhx13+pYuxYYV4OT3S40jvknc=
=1q6+
-----END PGP PUBLIC KEY BLOCK-----

Monday, September 15, 2014

5.2.1 b618 is out

Fortinet finally  released the  long awaited 5.2.1 which should fixes alot of problems that was discovered.

 While reading thru the notes.

NOTE: There was like over 60+ resolved issues in this new codes which is Unbelievabl to say the least 






 
With any upgrades should always read the release notes & make a backup of the cfg b4 the upgrade proceeds.









 Next, hang on and cross your fingers :)








So we can only hope the problems are fixed and  wait to see what new problems develops. As with any  code release we should expect problems. This is part of the  life with software.




Ken Felix
NSE ( Network Security Expert) and Route/Switching Engineer
kfelix  -----a----t---- socpuppets ---dot---com
     ^      ^
=(  @  @ )=
         o 
        /  \

802.1ad interfaces IOS-XR

In this post we will look at a simple QinQ tagged (  ether.type == 88a8 interface ) on ASR IOS-XR.

QinQ has been a favorite with ServiceProviders for at least a decade now. It's becoming a more and more available function & within the SP and Enterprise communities and routers and with a few firewalls.

Here's a simple QinQ interfaces running on a IOS-XR ASR9010

1st the  interface cfg;
( very simple we define the outer-tag aka client-vlanid and the inner-tag  )
  • outer vlan = 33
  • inner vlan = 1000

note: yes,  this is very simple to configure


And here's a dump of an ARP  packet from that interface;





note: notice the frame.type = 0x88a8 which is the default for QinQ tagged


QinQ tagging has also been called;
  •    dot1q-tunneling
  •    double-tagging
  •    stacked vlans
  •    IEEE 802.1ad
  •    0x88a8 frame-type
  •    provider bridging

Having the ability to terminate 802.1ad natively on a interface allows for greater and simplex operations. Take the following example of a MetroE SP gateway device.


Each of these 4 routers are using the same customer-vlan id#33 and have subinterface that carries via 802.1q a unique vlan id between the pair. From a service provider perspective =, vlans 999/1000 are not seen within it's vlan topology. QnQ reduce the name to carry cliest vlanids, reduce the number of STP instance, and allows for various customers to carry the same vlanids thru a single provider plane.

All customer-vlans are unique per each customer. So Theoretical speaking, you can have 4K unique customer vlans  depending on if your hardware could actually support 4K+ vlans.

NOTE:  The same applies for the customer interface and sub-interfaces. A pair of the above routers could have  4K+ sub-interfaces from  vlan# 1-4094. With QinQ  trunking you can carry any of  the 4000+ vlans with as long as it's not the SP customer-vlan. Any traffic not 802.1q tagged would be carried natively


Keep in mind with QnQ tagging,  the provider cloud must support a MTU greater than the standard 1514/1518 to allow for the 12 addition bits of extra 802.1q information for the outer vlan-tag

Ken Felix
NSE ( network security expert) and Route/Switching Engineer
kfelix  -----a----t---- socpuppets ---dot---com

     ^     ^
=(  #   #  )=
         o 
        /  \

Exploring the diag stats fortigate

Fortinet has always been a leader with regards to application identification statistics. In this post we will look at  obtain  statistical information by using  the diag stat  command from the cli.

The command has a limited set of options;


DAFWFGT800 # diag stat
app-bandwidth     applications by bandwidth of last minute
app-stat-clear    clear application statistics
app-usage-ip      per ip usage of application
per-ip-bw         top bandwidth by IP address
 


Typically one will execute the app-bandwidth to get a general overview of traffic statistics.

e.g


Note: I  highlighted a few fields such as ;

application id 
sessions counts
bps 
application name

With this diag cmd, you can specify the  app-id if known for statis on that application.


With the count option, you can now get statistics by address.


By using the per-ip option we can list of the top talkers;



This command can be creative and helpful with traffic status and counts.



Ken Felix
NSE ( network security expert) and Route/Switching Engineer
kfelix  -----a----t---- socpuppets ---dot---com

     ^      ^
=(  @  @ )=
         o 
        /  \

A look at EAS

So far in all of my security posts, has been network and/or security related. This one speaks of a gig that I just finished from a pen-test project  that was conduct against a major retail operation.  A friend of mine,  hired me on as a augmenter to a team of pen-testers, for a  project that was currently under way.

I came on initially for network penetration testing and firewall policies review.  Since the project had a requirement for conducting site physical security  test and penetration, I was able to suggest to  the project manager ,  if we could include product security;  “as in anti-theft  preventive measures”.

This ideal was suggested to  the customer, who immediately liked it and after a 1 hour conference call, we laid out the ground rules and restrictions;

·       No armed robbery (yes I’m not joking here, no physical confrontation with anybody to include loss-prevention personnel or customers)

·       No tampering with any EAS tags

·       No tampering with any EAS monitor gear ( aka transceivers)

·       No tampering with the packing material of any device that has a embedded EAS tag

·       Items must be at least $100.00 USD or more in value to be considered for this project


 Okay that looks simple, right ?

Will let’s back up some and explain the whole EAS tags concept and retail-theft and the flaws within.

Retail theft is always a problem with a host of stores thru out the world. Product are always stolen, and various department stores are always deploying various means for reducing theft. Some install cameras thru out the store’s public and private areas, others place security guards at entrance and exits, some even place door-open-alarms if open,  and lastly others trust the EAS systems.

EAS stands for Electronic Article Surveillance and primarily & is used to track the smaller/high value products such as; a handheld electronic devices ( phone/tablets/memory/cameras/etc...) , CD/DVD, games cartridges, phones, etc….

These devices are typically coupled  to a EAS tag or embedded in the packing material of the item. They are typically less than the thickness of a  pen/pencil width and shorter than a human pinky finger in length.

How the EAS concept works;  

·        A product  that's reviewed  as being an high theft object, will under go a EAS insertion. The store
negotiate with a EAS vendor  like  TycoSensormatic ( who  at one time I was employed as contractor in their IT/network dept). The vendor will provide an assortment of tags similar to these;





·       Transceiver devices are deploy at the entrances of the retailer store doors similar to the following;




When a tagged article that‘s actively armed & passes thru a transceiver, a audio/flashing warning is emitted.  I know you have seen these devices and/or at least heard one go off. They produce a buzz, chime, or siren. And in some cases, they briefly emits  flashes or lights to alert store employees of an possible theft.

The retailer stores deploys these systems as deterrence to theft, in a way similar to how a bank installs, security guards, dye packs, cameras, bullet-proof glass and man traps, but yet banks are still always being robbed and in some case the crooks are very successful  ( makes one think ) . 
Keypoint on history:  At one time  the Chicagoland was the bank robber capital of the world , & with a bank being hit every week if nt every day, but back to the story at hand.



Will back to our tagged articles of protection, the stores tries to reduce theft, but in reality they are not 100% successful by a long shot. Most stores will not publish data on just how many goods are stolen yearly, but most choose to report only an estimated. Who really knows, we just know items are being stolen on a daily basis by both amauetur  and professional thieves.

So in this gig, my goals was to prove that this particular retailer outlet & their choice of anti-theft mechanism was fool proof or not. I was given a list of 10 stores in the greater tri-county area that I resided in. Out of these 10 sites, I picked 6 store that where going to be “hit” so to speak. And didn’t let anybody know, and that including the pen-test leads  nor customer or any of there personnel.

I can’t disclose the store name or locations, but the sites where scoped out for a few days & before my big event would take place. In those few days, I recon'd the stores, and mentally selected the merchandise that I was going to try to lift.  I also probe their EAS alarms systems to get an ideal of the employees reactions,  and to validate the EAS gear was actually working.

How I probed the stores was very easy. I purchase a few device at another store ( that where not properly deactivated )  and removed the EAS tag from that device,  and used it to trigger the 6 selected stores EAS detection systems. It took me a few tries to get a non deactivated tag from my initial purchases, but when I found a few good ones, it was simple just to walk in thru the store entrance, and with my trigger EAS tag in my front shirt pocket.  A couple of pass thru the doors, will let you know if the systems was active.

In most cases the store employees did one of the following;

  • ·       hardly raised their heads or barely looked my way
  • ·       wave me on my way , as if nothing happen
  • ·       or did  absolutely nothing

The latter was what happen in almost eight out of ten times in my probe testing of the retail stores 6 targets locations. They did nothing, no challenge, and even to the point of no acknowledgement. I thought to myself ; “ This is going to be easy”

All but one of the six stores, had working EAS transceivers, so I skipped store #6 since the detection device was non-operative at the time of my initial probe. How often do they actually monitor the function of these devices and provide Maintenance is questionable imho.

So on the day of my big event, I dressed up in a nice causal polo & shorts, with my get out of jail paper, and drove to store number #1. It was a fall/winter day and the time was approx. 10:00AM. I strolled around in store #1 for about 30mins, looking at this and that, and loading, up my cart with big/heavy,  &  duplicate items. The goal was to lay the item(s) of theft, under these bigger items. These items where going to do one of two things;

  • ·                   shield the item from the EAS transceiver
  • ·                   or from visual eye sight, if it should go off

My planned worked like a charm.  My 1st store was looted of one item that weighed under 2lbs and cost approx  $132.00 usd.

I spent maybe 1 hour in that store total. The heavier items where too much of a hassle for the checkout employee, to remove and reinsert into my shopping cart. So she just scanned one item of the numerous/many that I had. I went to my next 4 targets, doing the exact same thing, but selecting another product to lift, but using the same method as with store number 1.

In all, I was 5 out of 5, and at the conclusion of that day or work, I had  $687.82 USD of goods.  Not bad for a day of work



Now can get an ideal of how organized retail theft rings work, and that the goods they lift  typically ends up at a flea market, or pawn shop.  At these place they are sold for a fraction of their face value. These organized pros targets stores like mine, and by lifting small items with no serial-numbers or with very hard means for tracking.

Now you can see that EAS systems are not effective be any means. In all of the 5 stores, and not counting the one with a broken, or non-operative transceiver, I was not challenge by any store personnel. In store #5, they even had a renta-security-guard at the door, and she barely raised her head when the alarm went off, since she her attention was directed at her smartphone, and the reading of a text or email.

I will say this; 

the alarms did trigger in all cases, but the culture of enforcement was broken by the employees ”.

So one can say the systems operated as designed, but it was the employees fault. But overall the EAS systems was not 100% in the prevention of theft. Only the honest person would be deterred by the EAS systems. Theirs an ole saying that goes like this; “locks, only keeps out the honest persons”. Will this holds true for the EAS systems.

Stores like office-depot for example, don’t bother to waste time and money with these EAS protection devices. They choose the route of  delaying  the customer, by making him/her bring a inert display item or box to the front counter,  and to make them wait, while they call up an associated to retrieve the items of interest for purchasing.  Or they stock certain items, upfront and behind the front counter.

This is probably more effective, than a multi-thousand dollar EAS systems and the 0.05-0.15 cent bulk pricing of the EAS tag that either packaged, pinned or coupled to the device.

I hope you found this article useful. 

Ken Felix
Freelance Security Network Guy
kfelix  “ a t “ hyperfeed dot com




Saturday, September 13, 2014

A meshed transparent-vdom using inter-vdom-linik fortigate

In this post we will look at a layer2  stacked aka meshed  vdom using a transparent vdom with a nat/routed-vdom.

This is setup is used when you have a  network segments that needs firewall protection, but do not want to  make any layer3 address changes. Please review previous meshed vdom here;
http://socpuppet.blogspot.com/2014/09/a-stacked-vdom-concept-with-fortigate.html

1st here's the topology;



As you can see custC vdom is  operating in a transparent mode with just 2 interfaces. The vdom is tied to the root-vdom using a inter-vdom-link.

First let's build our vdom for the custC and set the operation mode.

config system settings
    set comments "L2-vdom  SOCPUPPETS example  "
    set opmode transparent
    set manageip 10.199.199.2/255.255.255.0
end





Next we define one physical port into this custC-vdom. This could also have been an sub-interface ( 802.1q) on a trunk port.

config system interface
    edit "internal3"
        set vdom "custC"
        set type physical
        set alias "transparent interface inside"
    next
end



Okay now we need to define a  inter-vdom-link. Just like with the meshed routed vdoms, we place one side of the link into the root vdom,  and the other end into our l2-transparent vdom.

To keep this simple, I named this link transparent.
config system vdom-link
     edit "transparent"
        set type ethernet
    next
end


Tip, set the type as "ethernet" since we are going to bridge internal3 interfaces to it. The fortigate will also set  ethernet mac_address that you can customized if you  so desire. The default type is PPP.



Here's our inter-vdom-link name transparent0 and transparent1;



In true transparent installation & with real interfaces they typically will not have address assignment.  Since this firewall instance is stacked behind another layer3 device ( root-vdom firewall ) we have a layer3 interface addressed which is the gateway  for lan 10.199.199.0/24.


Now we can rock & roll.
 
1st we need to jump into the root-vdom and build our policy. We are going to simply allow all traffic and SNAT it via a interface overload on the WAN link.

( vdom root  firewall policy )

config firewall policy 
 edit 0 
        set srcintf "transparent0"
        set dstintf "virtual-wan-link"
        set srcaddr "all"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "ALL"
        set logtraffic disable
        set nat enable
 end


Next, we will create a dhcp-server within the  root vdom to dynamically assigned address to the layer2 vdom ( optional )

config sys dhcp server 
   edit 88
        set dns-service default
        set default-gateway 10.199.199.1
        set netmask 255.255.255.0
        set interface "transparent0"
            config ip-range
                edit 1
                    set start-ip 10.199.199.10
                    set end-ip 10.199.199.20
                next
            end


That pretty much takes care of our root-vdom configurations. Now we will switch to the  custC vdom and place an address  statements for the dhcp-server and local lan and a firewall policy

( custC vdom  address and firewall )

config firewall address
    edit "dhcp-server"
        set comment " transparent  dhcp server "
        set subnet 10.199.199.1 255.255.255.255
    next
    edit "10_199_199_0-NET"
        set comment "my local lan within the l2 domain socpuppets  http://socpuppet.blogspot.com "
        set subnet 10.199.199.0 255.255.255.0
    next
end


and our firewall policy;

config firewall policy
    edit 1
        set srcintf "internal3"
        set dstintf "transparent1"
        set srcaddr "all"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "ALL"
        set logtraffic disable
    next
    edit 2
        set srcintf "transparent1"
        set dstintf "internal3"
        set srcaddr "dhcp-server"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "DHCP"
    next
end



Ensure that you secure the required firewall policies that you need for both directions.

Make sure you create a policy to allow traffic from outside to internal if your dhcp-server is hosted on the outside.



And finally  we execute a  trace route to ensure that all works;



Vdoms  &  inter-vdom-links can be fun and challenging. Departmentalizing the fortigate firewall is a feature that can be used for dedication of resources and relinquishing  operations and controls to a sub administration. 

keep points
  • be careful of the inter-vdom links numberings
  • transparent operations are just that "transparent"
  • firewall policies  for all traffic flows needs to be build across vdoms
  • look at each vdom as a firewall  that unique that happens to sit in the same physical hardware
  • leverage  802.1q tagging to avoid port exhausting
  • HA clustering and vdom balancing can be a plus for A-P  operations
  • All interfaces have the ability for ; packet dump, allowaccess, if-index, netflow/sflow,etc......
note: be aware of dhcp-server positioning and any firewall policies for  the dhcp offers

Ken Felix
NSE ( network security expert) and Route/Switching Engineer
kfelix  -----a----t---- socpuppets ---dot---com

     ^      ^
=(  @  @ )=
         o 
        /  \


Friday, September 12, 2014

A meshed routed-vdom concept with fortigate

In this post we will look at a stacked ( meshed )  vdom routed concept. This is a means for the creation of vdoms for departmental isolation and with a share vdom that routes our traffic to the public wan.

This design is beneficial in that you can isolated roles and firewall function but yet have a gatekeeper-firewall  pe-se for that department. Each firewall vdom would  be Autonomous or
Sovereign.
The vdoms can be full or partial meshed. This post will demonstrate a partial meshed.

 
1st what is a vdom ?

This feature is a fortinet term for " virtual domain " or simply put; "  a firewall Virtualization Technology" . Think of it in the same way of the cisco ASA contexts,  or  Juniper SRX virtual-routers. We defined  a community with a communities of policies, admin, resource-limits and interfaces that are isolated from each others.

1st here's the topology;



Vdom ROOT ( RED ) is our public facing virtual firewall that has access to the internet backbone.

Vdom custA & custB  are stacked behind the  Root-Vdom and relies on the root-vdom for all internet access. You can look at this as a firewall behind another firewall. In  the above drawing,  I placed one  physical interfaces for the local lan subnets in each  customer side vdom.

This concept is used in a lot  of hosted of enterprise communities. The number of possible vdoms would be determine by the chassis type and possible the number of physical interfaces you consume for a vdom. We will use  both real and virtual interfaces in this example for the 3 vdoms shown.

Root =   WAN virtual-link,  vlinkcustA2root and vlinkcustB2root,
custA = PORT1 , vlinkcustA2root
custB = PORT2 , vlinkcustB2root

The custA & custB will use these virtual-links as the gateways to internet. These interfaces could have been  etherchannels ,  Wifi-interfaces,  or 802.1q tagged subinterfaces. Each vdom custA&B have dhcp-sys-services installed for dynamic allocation.

I like to call this vdom setup a "stacked" approach.

Okay now  let's build this out. The setup is quite simple, but the 1st time you stumble into  the fortinet vdoms world you might want to  build a checklist of things to look at and do B4 you start.

NOTE: the organizing of your design & thoughts,  can save a lot of time, create less confusing, and reduce  errors/mistakes 

So plan ahead for the proposed design.

Okay let put some /30 address on the  vlinks that we will use for the 2 customer vdoms ( custA custB )

vlinkcustA2root   192.168.10.0/30 ( .1  + .2 )
vlinkcustB2root   192.168.10.4/30 ( .5  + .6 )

1step assuming your already in vdom cfg mode and have set the firewall up with vdom enabled.


note: All fortigate appliance minus the  smaller SOHO have the capability to install upto 10vdoms each. With the bigger chassis you can  install vdom license for 10< vdom

config sys global
  set vdom-admin enable
end

We  1st build  the additional  vdoms named ;  custA and custB

config vdom
    edit custA
     next
    edit custB
end

2nd step

We define these interfaces port1 and port2 for these vdoms custA and custB respectively

config global 
    config sys interface 
         edit interna1
             set vdom custA
         next 
         edit internal2
            set vdom  custB
end

NOTE: You have to have the vdom created before you can place a interface into it.

3rd

Okay now, we will apply our virtual-links cfgs. These are our virtual WAN-uplinks. This is used for inter-vdom traffic ( traffic between vdoms ) and can be looked at as a real interface except it's really virtual. Your clients would not know the difference btw. For all purpose it's a interface. So you can do packet captures, allowaccess, build firewall rules, etc....

Each vlink will have one side  addressed in the root-vdom and other side in the customer vdom.  The sub numbers will end in a  0 and 1 as shown in the system interfaces. make sure you pay very good attention to the numbers and where you assign them and the address. In this post the Zero ( 0 ) will be in  Root and One ( 1)  will be in the customer vdom.

( vdom interlink creation )

config system vdom-link
    edit "root2custA"
    next
    edit "root2custB"
    next
end


(  vdom interlink address   config sys interfaces  )

   edit "root2custA0"
        set vdom "root"
        set ip 192.168.10.1 255.255.255.252
        set allowaccess ping
        set type vdom-link
        set snmp-index 22
    next
    edit "root2custA1"
        set vdom "custA"
        set ip 192.168.10.2 255.255.255.252
        set allowaccess ping
        set type vdom-link
        set snmp-index 25
    next

    edit "root2custB0"
        set vdom "root"
        set ip 192.168.10.5 255.255.255.252
        set allowaccess ping
        set type vdom-link
        set snmp-index 27
    next

    edit "root2custB1"
        set vdom "custB"
        set ip 192.168.10.6 255.255.255.252
        set allowaccess ping
        set type vdom-link
        set snmp-index 28
    next


4th, after you have the vlink installed and configured, we will start the vdom policy configurations. These are simple to configured and you will need policies in ALL vdoms for allowing the traffic flows.

( root firewall address + policies )

config firewall address

 edit "custA"
        set uuid a435f472-39f9-51e4-3f01-2f63d976cc44
        set subnet 10.100.10.0 255.255.255.0
    next

    edit "custB"
        set uuid ad656096-39f9-51e4-0d06-ee9f8c992982
        set subnet 10.200.10.0 255.255.255.0
    next

end


config firewall policy
    edit 0
        set srcintf "root2custA0"
        set dstintf "virtual-wan-link"
        set srcaddr "custA"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "ALL"
        set logtraffic disable
        set nat enable
    next

    edit 0
        set srcintf "root2custB0"
        set dstintf "virtual-wan-link"
        set srcaddr "custB"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "ALL"
        set logtraffic disable
        set nat enable
    next

end 

 ( custA firewall address and policies )

config firewall policy
    edit 1
        set srcintf "internal1"
        set dstintf "root2custA1"
        set srcaddr "all"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "ALL"
        set logtraffic disable
        set comments "custA-outbound"
    next

end

( and finally custB )

config firewall policy
    edit 1
        set srcintf "internal2"
        set dstintf "root2custB1"
        set srcaddr "all"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "ALL"
        set logtraffic disable
        set comments "custB-outbound"
    next

end

NOTE: we are allowing all traffic with no nat enabled, NAt overload will be configured in the  root vdom 


5th, you need routing for traffic entering and exiting the vdoms and for the root-vdom to route traffic to the local subnets

( custA  static route )

config router static
    edit 1
        set device "root2custA1"
        set comment "default custA"
    next
end


(custB  static route )

config router static
    edit 1
        set device "root2custB1"
        set comment "default custB"
    next
end


( root vdom static route to the  customer vdom  subnets  using the inter-vdom-links  )

config router static
    edit 1002
        set dst 10.200.10.0 255.255.255.0
        set gateway 192.168.10.6
        set device "root2custB0"
    next

    edit 1001
        set dst 10.100.10.0 255.255.255.0
        set gateway 192.168.10.2
        set device "root2custA0"
    next

end

Finally some traceroute output to show that this all works;

( custA vdom )


( custB vdom )


Vdoms  &  inter-vdom-links can be fun and challenging. Departmentalizing the fortigate firewall is a feature that can be used for dedication of resources and relinquishing  operations and controls to a sub administration. 

keep points

  • be careful of the inter-vdom links numberings
  • ensure routing or a routing protocol is used
  • firewall for all traffic flows needs to be build across vdoms
  • SNAT and DNAT can be complex ( stay focus on what vdom your in )
  • look at each vdom as a firewall  that unique that happens to sit in the same physical hardware
  • leverage  802.1q tagging to avoid port exhausting
  • HA clustering and vdom balancing can be a plus for A-P  operations
  • All interfaces have the ability for ; packet dump, allowaccess, if-index, netflow/sflow,etc......
note: VIPs can be created on any of these segments , but the public facing  firewall will house any public address  that we map to our  customer servers or possible to a inside VIP.

Ken Felix
NSE ( network security expert) and Route/Switching Engineer
kfelix  -----a----t---- socpuppets ---dot---com
     ^      ^
=(  @  @ )=
         o 
        /  \