The fortigate sizing app

The forticlient app on my tablet has a "find my fortigate"  tool  that allows you to set basic  requirements and the application will find the models that matches these requirements.

Requirements can be items IPS/VPN/AV  thruput speeds and even wireless security &  interface support for 10gig. The application only provides the match models, but you will still need to do a side-by-side comparison of the listed models to determine the final model for your implementation.

Here's a few photos  from the android-app

Ken Felix
NSE ( Network Security Expert) and Route/Switching Engineer.
kfelix  -----a----t---- socpuppets ---dot---com

    ^     ^
=(  *  * )=
        o 
       /  \

cisco tac android app

I broke down and installed & tried the  cisco tech-support mobile app. This is a good approach  for support and  providing customers access to the vendor support portal.
 

https://play.google.com/store/apps/details?id=com.cisco.swtg_android&hl=en

We have apps for  everything from weather, news, food sport, airline status, hospital appointments, movie info, ......." heck why not support ? "


I push this andorid app &  installed it on a Samsung Galaxy 12.2" tablet for trial and my 1st attempts at login was a failure.

But soon I was able to login and review support contracts, review open/closed cases & in the same fashion as that of the web acces. I didn't try to open a new case but it looks like you will need to know the serial # and complete some simple search to find the device.

I'm sure plenty of other vendors will start offering a mobile app support tool & the future will see more customer interface tools design around the mobile end-device.


Ken Felix
NSE ( Network Security Expert) and Route/Switching Engineer.
kfelix  -----a----t---- socpuppets ---dot---com

    ^     ^
=(  *  * )=
        o 
       /  \

smtp-mailhost honeypot

I've been working on a mail honeypot for the last year or so. The goal was to analyze  smtp-auth failures on a dummy mailhost that;

        1: I never had any MX/A/TXT/SPF record installed ( the ISP did install generic PTR )
        2: never sent any email 
        3: never received email under any official means

My top smtp-auths failures are show in this simple ms-excel graph.

 The graph here's shows % by continents using a geo-IP lookup  and  against  the 7 continent model

Now to summarize,

• I took total failures  and reduce any duplicates ( address )  so these where unique event for each user

• Asia was  the #1 continent by geoIP lookup

• The "Administrator" was the #1 account that failed

• The ideal was taken from  the honypot folks at  https://www.projecthoneypot.org/

My future goals are to extract the data for developing timed ACL for  repeat offenders. I also want to explore ipv6 mail-abusers to see if this issues exists in the ipv6 domain.

On a different approach I have a few domains being used for email-traps, this is another means for trapping and luring  abuser in regards to mail. The abuser are so blunt  the trap emails have email address such as ;  dontsendmemail@mydomain.com or similar , and the abuser still send spam email.

My hyperfeed.com domain which was a big target when it was productive back in the later 90s early 2000s is still receive spam emails to various emailserver but yet it has no MX record.

Btw, me and a few friends are setting up a ipv6 only honeypot & for tracking in the next few weeks on a virtual machine to see if we get any hits.

The ideal that if a you have a honeypot & that it ( address ) was never publish and folks are attempting to relay thru you, they are most likely up to no-good

SMTP/POP  honeypots are great for trending and general awareness of abusers. This approach can  be used for both personal awareness & knowledge , of just to see how rampart  mail-abuse exists.

Ken Felix
NSE ( Network Security Expert) and Route/Switching Engineer.
kfelix  -----a----t---- socpuppets ---dot---com

    ^     ^
=(  *  * )=
        o 
       /  \

FTNT blog ( fortinet )

Fortinet has a blog that 's pretty well laid out. Here's the link for the Fortinet blog

http://blog.fortinet.com/

This following blog entry caught my eye about bots and C&C within http.Status-Codes

http://blog.fortinet.com/post/hiding-malicious-traffic-under-the-http-404-error

Enjoy

Ken Felix
NSE ( Network Security Expert) and Route/Switching Engineer.
kfelix  -----a----t---- socpuppets ---dot---com

    ^     ^
=(  *  * )=
        o 
       /  \

cisco ASA 9.4.1

Will time has came for ASA code 9.4.1. Here's the one striking new feature that caught my eye. It has been out for some time now , so I was  decided to kick the tires and to upgrade a cluster of firewalls to this new version.


NOTE: PBR has finally landed in the  cisco software version

The migration path is quite simple from  version 9.3.x.

I was hoping to see  more new introduced features for ipv6 and routing, but I guess we have to wait for a later  asa9.4.x release.

So far,  no big reveiws on the 9.4.1 cisco asa site. This could be a big or small thing. I've only found one review posted on CSCO.

Ken Felix
NSE ( Network Security Expert) and Route/Switching Engineer.
kfelix  -----a----t---- socpuppets ---dot---com

    ^     ^
