Thursday, June 27, 2013

I passed my Fortinet mail exam FCESP

This by far has been my hardest IT/exam ever , and much harder than the other  Fortinet exams that  I have taken over the course of 5 years. FCESP has straight forward questions  & on just  about everything you can imagine.

Unlike cisco certifications exams, the exam challenges you with both technical  questions and know how. They don't have silly  question such as;
  • what's cisco stance is.....
  • what's the methodology of.......
  • etc...

 The question ( 45 total ) are dealing with the FortiMAIL  unit  to include;  the operation, function and diagnostics capabilities.

I glad it's over, and  after my  1st miserable fail,  I'm just  glad I passed it & almost 2 years later.
( FCESP attempts )

The funny thing about this exam;

1: A FortiMail class is not going to help you at all ( so don't think you can pass, just by taking a class )
2: you will need  actually time deploying and managing these units
3: a lot of transparent-mode questions ( so get prepared )
4: same with almost all other parameters including  ldap,acl, recipient +ip based policies
5: no simple SMTP questions ( no give-me )
6: my exam was filled with a lot of things I 've never done or even knew  about ( :)  )
7: it's challenging
8: I thought I did much better, but the results showed otherwise

Good luck if you ever attempt to take this exam.

fwiw: The exam I took will be replaced in the near future per my email dialog with  Fortinet Certifications

e.g ( snapshot of  a response from Fortinet )

So if I want to get certified  for 5.0, I will have to take another exam.  I don't know how much harder it would be but ..... Boy I can't wait!


Ken Felix
Freelance Network/Security Engineer
kfelix    a t  hyperfeed  d o t  com

Wednesday, June 26, 2013

diag debug flow troubleshooting

In this blog, we will look at the FortiGate  diag debug  flow output messages & what they are trying to tell you.

I've been dabbing with Fortigates ever since 3.0 came out ( since 2005 ) and it still surprises me  on the pure amount of  individuals,  that struggles with diagnostics and those that don't even use the  diag debug flow.

In this post I'm going to show you some output messages and how to interpet them.

1st  up:

You try to ping , ssh or web into a fortigate and you are denied. Diag debug flow will show you something of the following;

So this means; " whatever interface your trying to access did now have the correct < set allowaccess> statement "

e.g ( webgui interface configurations )

or via the cli;


This  message  below is "10 out of 10" times one of the following;

1: a deny firewall policy ( it even tells you so :) )
2: firewall policy missed-ordered or sequence#  ( our most specific and denys should be 1st in the order )
3: error in your firewall policy ( typo , wrong address, wrong  interface , service or a combination of erros )
4: or a missing firewall policy ( if it's not allowed it's denied )

Bottom line check your firewall policies and go thru them with a fine tooth comb.

3rd and final: ( my favorite )

When your working with  sslvpn or tunnels this is a common  error. It's also seen when you have internal LANs being routed behind another device like a internal router & you have no route for the source(s) in the FGT route table.

In the above 10 out of 10 times it's any of the following;

1: routes installed  incorrectly
2: no route installed ( it's missing )

Bottom line ;"your routing is screwed up" . Monitor your route table and validate the next-hop gateway is correct & the correct interface.

Diagnostics with diag debug flow is simple and straight.

It frustrate me to see  junior/senior  Fortigate engineers struggling to diagnostic connections problems, and they DON'T ever bother to use the built-in diagnostics tools or just bypass the process of making a packet capture.

The fortigate is one of the best firewalls on the market to trouble-shoot ( period ). You will not find anything as simple or as easy.

These commands should be routine in our everyday  activities and before you waste time throwing things into the mix;

diag debug flow
diag sniffer

And finally, we have  the means to make  packet  captures on most any newer fortigates.

 So instead of guessing, shoot-n-pray, or just using the "trial--n--error" process, start using the diag debug flow  cmds :)

Ken Felix
Freelance Network/Security Engineer
kfelix  ---a---t--- hyperfeed --d-o-t-- com

    ^        ^
=( @   @ ) =
      /     \

diag system session ( a quick way find sessions on fortigate firewalls )

In this post, I will share  with you a simple means; "  to find and for filter specific sessions"from the cmd line.

Fortigate offers a  session  count thru the gui, but it's not as flexible as what you can do from the command line. The cli provides more flexibility,  and in fact ; you can filter option in the webgui, but it's not as quick nor easy to  deploy.

If you need to quickly change filters, the cli is the best means.

( samples of the webGui  session details )

The diag system session  or session6 command, provides either the ipv4 or ipv6  sessions stats. With this command you can filter by a host of parameters. This allows you to zoom into the  sessions types that you might have interests in.

here's those parameters;

