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

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;

2nd:

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  .....dot....com

   ^      ^
=( *  * )=
       o
      /  \

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

end

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
end


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;

etc.

• 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 192.0.2.1 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 192.0.2.1; the user =  "myuser", and we are using  version 3.

e.g
snmp-server  host 192.0.2.1  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

   ^     ^
=( *  * )=
       o
     /    \

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 10.0.18.11 in these examples )

   

sh-3.2$ sudo tshark -r active*close.pcap -R 'tcp.port==55876'

 21 15.184532000  10.0.18.11-> 64.124.19.179 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 64.124.19.179 -> 10.0.18.11 TCP 66 http > 55876 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1430 SACK_PERM=1 WS=128

 23 15.286279000  10.0.18.11-> 64.124.19.179 TCP 54 55876 > http [ACK] Seq=1 Ack=1 Win=262144 Len=0

 24 15.286337000  10.0.18.11-> 64.124.19.179 HTTP 205 GET / HTTP/1.1

 25 15.377931000 64.124.19.179 -> 10.0.18.11 TCP 60 http > 55876 [ACK] Seq=1 Ack=152 Win=6912 Len=0

 33 25.378766000 64.124.19.179 -> 10.0.18.11 TCP 60 http > 55876 [FIN, ACK] Seq=1 Ack=152 Win=6912 Len=0

 34 25.379010000  10.0.18.11-> 64.124.19.179 TCP 54 55876 > http [ACK] Seq=152 Ack=2 Win=262144 Len=0

 35 25.379271000  10.0.18.11-> 64.124.19.179 TCP 54 55876 > http [FIN, ACK] Seq=152 Ack=2 Win=262144 Len=0

 36 25.467514000 64.124.19.179 -> 10.0.18.11 TCP 60 http > 55876 [ACK] Seq=2 Ack=153 Win=6912 Len=0

sh-3.2$

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  10.0.18.11-> 15.193.113.27 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 15.193.113.27 -> 10.0.18.11 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  10.0.18.11-> 15.193.113.27 TCP 66 56154 > http [ACK] Seq=1 Ack=1 Win=131328 Len=0 TSval=816940561 TSecr=3823454198

  4 0.044447000  10.0.18.11-> 15.193.113.27 HTTP 208 HEAD / HTTP/1.1

  5 0.151665000 15.193.113.27 -> 10.0.18.11 TCP 383 [TCP segment of a reassembled PDU]

  6 0.151972000  10.0.18.11-> 15.193.113.27 TCP 66 56154 > http [ACK] Seq=143 Ack=318 Win=131008 Len=0 TSval=816940667 TSecr=3823454209

  7 0.152167000  10.0.18.11-> 15.193.113.27 TCP 66 56154 > http [FIN, ACK] Seq=143 Ack=318 Win=131072 Len=0 TSval=816940667 TSecr=3823454209

  8 0.198413000 15.193.113.27 -> 10.0.18.11 TCP 66 http > 56154 [ACK] Seq=318 Ack=144 Win=32768 Len=0 TSval=3823454213 TSecr=816940561

  9 0.198646000  10.0.18.11-> 15.193.113.27 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 15.193.113.27 -> 10.0.18.11 HTTP 66 HTTP/1.1 200 OK

 11 0.203732000  10.0.18.11-> 15.193.113.27 TCP 66 56154 > http [ACK] Seq=144 Ack=319 Win=131072 Len=0 TSval=816940715 TSecr=3823454213

sh-3.2$

sh-3.2$

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  10.0.18.11-> 140.211.167.51 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 140.211.167.51 -> 10.0.18.11 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  10.0.18.11-> 140.211.167.51 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  10.0.18.11-> 140.211.167.51 HTTP 207 HEAD / HTTP/1.1

  5 2013-06-22 23:40:09.330093000 140.211.167.51 -> 10.0.18.11 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 140.211.167.51 -> 10.0.18.11 TCP 255 [TCP segment of a reassembled PDU]

  7 2013-06-22 23:40:09.331584000  10.0.18.11-> 140.211.167.51 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  10.0.18.11-> 140.211.167.51 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 140.211.167.51 -> 10.0.18.11 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  10.0.18.11-> 140.211.167.51 TCP 66 56421 > http [ACK] Seq=143 Ack=191 Win=131136 Len=0 TSval=817520925 TSecr=2005662210