=(  *  * )=
        o 
       /  \

TFTP blocksize ( be aware)

TftpServers and various network devices such as cisco routers and switches, some time has problems with tftp transfer if the blocksize is too small. Typical tftp uses a blksize of 512bytes. What this means, the max file chunk is configured at 512 bytes

NOTE: The size of the block will effect the overall transfer rate ( greater much quicker , lesser much slower )

Take this screenshot of a typical file size with the  blocksize against a tftp-server running on a macosx machine

Here's a tftp-server running on a cisco 2960 switch with various blocksizes defined by the client from 8 bytes to 9128 bytes

Okay so await a minute, we adjust the  client requested blocksize from 8 to 9128 bytes but the transfer speed for the same file-size of 7075041bytes stayed the same. A dump of  the packets during the tftp transfer will show that the blocksize was set only to 512bytes;

e.g

So no matter what the client requests, the block sent by the tftp-server was only set to 512bytes. So if I change the client to operate in binary mode, and request the file we also find out that the  tftp-server ( cisco ) ignores the requested blocksize and set all blocks served at 512bytes


e.g

So keep all of  this in mind when your complaining about why a tftp transfer takes so long.


Ken Felix
NSE ( Network Security Expert) and Route/Switching Engineer.
kfelix  -----a----t---- socpuppets ---dot---com

    ^     ^
=(  *  * )=
        o 
       /  \


Ken Felix
NSE ( Network Security Expert) and Route/Switching Engineer.
kfelix  -----a----t---- socpuppets ---dot---com

    ^     ^
=(  *  * )=
        o 
       /  \

ubuntu upgrades

This week I'm snap-shoting images for a ubunti upgrade. This will be interesting to see if any problems develops.

I' been running Precise now for some serious time.

Now we need to explore 14.0 ( trusty/tahr ) to start giving it a spin. I suspect this upgrade will be fault less. http://releases.ubuntu.com/14.04/

Ken Felix
NSE ( Network Security Expert) and Route/Switching Engineer.
kfelix  -----a----t---- socpuppets ---dot---com

    ^     ^
=(  *  * )=
        o 
       /  \

NXOS commands stringing

Since NX-OS is unix-like;  we have a simple trick for stringed commands. This can be helpful in scripts or other automated activities.

The stringed the commands allows you to group together one single line of commands that are execute one after another.


E.g a typical expect script might have the following;

expect "NXOS2"
send -- "term leng 0\r"

expect ""
send -- "conf t \r"

expect "NXOS(config)#"
send -- "push top ; int eth 1/1 ; load 30 ; int eth 1/2 ; load 30 ;  int eth 1/4 ; load 44 ; int eth 1/9 ; load 30 ; int eth 1/19-20 ; load 30 ;  pop ; do copy run start\r"

Here's an example from a screenshot;

NOTE:  Stringing commands is great when you have a series of commands to execute at one-shot or session.

Here's a sample expect script with cmd stringing in for the CLI

#!/usr/bin/expect

# usage getnxos.exp <user@host>  <password>

set timeout 10

spawn ssh [lindex $argv 0]

set pass [lindex $argv 1]

#

expect "word:"
send -- "$pass\r"

expect "SW2#"
send -- "term leng 0 ; show interface status ;\r "

expect "SW2#"
send -- "show inv | inc power ;  term leng 0 ; show run int eth1/1 ; show run int eth 1/24 ; show logging last 20 | tr \-d \"SW2\" \r"


expect "SW2#"
send -- "exit\r "
~                                                                                                                                                     
~                      

Ken Felix
NSE ( Network Security Expert) and Route/Switching Engineer.
kfelix  -----a----t---- socpuppets ---dot---com

    ^     ^
=(  *  * )=
        o 
       /  \

QinQ on Nexus 3524s

Will cisco confirm that dot1q-tunneling is not a supported feature under a 35XX nexus switch. The 30xxs support and IIRC the 5K also.

This is confirmed even under the latest code that 's available under the 6.0 family.

Ken Felix
NSE ( Network Security Expert) and Route/Switching Engineer.
kfelix  -----a----t---- socpuppets ---dot---com

    ^     ^
=(  *  * )=
        o 
       /  \

HOWTO license a Nexus SWITCH

This post will show you the few & simple steps with licensing a feature license on Nexus switch. The process is non-service impacting and takes approx 5 mins or  even less.


1st you need to find your license information as provided via the reseller. Take note of the circled info.

NOTE: The PAK is provided and will be applied to the device via serial #

Now, you need to  browse over to the cisco activiation website and fill in a few details such as the device PAK id and serial number of the device. You can use the "show inventory" cmd for gaining your system serial#.

Upon completion,   you will receive the license file in a zip format via the email associated to your CCO profile, just unzip the file copy the license.lic file to the device via SCP or some other means.