As you can see from the above, we have a host of parameters. In the case of the output above, I'm filtering for icmp ( protocol #1 )

A simple ping to my wan2 interface after allowance for ping, will display the session(s) with the above filter.

Filtering on sessions in this manner, allows for quick diagnostics of the total sessions  & helps with quickly identifying  states within your fortigate firewall.

You should get use to applying and clearing filters in your everyday  monitoring , and trouble-shooting activities.

To wrap up, the flexibility in the filter is amazing and with creativity, you can filter on a host fields. In this last snapshot; " here's a filter using just  the policyID"

( I highlighted some key items )

The session filters along with diag debug flow, are two of the most important diagnostic commands that we have. These commands, make the life of diagnostic for fortigate series firewalls, much easier. They are simple to deploy provide more details than most other brands ( cisco ASA, Juniper NS/SRX ) and the information is very useful.

Ken Felix
Freelance Network/Security Engineer
kfelix  at  hyperfeed

   ^      ^
=( *  * )=
      /  \

Sunday, June 23, 2013

SNMPv3 traps config + cisco

In this blog we will look at security SNMPv3 traps

SNMPv3 allows for us to generate traps and secure these between the agent and manager. To do this we need to take a few steps in  our configurations;

1st we need to enable traps

config t
  snmp-server enable traps


next we need to define  a snmpv3 group and a user. Here we are defining a group name <mygroup> and a user <myuser> and with  <md5> and single <des> for authentication and encryption.

config t
 snmp-server group mygroup v3 auth
 snmpserver user myuser  mygroup v3  priv md5 Ims0s3cur3d  des56 hAckm3123Wed

The next few steps are crucial; we have to have a unique EnginID, but we don't have to configured one. By default, our  snmpEngineID is predefined on every cisco  router/switch device.

This  ID is created by default , & by using the 1st physical interface bia ( burned in address  aka mac-address )

Here's a cisco 2800;