sh-3.2$

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  10.0.18.11-> 156.151.59.35 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 156.151.59.35 -> 10.0.18.11 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  10.0.18.11-> 156.151.59.35 TCP 66 56155 > http [ACK] Seq=1 Ack=1 Win=131872 Len=0 TSval=816946553 TSecr=1863626880

 15 6.126548000  10.0.18.11-> 156.151.59.35 HTTP 209 HEAD / HTTP/1.1

 16 6.249165000 156.151.59.35 -> 10.0.18.11 HTTP 203 HTTP/1.0 301 Moved Permanently

 17 6.249460000  10.0.18.11-> 156.151.59.35 TCP 66 56155 > http [ACK] Seq=144 Ack=138 Win=131728 Len=0 TSval=816946674 TSecr=1863627001

 18 6.249666000 156.151.59.35 -> 10.0.18.11 TCP 66 http > 56155 [FIN, ACK] Seq=138 Ack=144 Win=4433 Len=0 TSval=1863627001 TSecr=816946553

 19 6.249714000  10.0.18.11-> 156.151.59.35 TCP 66 56155 > http [FIN, ACK] Seq=144 Ack=138 Win=131728 Len=0 TSval=816946674 TSecr=1863627001

 20 6.249827000  10.0.18.11-> 156.151.59.35 TCP 66 56155 > http [FIN, ACK] Seq=144 Ack=139 Win=131728 Len=0 TSval=816946674 TSecr=1863627001

 21 6.354273000 156.151.59.35 -> 10.0.18.11 TCP 66 http > 56155 [ACK] Seq=139 Ack=145 Win=4433 Len=0 TSval=1863627108 TSecr=816946674

 22 6.354555000  10.0.18.11-> 156.151.59.35 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 156.151.59.35 -> 10.0.18.11 TCP 66 [TCP Dup ACK 21#1] http > 56155 [ACK] Seq=139 Ack=145 Win=4433 Len=0 TSval=1863627108 TSecr=816946674

sh-3.2$

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

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.

Fortigate;


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


#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
            end
    next
end

# 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
            next
        end
        config redistribute "connected"
        end
        config redistribute "rip"
        end
        config redistribute "ospf"
        end
        config redistribute "static"
        end
        config redistribute "isis"
        end
        config redistribute6 "connected"
        end
        config redistribute6 "rip"
        end
        config redistribute6 "ospf"
        end
        config redistribute6 "static"
        end
        config redistribute6 "isis"
        end
    set router-id 192.168.0.2
end

And the cisco;



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

and
 

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

And  now a few show cmds

 

 FG200A2106401308 # get router info6  bgp summary
BGP router identifier 192.168.0.2, 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

and


FG200A2106401308 # get router info6  bgp
BGP table version is 1, local router ID is 192.168.0.2
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
*>i2001:db8:100::/64
                    2001:db8::2               0    100   1000 i
*>i2001:db8:101::/64
                    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.

Next,

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>@socpuppets.com to  <anyuser>@gmail.com & 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;

O

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

    ^     ^
= ( *  * )=
        @
    

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.

3rd

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...

4th

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 :)

5th

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

     ^          ^
= (  @   @ ) =
           O
         /    \
 

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 .1.3.6.1.4.1.5387 include
set snmp view hypr5387 oid .1.3.6.1.4.1.2636.3.11 include
set snmp view hypr5387 oid  .1.3.6.1.4.1.2636.4 include
set snmp view hypr5387 oid  .1.3.6.1.4.1.2636.1.1.1.2 include
set snmp view hypr5387 oid  .1.3.6.1.4.1.2636 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  nms@hyperfeed.net

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;

e.g
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;


e.g

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

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

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


    ^        ^
= ( @    @ ) =
             )
        /   ~   \