Now the fun part begins;

1:  make a backup of the running cfg ( copy run start ) and ( copy run bootflash:mybackup.cfg )

2:  backup your existing license via the  ( copy license  ) cmd;

note: the file-name specified has to end with an  .tar  extension or the system will fail.  If  you  try to backup against a name already defined, it too will fail also


3:  now you can install the new license that you copy to the device from bootflash or usb1; or wherever  you have it installed;

If you ever should need to remove a license, repeat the backup steps mentions above, but now use the following command;

Ken Felix
NSE ( Network Security Expert) and Route/Switching Engineer.
kfelix  -----a----t---- socpuppets ---dot---com

    ^     ^
=(  *  * )=
        o 
       /  \

VLAN cisco reservation internal usage ( thoughts )

With Vlan IDs  we have some that we  should be avoid & this issue bound to come up in big networks with hundreds if not thousands of vlans.

The following show command  under IOS/NX-OS will display these internal usage vlans;

e.g

show vlan internal  usage

If you try to configure a vlan that's used internally, you will have an error similar to the  below.

Now luck has it that cisco has created a means for reserving  vlans. It's sometime best to apply this practices in big SP/ENTERPRISE networks to avoid design issues  that could later conflicts with a reserved vlan.

Our socpuppets general thought has always been to craft vlans under the 4K range,  and build a vlan allocation sheet that you SHOULD always review b4 vlan allocations.

The "vlan internal  allocation policy ascending" or "vlan internal  allocation policy descending" commands can help in determining the internal vlan allocation methods.

NOTE: I believe this is a IOS command and not widely deploy under most  NX-OS switches.

Ken Felix
NSE ( Network Security Expert) and Route/Switching Engineer.
kfelix  -----a----t---- socpuppets ---dot---com

    ^     ^
=(  *  * )=
        o 
       /  \

NX-OS howto md5 check 3500s

On a nexus 3524 you can use the following means for file md5sum checking & file-image integrity. The size of the file will determine how long it takes to complete the md5sum verification.


show bootflash:<filename>  md5sum

E.g

NOTE : The NX-OS will also perform a image verification when setting the boot var

E.g

or you can execute the following;

E.g

Ken Felix
NSE ( Network Security Expert) and Route/Switching Engineer.
kfelix  -----a----t---- socpuppets ---dot---com

    ^     ^
=(  *  * )=
        o 
       /  \

SIP registering issues cisco ASA

In this blog we will look at a sip UA client ( X-lite ) and using the call centric services. One of the biggest problems with  SIP clients soft or hardware based ,  involves with the SIP  registrations.

A few reasons that can cause a SIP REGISTRATION or failures

•  bad sip domain specified at the client
•  username incorrect ( SIP register name = Sip.To ) 
•  bad  sip account password
•  the firewall filtering your protocol and ports ( TCP|UDP port5060/5061 )
•  ALG not enabled  nor fixing up the SIP header
• lack of re-REGISTERs or lack of SIP-KeepAlives
• severe packet lost preventing registering ( not common but could happen )
• you have trip the max registers per client or some Admission controls thresholds ( usually this is set at the SIP provider server/proxy )

Here's a SIP-register from my X-lite client on my MACOSX client

Now the firewall plays an important process. It must fixup the SIP REGISTER and mask the  SESSION details to match your public SNAT address if NAT is enabled between the UAC and UAS.

Obviously you must have firewall policies that allows the traffic outbound from your client to the sip server to begin with.

NOTE:  With the call centric the protocol for registering is done via SIP using defector udp/5080. Some clients will revert to TCP and even to ports 5060 |5061 as an alternative but you need to double each client and what the SIP provider is expecting. In my  X-lite and Callentric  they use 5080 which is typically the default for Sip clients that uses proxy-registration  versus a sip trunk Carrier which hardly uses SIP-REGISTERs.


For "Bad" authentication , is actually easy to determine if this has happen by monitoring  the SIP status-codes between client and server.

1   9.698676 10.200.41.89 -> 204.11.192.22 SIP 610 Request: REGISTER sip:callcentric.com  (1 binding) | 

  2   9.941065 204.11.192.22 -> 10.200.41.89 SIP 553 Status: 407 Proxy Authentication Required | 

  3   9.942312 10.200.41.89 -> 204.11.192.22 SIP 811 Request: REGISTER sip:callcentric.com  (1 binding) | 

  4  10.186344 204.11.192.22 -> 10.200.41.89 SIP 386 Status: 403 Incorrect Authentication | 

  5  15.373261 10.200.41.89 -> 204.11.192.22 SIP 610 Request: REGISTER sip:callcentric.com  (1 binding) | 

  6  15.633247 204.11.192.22 -> 10.200.41.89 SIP 553 Status: 407 Proxy Authentication Required | 

  7  15.635155 10.200.41.89 -> 204.11.192.22 SIP 811 Request: REGISTER sip:callcentric.com  (1 binding) | 

  8  15.883003 204.11.192.22 -> 10.200.41.89 SIP 386 Status: 403 Incorrect Authentication | 

  9  27.379048 10.200.41.89 -> 204.11.192.22 SIP 610 Request: REGISTER sip:callcentric.com  (1 binding) | 

 10  27.626802 204.11.192.22 -> 10.200.41.89 SIP 553 Status: 407 Proxy Authentication Required | 

 11  27.628884 10.200.41.89 -> 204.11.192.22 SIP 811 Request: REGISTER sip:callcentric.com  (1 binding) | 

 12  27.894571 204.11.192.22 -> 10.200.41.89 SIP 386 Status: 403 Incorrect Authentication | 