rt1.mdc11#show int gi 0/0 | incl bia
  Hardware is MV96340 Ethernet, address is 0015.fad8.2211 (bia 0015.fad8.2211

and check out our SNMPengine ID

rt1.mdc11#show snmp engineID       
Local SNMP engineID: 8000000903000015FAD2211  <------ here

Remote Engine ID          IP-addr    Port

Notice how our bia is used to compute the engine ID?

It's done by default and you have to do nothing. Arguments have been made for crafting the ID by and for it being unique for each device in your network.  A few valid reasons exist for this purpose;


  • Such as if you   change hardware ( i.e  RMA ) or configurations are move to a new device ( SNMP engine ID will change )

  • Also the  SNMPv3 user  password is hashed off this  ID. So if you change it mid-stream, it would  screw up the SNMPv3 user

Now moving on, you need to craft a remote snmp engine ID for the remote collector;

snmp-server engineID remote 8000000903000000000001

Once again this ID is unique and should be for the SNMPtrap collector.

Now that we have all of the ingredients,  we can complete the config by mapping the SNMPv3 user to our  snmp-server  hosts that's to receive the traps.

Here's the final configuration for our  user to send traps to the host; the user =  "myuser", and we are using  version 3.

snmp-server  host  informs  version  3 priv myuser

So  in this example, the  router/switch would send  snmpv3 traps with authentication only, and with no encryption. The SNMP collector would authenticate the sender traps.

The following dumps shows you some unencrypted traps being sent to a  collector & from the above host;

Here's some other important information that pertains to cisco and SNMPv3 users;

The SNMPv3 user information,  is NOT maintain in the running-config. If you "dir" the nvram filesystem, it would maintain a list of  SNMPv3 user names/password-hashes and along with  any ssh private-pub/keys. If you would run the "show run " command, you will not find any user information for SNMPv3.

NOTE: The file  <private-config> contains the SNMPv3 user  information and it is NOT read/write by anyone.

Also the "show snmp user" command will show you details about any  configured  users, along with your SNMP engine ID.

So SNMPv3 traps are easy to configure , and requires a few more steps. Its simple, and just remember ; " you have the means to use auth or authPriv between the  SNMPagent and collector"

Ken Felix
Freelance Network/Security Engineer

   ^     ^
=( *  * )=
     /    \

Server "active close"

With a typical web-browser, the normal behavior is for the server to close the session after they have received the request via the client. But that's doesn't always happen in that order. In this post we will look at some closing for tcp-sessions.

Here's the opposite, where a server closes the session first;
( the client sits at in these examples )

sh-3.2$ sudo tshark -r active*close.pcap -R 'tcp.port==55876'
 21 15.184532000> TCP 78 55876 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=16 TSval=816445360 TSecr=0 SACK_PERM=1
 22 15.286232000 -> TCP 66 http > 55876 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1430 SACK_PERM=1 WS=128
 23 15.286279000> TCP 54 55876 > http [ACK] Seq=1 Ack=1 Win=262144 Len=0
 24 15.286337000> HTTP 205 GET / HTTP/1.1
 25 15.377931000 -> TCP 60 http > 55876 [ACK] Seq=1 Ack=152 Win=6912 Len=0
 33 25.378766000 -> TCP 60 http > 55876 [FIN, ACK] Seq=1 Ack=152 Win=6912 Len=0
 34 25.379010000> TCP 54 55876 > http [ACK] Seq=152 Ack=2 Win=262144 Len=0
 35 25.379271000> TCP 54 55876 > http [FIN, ACK] Seq=152 Ack=2 Win=262144 Len=0
 36 25.467514000 -> TCP 60 http > 55876 [ACK] Seq=2 Ack=153 Win=6912 Len=0

I bold the line containing the FIN-ACK and from the direction of the server. Now let's compare the  normal TCP close typically done by a client.

sh-3.2$ sudo tshark -r normalclose.pcap  -R 'tcp.port==56154'
  1 0.000000000> TCP 78 56154 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=16 TSval=816940518 TSecr=0 SACK_PERM=1
  2 0.044037000 -> TCP 78 http > 56154 [SYN, ACK] Seq=0 Ack=1 Win=32768 Len=0 MSS=1380 SACK_PERM=1 WS=1 TSval=3823454198 TSecr=816940518
  3 0.044278000> TCP 66 56154 > http [ACK] Seq=1 Ack=1 Win=131328 Len=0 TSval=816940561 TSecr=3823454198
  4 0.044447000> HTTP 208 HEAD / HTTP/1.1
  5 0.151665000 -> TCP 383 [TCP segment of a reassembled PDU]
  6 0.151972000> TCP 66 56154 > http [ACK] Seq=143 Ack=318 Win=131008 Len=0 TSval=816940667 TSecr=3823454209
  7 0.152167000> TCP 66 56154 > http [FIN, ACK] Seq=143 Ack=318 Win=131072 Len=0 TSval=816940667 TSecr=3823454209
  8 0.198413000 -> TCP 66 http > 56154 [ACK] Seq=318 Ack=144 Win=32768 Len=0 TSval=3823454213 TSecr=816940561
  9 0.198646000> TCP 66 [TCP Dup ACK 7#1] 56154 > http [ACK] Seq=144 Ack=318 Win=131072 Len=0 TSval=816940711 TSecr=3823454213
 10 0.203468000 -> HTTP 66 HTTP/1.1 200 OK
 11 0.203732000> TCP 66 56154 > http [ACK] Seq=144 Ack=319 Win=131072 Len=0 TSval=816940715 TSecr=3823454213

Notice the client  initializing the closure first? Also you see some duplicate ACK  that's not relevant.

Here's another client side closure;

sh-3.2$ sudo tshark -r normalclose.pcap  -R 'tcp.port==56421' -tad
  1 2013-06-22 23:40:09.145392000> TCP 78 56421 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=16 TSval=817520647 TSecr=0 SACK_PERM=1
  2 2013-06-22 23:40:09.236713000 -> TCP 74 http > 56421 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1380 SACK_PERM=1 TSval=2005662022 TSecr=817520647 WS=128
  3 2013-06-22 23:40:09.237021000> TCP 66 56421 > http [ACK] Seq=1 Ack=1 Win=131328 Len=0 TSval=817520736 TSecr=2005662022
  4 2013-06-22 23:40:09.237193000> HTTP 207 HEAD / HTTP/1.1
  5 2013-06-22 23:40:09.330093000 -> TCP 66 http > 56421 [ACK] Seq=1 Ack=142 Win=15616 Len=0 TSval=2005662116 TSecr=817520736
  6 2013-06-22 23:40:09.331312000 -> TCP 255 [TCP segment of a reassembled PDU]
  7 2013-06-22 23:40:09.331584000> TCP 66 56421 > http [ACK] Seq=142 Ack=190 Win=131136 Len=0 TSval=817520829 TSecr=2005662116
  8 2013-06-22 23:40:09.331977000> TCP 66 56421 > http [FIN, ACK] Seq=142 Ack=190 Win=131136 Len=0 TSval=817520829 TSecr=2005662116
  9 2013-06-22 23:40:09.428806000 -> TCP 66 http > 56421 [FIN, ACK] Seq=190 Ack=143 Win=15616 Len=0 TSval=2005662210 TSecr=817520829
 10 2013-06-22 23:40:09.429067000> TCP 66 56421 > http [ACK] Seq=143 Ack=191 Win=131136 Len=0 TSval=817520925 TSecr=2005662210

Same here, the client sends the FIN-ACK and the server immediately sends back a FIN-ACK and doesn't even bother to  wait for the  client #2nd  ACK.

And lastly,  here's a  look at another client and server tear-down, once again initialized by the server;

sh-3.2$ sudo tshark -r normalclose.pcap  -R 'tcp.port==56155'
 12 6.023331000> TCP 78 56155 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=16 TSval=816946451 TSecr=0 SACK_PERM=1
 13 6.126083000 -> TCP 78 http > 56155 [SYN, ACK] Seq=0 Ack=1 Win=4290 Len=0 MSS=1430 WS=1 TSval=1863626880 TSecr=816946451 SACK_PERM=1
 14 6.126398000> TCP 66 56155 > http [ACK] Seq=1 Ack=1 Win=131872 Len=0 TSval=816946553 TSecr=1863626880
 15 6.126548000> HTTP 209 HEAD / HTTP/1.1
 16 6.249165000 -> HTTP 203 HTTP/1.0 301 Moved Permanently
 17 6.249460000> TCP 66 56155 > http [ACK] Seq=144 Ack=138 Win=131728 Len=0 TSval=816946674 TSecr=1863627001
 18 6.249666000 -> TCP 66 http > 56155 [FIN, ACK] Seq=138 Ack=144 Win=4433 Len=0 TSval=1863627001 TSecr=816946553
 19 6.249714000> TCP 66 56155 > http [FIN, ACK] Seq=144 Ack=138 Win=131728 Len=0 TSval=816946674 TSecr=1863627001
 20 6.249827000> TCP 66 56155 > http [FIN, ACK] Seq=144 Ack=139 Win=131728 Len=0 TSval=816946674 TSecr=1863627001
 21 6.354273000 -> TCP 66 http > 56155 [ACK] Seq=139 Ack=145 Win=4433 Len=0 TSval=1863627108 TSecr=816946674
 22 6.354555000> TCP 66 [TCP Dup ACK 20#1] 56155 > http [ACK] Seq=145 Ack=139 Win=131728 Len=0 TSval=816946777 TSecr=1863627108
 23 6.355058000 -> TCP 66 [TCP Dup ACK 21#1] http > 56155 [ACK] Seq=139 Ack=145 Win=4433 Len=0 TSval=1863627108 TSecr=816946674

So a server can close the tcp connection 1st. 

TCP allows for either party to close the sessions.  When the server closes the session 1st ( by sending the initial FIN-ACK ) it's called a "active close". 

NOTE:  In the above last  pcap example,  and due to the short  delay between  packets #18 & #19, I believe this yet another close type, known as a   simultaneously close.

(  keep theses below thoughts in mind when dealing with  tcp )

All TCP sessions goes thru  these states;

  LISTEN ( server listening and awaiting for connections )
  SYN-SENT  ( a cliet Sending a request to Synchronize a session )
  SYN-RECEIVED ( server ack the client and completion of the Synchronize the session via sequence #s )
  ESTABLISHED ( client +server are actively establish, does not necessary mean we are passing data )
  FIN-WAIT1 ( awaiting a connection termination state or ack from the remote ) 
  FIN-WAIT2 ( awaiting a connection termination state from remote )
  CLOSE-WAIT ( awaiting a connection termination from the local machine )
  CLOSING (  a waiting a connection termination from the remote host )
  LAST-ACK ( ack of the last closing state)
  TIME-WAIT ( a state to ensure that the session is closed )
  CLOSED ( a psuedo state  it really doesn't exists  & means we are close and not sending data )

With the active close, this is acceptable and not bad behavior. The server does not have to wait for the  session to be torn down via the client or even the "Acknowledg" the client requests.

With a lot of tcp based applications  & those that deals with "web" services, the server may start the tear down 1st. So keep that thought in mind.

   ^   ^
=( * * )=
     / ` \

Ken Felix
Freelance Network/Security Engineer
kfelix  ---a--t--- hyperfeed  dot com

Wednesday, June 19, 2013

BGPv6 on FGT

A Fortinet SE contact me a few days to discuss some BGPv6 peering setup and with fortigates. This blog will show you  BGPv6 peering setup.


FG200A2106401308 (loop0) # show
config system interface
    edit "loop0"
        set vdom "root"
        set ip
        set type loopback
        set alias "router-id"

#WAN2 is my ipv6 uplink in the route injector of mine

config system interface
    edit "wan2"
        set vdom "root"
        set allowaccess ping
        set type physical
            config ipv6
                set ip6-address 2001:db8::1/127

# bgp cfg

FG200A2106401308 # show router bgp
config router bgp
    set as 65506
        config neighbor
            edit "2001:db8::2"
                set remote-as 65506
                set keep-alive-timer 90
                set holdtime-timer 240
                set weight 1000
        config redistribute "connected"
        config redistribute "rip"
        config redistribute "ospf"
        config redistribute "static"
        config redistribute "isis"
        config redistribute6 "connected"
        config redistribute6 "rip"
        config redistribute6 "ospf"
        config redistribute6 "static"
        config redistribute6 "isis"
    set router-id

And the cisco;

interface GigabitEthernet0/1
 description outside
 ipv6 enable
 ipv6 2001:db8::2/64
 duplex auto
 speed auto
 media-type rj45


router bgp 65506
 bgp log-neighbor-changes
 neighbor 2001:DB8::1 remote-as 65506
 address-family ipv4
  neighbor 2001:DB8::1 activate
 address-family ipv6
  network 2001:DB8:100::/64
  network 2001:DB8:101::/64
  neighbor 2001:DB8::1 activate

And  now a few show cmds
FG200A2106401308 # get router info6  bgp summary
BGP router identifier, local AS number 65506
BGP table version is 1
1 BGP AS-PATH entries
0 BGP community entries

Neighbor        V         AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
2001:db8::2     4       65506      26      14        0    0    0 00:02:15        2

Total number of neighbors 1


FG200A2106401308 # get router info6  bgp
BGP table version is 1, local router ID is
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
                    2001:db8::2               0    100   1000 i
                    2001:db8::2               0    100   1000 i

Total number of prefixes 2

ken Felix

Fortimail IBE setup as simple as 1 2 3

In this blog we will look at the Fortinet's FortiMail  IBE setup. 1st what is IBE? 

Identity Based Encryption

What this means, we have a method to enforce encryption profiles & based on the user ( recipient ). This allows full encryption of the body of the email message and/or it's attachment(s).

What this means;
  •  we can control  the securing of the email content 
  •  based on sender and destination  ( ip_address or email address )
  •  enforce  enterprise strict security-policies between sender/recipient
  •  unlike TLS between MTAs, the message is fully  encrypted in transient and at rest
  • and with out his/her ( sender/recipient )  knowledgement or involvement ( we don't need any local mail encryption programs like PGP, nor have to worry about the user forgetting to encrypted his mail )
So in the fortimail appliance, we can set our delivery options after creation of a IBE profile. In the IBE encryption profile, you have these choices of  encryption ciphers ;

Profile > Security > IBE

These levels of encryptions, should satisfy most security policies & any requirements that your network might  demand. Theses choice of encryption, should meets most enterprise & government requirements. AES is highly recommended imho and should be used at minimum.

The name of the IBE profile should be simple & fit the purpose. It should also be easy to  remember. Once again this is my opinion.

Here, I'm naming this profile IBE-3des for  the "triple des encryption" encipher.


After you have defined your IBE profile(s), you  must set up the delivery under your access-controls.

AccessControls > Delivery

The above is a snippet of my  delivery access, and the  "from who", "to what"   & the level of encryption.  As you can see, I have a few  profiles built for 3des and even aes192.

At this point; 1> you should select you encryption profile, or  2> create a new one,  and install any comments within the profile ( optional).

In the below example,  I'm created a  encryption profile for any email from  <anyuser> to  <anyuser> & selection and selecting aes192. You can use wildcards or specific matches for either  the user email_address or ip_address.

Okay now, let's order the ACL to be match before any "wildcards" access-list entries. This step is crucial & you must remember the evaluation order of the profiles. Email policies are like firewall policies,  "top to bottom , & the most specific match 1st"

Okay now that the ordering is correct we will draft a mail message from  the appliance or even any mail that was relayed thru the unit. All would under go the encryption and the profile that's attached for the sender/receiver.

I'll send a email to someone on gmail. And let's  watch what happens. Here's the mail messages;


Unknown to the sender, his email will be  encrypted and  a link pushed to the recipient. The recipient can down load the  email attachment ( the secured data ),  but it would be encrypted by the cipher that we used. So good luck to anybody that intercepts our data.  They would not be able to  decryption the cipher.text.

A  message will appear in the  recipient inbox similar to the below. This message is  just a <notification> for mail sent securely to the recipient.

And if he/she want to read the message, they would need to follow the link and set a password. All of the above is done via  TLS and thru the redirection link give in the mail messages. The registering of the  user is simple and straight forward and takes about 1-2mins depending on how fast you can type :)

After you  have completed the register and crafted a new user, you can view the  email.

Decryption speeds will depend  on the cpu utilization and the network bandwidth of the fortimail appliance.

The fortimail will monitor the user  status and  display information concerning the user,  & under the user > ibe-user . You can display information about the  user logins and when they completes the pre-register process

See how simple this setup  & just how effective the IBE encryption process .

As with all email messages, you can download the message, but it would be encrypted with the cipher that you enabled under that profile. So if a man in the middle or big brother was watching, they would have only cipher.text. The only information not encrypted,  would be  our  html formatting and other non-mail message body data.

I hope this post has been helpful. IBE is easy to craft and setup. Key points to remember;

  • determine the level  of encryption that you need
  • determine the sender/recipient that needs encryption 
( i.e  maybe accounting and hr to other other accounting or HR  personnel , or maybe you need o encrypted that job offer letter to an external party ]
  • Build your profile
  • attach it via the ACL for the sender/recipient pairing
  • evaluate the ordering of the ACL and adjust if required

Ken Felix
Freelance Security/Network Engineer
kfelix ----at--- hyperfeed  --dot---com

    ^     ^
= ( *  * )=

Sunday, June 16, 2013

Fortimail Tips & Tricks

Here's a few tips that I would like to share about the Fortimail Appliance;

1st  If you want to clear all mail statistics , you can easily conduct this operation from the cmd line;

You can also write them out to a file b4 execution of the clearing.
NOTE :  I don't know of any way to download the statistics off the  unit directory after doing this

2nd Have you ever had stale greylisting  entries in the display , and new ones are not populating? Will you can  clear the greylist database from the cli.


The FortiMail appliance allows you to download the logs from the gui, you can use these logs via scripts to manipulate collection of details such as; client_ip; dispositions;etc...


Remember you can write layer3  ACLs to block by address for receive or outgoing;

This way, you don't have to wait for your firewall team to block anything for you :)


For Secured SMTP you need to check the following box.

Lastly, when updating software, always  backup the cfg. I've seen problems where rules where lost during a OS update

Ken Felix
Freelance Network/Security Engineer
kfelix  ----at---hyperfeed ---dot---com

     ^          ^
= (  @   @ ) =
         /    \

Thursday, June 13, 2013

SNMPv3 on SRX Junos ( user and views )

In this post we will look at SNMPv3 support and views creations.

SNMP v3 support is available in  junos and the SRX platform for quite some time now. It's quite simple to set up. Let's recap what SNMPv3 provides;

It supports encryption ( privacy ) and authentication ( who has access )
It's backward compatible with  communities 
It supports views ( even v1 & v2c supports views btw )

Okay let's look a very basic v3 cfg;

set snmp v3 usm local-engine user nms  authentication-md5 authentication-password mypasswordhere
set snmp v3 usm local-engine user nms privacy-des privacy-password mypasswordhere
set snmp v3 vacm security-to-group security-model usm security-name nms group groupnms
set snmp v3 vacm access group groupnms  default-context-prefix security-model any security-level privacy  read-view all
set snmp v3 vacm access group groupnms  default-context-prefix security-model any security-level privacy write-view all
set snmp view all oid .1
set snmp contact hyprops

The above is from my management & polling station. And for this SRX we are allowing both the Authentication & Privacy ( authPriv ) and my view  is named "all". And within the view "all", we have allowed  all views with in the .1 family ( so pretty much the whole tree  for .iso  & the   ISO assigned oids  or the start of the tree with the MIB walk )

My SNMPv3 user == "nms"  and he belongs to  the group known as "groupnms"
The group "groupnms" has a view ( "all" ) for the security level  "privacy" and for both read/write access

Okay see how simple the above was ? 

We  can craft various views to ensure we give the appropiate user the right to read/write as required by the SNMP manager. Typically in my setups, I  have numerous views depending on  the SNMP manager functions & roles.

( e.g  NMS polling station ( cacti ) and another for  NMS monitor ( opsview/nagios ) )

Okay now let's look a more complex setup that leverage a more specific view ;

set snmp v3 usm local-engine user nmssys  authentication-md5 authentication-password hyprf33d3efSnMpv3
set snmp v3 usm local-engine user nmssys privacy-des privacy-password hyperFe3dP3nL921h

set snmp v3 vacm security-to-group security-model usm security-name nmssys group hyperfeedpen

set snmp v3 vacm access group hyperfeedpen  default-context-prefix security-model any security-level privacy read-view hypr5387
set snmp v3 vacm access group hyperfeedpen  default-context-prefix security-model any security-level privacy write-view hypr5387
set snmp view hypr5387 oid . include
set snmp view hypr5387 oid . include
set snmp view hypr5387 oid  . include
set snmp view hypr5387 oid  . include
set snmp view hypr5387 oid  . exclude
set snmp view hypr5387 oid  ifIndex  included
set snmp view hypr5387 oid  ifName included

set snmp v3 snmp-community  NMSac#ssH678 security-name nmssys
set snmp contact

Okay the above provide a few oid that I've allowed and a few that I want to disallow for this view and user using a few juniper  oids and  the full range of oid under my own PEN " 5387 IANA " and a few common interface oid. I have a community string  also created.

Another example and more common

I could have create a view to exclude certain details and apply these to my group and user;

set snmp view mycustomer oid  ifDescr .6 include
set snmp view mycustomer oid  ifName.6 include

set snmp view mycustomer oid  ifOutOctets.6 include
set snmp view mycustomer oid  ifInOctets.6 include
set snmp view mycustomer oid  ifType.6 include
set snmp view mycustomer oid  ifAlias.6 include

The above would allow the user/group  to query the above  objects and only those objects in the "mycustomer" view & for the interface index ID of ".6"

 Great for when you want to accommodate a client & allow them to graph a port, but restrict his/her view to just that port.

With SNMPv3 we can use  the common  snmptools;    snmpwalk or snmpget  & to test the  "views" and configuration parameters;


snmpwalk -u <username" -v3  -O ne  -l authPriv -x md5 -X <authentication pass phrase> -x des -X <privacy passphrase > ip_address .

( the above would walk all in the  Organization   of registered  "HyperFeed"  starting  at .* )

Things to key in mind;

  • ciphers are limited to DES or AES128 ( not sure if 3des is support in any Junos release )
  • you can provide  further restriction by enabling a host ACL filter to restrict the SNMP manager access by ip_address targets
  • passphrases need to be  8 characters or more , and try to avoid special characters like a ! or *
  • A user can be a member of just  one group ;  for both the read or write
When trouble-shooting;

  • try to identify the problem
  • is a credential related matter ( a wrong user and/or password or auth/privacy level )
  • or is it a ACL ( port 161/udp )
  • or is it a encryption protocol/hash mismatch

Good luck and remember to diagnose you snmp issues and configuration, based on what errors you get;

FWIW: Your SNMPviews can be different for both read or write & don't have to match. 

" I try to avoid taking a Hilter approach and place extremely tight  SNMPviews . If you don't know what your SNMPmanager might poll. I 've spent countless hours trouble-shooting  why Nagios is timeout or failing on a query and come to find out, we where blocking it from  our view   "

Ken Felix
Freelance Network/Security Engineer
kfelix  ------a@t --------hyperfeed ---.----- com

    ^        ^
= ( @    @ ) =
        /   ~   \

Tuesday, June 11, 2013

CDN and ipv6

Content Delivery Network providers have been slow  in providing  content for ipv6 clients, but the growth is moving forward.

Take this link

This is akamai tracking of ipv6 content delivery. What you will find  interesting, the number are  moving at a snail's pace.

A few reasons as to why;

  • lacking of knowledge in the enterprise sector
  • lack of any customers demanding it
  •  security  awareness for WAF/PROXIES/FILTER/SSL-INSPECTION is hit or miss
  • lack of DDoS mitigation service providers 
  • overall budgets in  our tight economy for transition to ipv6 is small
All of these are  factors , stuns the movement to provide content for the ipv6 segment. Take my  dayjob, we have connection to the ipv6  backbone , but as of this date; " we do not have one  public facing  server on the ipv6 network".

Same things goes  in that we are a mitigation  company, but we  really can't mitigate anything as far as ipv6 traffic goes.

 look at  how many host based AV/Malware software that supports ipv6? ( very few )

So all of these factors are major reasons as to why content on the ipv6 network is at a crawl. Here's a listed on CDN providers that are ipv6 awared;


here's some good links to learn more about  these ipv6 CDN providers

Ken Felix
Freelance Network/Security Engineer
kfelix   --a@t-- hyperfeed ---d.t--com

Saturday, June 8, 2013

Packet Forgery

In this discussion, we will look at packet forging tool known simply as "sendip".

Sendip is a packet utility tool that comes in handy for typical security personnel. Great for  crafting packets to check firewall policies or ips/idp signatures. Or in some case to  check the behavior of a network device or server.

Sendip used various modules  and supports ipv4 and v6. Each module works on a dependency model


for a icmp message

ipv4+ icmp

for a udp packet

ipv4 + udp

With the dual ipv4/ipv6  stack support, you can build a slew of options, depending on the modules you enable & the options or switches you use.

Here's a terse output of the udp module;

Modules are loaded in the order the -p option appears.  The headers from
each module are put immediately inside the headers from the previos model in
the final packet.  For example, to embed bgp inside tcp inside ipv4, do
sendip -p ipv4 -p tcp -p bgp ....

Modules available at compile time:
    ipv4 ipv6 icmp tcp udp bgp rip ntp

Arguments for module udp:
   -us x    UDP source port
             Default: 0
   -ud x    UDP destination port
             Default: 0
   -ul x    UDP packet legnth
             Default: Correct
   -uc x    UDP checksum
             Default: Correct

And for tcp , we have way more options;

Modules available at compile time:
    ipv4 ipv6 icmp tcp udp bgp rip ntp

Arguments for module tcp:
   -ts x    TCP source port
             Default: 0
   -td x    TCP destination port
             Default: 0
   -tn x    TCP sequence number
             Default: Random
   -ta x    TCP ack number
             Default: 0
   -tt x    TCP data offset
             Default: Correct
   -tr x    TCP header reserved field EXCLUDING ECN and CWR bits
             Default: 0
   -tfe x    TCP ECN bit (rfc2481)
             Default: 0 (options are 0,1,r)
   -tfc x    TCP CWR bit (rfc2481)
             Default: 0 (options are 0,1,r)
   -tfu x    TCP URG bit
             Default: 0, or 1 if -tu specified (options are 0,1,r)
   -tfa x    TCP ACK bit
             Default: 0, or 1 if -ta specified (options are 0,1,r)
   -tfp x    TCP PSH bit
             Default: 0 (options are 0,1,r)
   -tfr x    TCP RST bit
             Default: 0 (options are 0,1,r)
   -tfs x    TCP SYN bit
             Default: 1 (options are 0,1,r)
   -tff x    TCP FIN bit
             Default: 0 (options are 0,1,r)
   -tw x    TCP window size
             Default: 65535
   -tc x    TCP checksum
             Default: Correct
   -tu x    TCP urgent pointer
             Default: 0
   -tonum x    TCP option as string of hex bytes (length is always correct)
             Default: (no options)
   -toeol      TCP option: end of list
   -tonop      TCP option: no op
   -tomss x    TCP option: maximum segment size
   -towscale x    TCP option: window scale (rfc1323)
   -tosackok      TCP option: allow selective ack (rfc2018)
   -tosack x    TCP option: selective ack (rfc2018), format is l_edge1:r_edge1,l_edge2:r_edge2...
   -tots x    TCP option: timestamp (rfc1323), format is tsval:tsecr

Okay let's look at me crafting the following;

sendip -v  -p ipv4 -is -p tcp -tomss 6655 -ts 3400 -td 80 -ifr 1 -ii 1234

ip-ident         1234
ip reserved bit toggle on
Protol      #6 (tcp)
Source-port       3400
Dest-port    80
MSS          6655

I'm also sourcing this packet with my real ip_address, since my new provider has unicast verification enabled :(

A packet capture at the target looks  something like the below;

Internet Protocol, Src: (, Dst: (
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 44
    Identification: 0x04d2 (1234)   <--- ip.identification
    Flags: 0x08
        1... = Reserved bit: Set     <--------my reserved bit set
        .0.. = Don't fragment: Not set
        ..0. = More fragments: Not set
    Fragment offset: 0
    Time to live: 242
    Protocol: TCP (0x06)
    Header checksum: 0x71fe [correct]
        [Good: True]
        [Bad : False]
    Source: (
    Destination: (
Transmission Control Protocol, Src Port: 3400 (3400), Dst Port: 80 (80), Seq: 0, Len: 0
    Source port: 3400 (3400)     <----source port
    Destination port: 80 (80)     < --- destination port
    Sequence number: 0    (relative sequence number)
    Header length: 24 bytes
    Flags: 0x02 (SYN)
        0... .... = Congestion Window Reduced (CWR): Not set
        .0.. .... = ECN-Echo: Not set
        ..0. .... = Urgent: Not set
        ...0 .... = Acknowledgment: Not set
        .... 0... = Push: Not set
        .... .0.. = Reset: Not set
        .... ..1. = Syn: Set
        .... ...0 = Fin: Not set
    Window size: 65535
    Checksum: 0xea68 [correct]
        [Good Checksum: True]
        [Bad Checksum: False]
    Options: (4 bytes)
        Maximum segment size: 6655 bytes
   <----- MSS value

So if you are curious about ip packet creation,  and detection; " sendip is a must". Imho is simpler to use than scapy,  but with scapy you can do more get more done. For quick easy packet manipulation, nothings beats sendip. I will follow up with a post on scapy.

Ken Felix
Freelance Network/Security Engineer
kfelix    ---at--- hyperfeed ----dot---com

     ^       ^
=(  0   @ )=
      /  * \