NOTE: It doesn't tell you what was wrong other than your authentication was incorrect. It could have been username,  password or both, remember the server & client are using a cryptographic nonce to ensure the password is hash to a value that can't be replayed. So if the domain is correct, just  rekey the username and password


Now with the cisco ASA, all we need to do is to ensure our  policy-map has sip inspection enabled and to ensure it's applied globally or on the interface.

Here's a typical ASA policy-map cfg;

policy-map global_policy

 class inspection_default

  inspect ftp 

  inspect h323 h225 

  inspect h323 ras 

  inspect ip-options 

  inspect netbios 

  inspect rsh 

  inspect rtsp 

  inspect skinny  

  inspect sqlnet 

  inspect sunrpc 

  inspect tftp 

  inspect xdmcp 

  inspect pptp 

  inspect ipsec-pass-thru 

  inspect icmp 

  inspect icmp error 

  inspect http 

  inspect snmp 

  inspect dns preset_dns_map 

  inspect sip  

 class internal_network

  inspect esmtp 

 class class-default

  inspect pptp 

  user-statistics accounting

You can use the following show commands to confirm inspect for SIP;

show service-policy inspect sip table

And for monitoring any flows

show conn protocol udp port 5060-5061 long

show conn protocol tcp port 5060-5061 long

or

show conn protocol udp port 5080 long

And you can monitor the expiration and refresh to get an ideal of how long your sessions are up and when they refresh, this should match the SIP keepalives intervals  for the UAC

UDP EXTERNAL02: 204.11.192.22/5080 (204.11.192.22/5080) TRUST01: 10.200.41.89/55589 (1.22.11.100/55589), flags - , idle 1s, uptime 8m18s, timeout 1m0s, bytes 17115

A few other items to think about, do you need 1> SIP re-REGISTER and  2>KEEPALIVES. The answer for this really depends.

But  SIP keepalives will ensure the firewall NAT/SESSION table stays active and does not expire from the  session list. It never hurts to enable a reason SIP session timer.  You can also get by with increase sessions timeout in the  cisco ASA for SIP for the session table

The show run timeout cmd will provide you an ideal for SIP sessions values

timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00

timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute

The choice is all yours on what you need to do, but be aware of the few listed issues that effects SIP registering  and how your Cisco ASA fits into the  picture.

Ken Felix
NSE ( Network Security Expert) and Route/Switching Engineer.
kfelix  -----a----t---- socpuppets ---dot---com

    ^     ^
=(  *  * )=
        o 
       /  \

tips "Fortigate logging for IPS attack events"

One of the biggest gotcha when using  the forties IPS sensor is the lack of logs  in the WebGUI. One easy mistake is forgetting to  enable logging for memory vrs foricloud

Next, you need to enable logging per IPS sensor event.

After your have done the above, you can now witness any Alerts within the log &report > security  from the main page.


Ken Felix
NSE ( Network Security Expert) and Route/Switching Engineer.
kfelix  -----a----t---- socpuppets ---dot---com

    ^     ^
=(  *  * )=
        o 
       /  \

Fortimail and cisco cables

In this post I will demostrate the usage of cisco cables SFP-H10GB-CU3M enlew of  SFPs for connecting a FML to a cisco 6509-E.

Most if not ALL Fortinet gear, is pretty much cisco compatible for ALL SFPs that I've used in the past.  You can pretty much use any standard  badged/labeled  cisco SFPs in fortunate gear and it will work.

Here's the  FML 3KD  configuration for the SFP slot interface in the back.

No on the switch I was surprised that cisco showed there own cables not compatible .

NOTE: I'm using the service unsupported transceiver commands on this switch btw.

service unsupported-transceiver

The  cisco gear works find and provides layer2 connectivity to the 3000D FML appliance

Ken Felix
NSE ( Network Security Expert) and Route/Switching Engineer.
kfelix  -----a----t---- socpuppets ---dot---com

    ^     ^
=(  *  * )=
        o 
       /  \