Tuesday, December 30, 2014

Strange Behavior w/ ssh and cisco ASA 5558-x

I was playing around with some  scripting & trying to execute remote commands against a cisco ASA and found the following behavior.

  • it seems like you can't execute remote commands via ssh

  • if you apply any validate asa cmds the cmd will always fail regardless

  • the execution of remote commands against the appliance , will drop you in the non-enable mode prompt

  • if you than enter enable mode, your password would be echo on screen

Check this screenshot out when trying to execute a "ls"  and "curpriv"  against my  cisco ASA.





This behavior is not present with ciso IOS, IOS-XR , none of my juniperSRX or Fortigates firewalls. So  the ssh and remote shell execution seems to have a minor issue.


Have a happy 2015 and celebration from socpuppets!


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

     ^      ^
=(  @  @ )=
         o 
        /  \

The last of the ASA have been push to asa9.32 and asdm7.3.2

I've upgraded the last of my ASA-5558 clusters and rolled  ASDM-732 out across all devices. I mainly want to explore any backup/restoral options in the ASDM interface and didn't find any.




I was hoping to find a config backup and restore button in the main asdmn interface and so far I have seen any. At one time  I remember a backup option as early as 8.04 or the 1st gen 9.x codes and the ASDMs that was out at that time.






The release notes show the backup/restore is still suppose to be in the ASDM, but I didn't immediately find it. I hardly ever use the asdm due to the cluttering of the Web Interface and items aren't arrange in a very good to find method.




note:  The asdm onboard "help"  shows backup suppose to be still available , but maybe in multi-context mode, we don't have this option






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

     ^      ^
=(  @  @ )=
         o 
        /  \

Multi-Vdom can open you up to more risk on a fortigate ( configurations access or lack of )

Okay,  this will be my last blog post for  the year 2014. If you remember the following two earlier  posts ;

http://socpuppet.blogspot.com/2014/08/your-fortigate-is-not-as-secured-as-you.html

and

http://socpuppet.blogspot.com/2014/09/a-stacked-vdom-concept-with-fortigate.html

I will demonstrate how one firewall administrator  & in a non-Management vdom,  can actually grab the configuration for all other vdoms. This means the following;

  •   limited user of non-root-vdom can gather all other vdom cfg even regardless of your profile type

  •   users of a non-Management vdom can gather ALL other  cfgs including root-vdom or the   defined management vdom
Now keep in mind that all critical  users accounts details, radius secrets , local users details,  vpn PSKs , and other passwords are hashed for security reasoons. But any other firewall administrator in a muti-tenant vdom setup,  could actually gain access to ALL of the configurations details of his own vdom and any other vdoms that's present on the security appliance.

To expanded  on this, if the user is assigned a RO account, he/she can still gather all other configurations details.

1st let's look at my  user  "custA", he's assigned into custA-vdom  & as a firewall administrator. His profile is a RO profile.




So now we will  ssh into the  firewall or even use https access, all we really need ; " is to get to the cli console to execute our commands  cli  fnsysctl  commands "






A copy of the full  saved and running configuration is stored in local directory /data2/config. Yes, it's that obvious,  and the  unprotected firewall configuration file is present with a time/date stamp to show you the most up todate configuration file.



note: My RO user assigned to  vdom-custA can see the config cfg that has permissions set for anybody to read.

So what this means from a muti-tenant  use firewall ; " you place your other tenant configurations details out in open , and at risk of being  reviewed  by another user ( administrator ) who happen to  have cli access & via a simple cli command ( fnsysctl ) "

Okay the best way to prevent this type of access;

1:  assign the firewall as a FIPS mode (  fnsysctl command accces is eliminated in FIPS-compliant mode  of operations )
http://socpuppet.blogspot.com/2014/09/hardening-your-fortigate-firewall-by.html

2:  disallow ssh/telnet access for not root-Management vdoms interfaces ( taken away the console access via these management access methods )

and

3:  remove the jsconsole widget-type from non-Management vdom firewall administrators account
 ( taken away the console access widget )

e.g


config global
    config sys admin
         edit <username>
           config dashboard
          delete 3
end



What I thought was funny, Fortinet took  the time effort to protect you from deleting or copying the file to another directory or a usb mount point, but you still have full read-access view of the configuration file on the security appliance by using cat or more  with the cli command fnsysctl



If you do try to move or copy the file, you will be challenged with the "Admin" passwords for a valid administrator  within the management-vdom



Just keep in mind  to  control what the "actual firewall administrator has access to " and the cli command  fnsysctl,  can be quite dangerous. It's a cli  tool that can expose everything from  ssh/ssk keys and configurations details. The FIPS mode of operations can protect you.

note: I just one to point out, that in a cisco ASA running multi-contexts, this risk is pretty much eliminated. A  user can't access the system configurations files without  changing to the system context and most important he/she will the priv-level for enable.

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

     ^      ^
=(  @  @ )=
         o 
        /  \

Friday, December 26, 2014

Locking Down Fortigate Admin Access

I 'm going to show you a few tips for access controls and for controlling users access for the  firewall administrators on a fortigate security appliance.

One of the job of a firewall,  is for the means of controlling access at the system administrators level. Within the fortigate lineup,  you can control what interfaces that you allows for http, https, ssh,  snmp, icmp or telnet. These are all management type of services or protocols



Please don't use HTTP or TELNET and on a public facing interface. It should not be used at all due to lack of security

To allow just for ssh & ping on the interface named wan1,  we will deploy the following configuration;

config system interface
    edit "wan1"
        set vdom "root"
        set dhcp-relay-type ipsec
        set ip 12.212.22.77 255.255.255.0

        set allowaccess ping   ssh   <----here
        set ident-accept enable
        set type physical
        set alias "WAN public uplink"

    next

You can selectively set what services you allow per interface. On my DMZ interface I have the following ( http-secured ssh and snmp )

config system interface
    edit "dmz"
        set vdom "root"
        set dhcp-relay-type ipsec
        set ip 192.168.11.1 255.255.255.192

        set allowaccess ping https ssh snmp
        set ident-accept enable
        set type physical
        set alias "DMZ main"
    next



Now let's look at some cool tricks within the administrators settings. You can define time-based schedules for when a particular "admin" can actually login .

1st you set a firewall recurring schedule and then apply that per administrator account.

config firewall schedule recurring
    edit "always"
        set day sunday monday tuesday wednesday thursday friday saturday
    next
    edit "WORKWEEK"
        set day monday tuesday wednesday thursday friday 

        set end 17:00
        set start 09:00

    edit "MAINT-WINDOW1"
        set day   tuesday   thursday 

        set end 03:00
        set start 01:00
    next
end



Alternatively,  you can also create one-time schedules in a similar fashion. Great for a single use or for restricting a contractor access.

config firewall schedule onetime
    edit "MYBLOGken"
        set end 18:00 2014/12/26
        set start 17:00 2014/12/26
    next
end


The above will then be applied to a administrator configuration;

config system admin 
    edit  kfelix
            set schedule MYBLOGken
            set vdom root
            set accprofile super_admin 
        end

So now the user "kfelix" will be impacted by the schedule regardless if it's one-time or occurring. This is great for tech-support access or a contractor that has window for conducting his/her work.

I use the one-time  schedule a lot so I can configure and forget. I know after the time window has expired , that the user will not have any further access. Just be very careful on the access you give the user & how you  deploy schedules. You don't what a super_admin access having the ability to reconfigure his/her schedule 


If the user try to access outside of the scheduled time-window, he/she will be rejected;



Next, let's look at admin profiles. This one can create confusion,  but increases the complexity that you many offer for administrator access.

Admin profile are great for assigning read-only access or to allow limited  read/write functions within  the profile that you assign to the admin. You can only ASSIGNED one profile per user account, but you can define numerous account profiles known as " accprofiles ".

Here's a sample of the options in a  profile configuration as shown from the WebGUI;


You control the items above and then apply the profile to the users that your desire. The below profile is what I allow for my security ops team to  look at systems statistics alone



 you can set administrator profiles to be global or vdom




config system accprofile
    edit "tvdom1"
        set scope vdpom  
<---HERE
        set sysgrp read
        set netgrp read
        set loggrp read
        set wifi read
    next
end


Okay for the last grand finale event, ipv4 or ipv6 trusthost can be applied for each "specific" user account.  This allow you to allow remote users access based on the "sourced ip_address"

Look at the following examples for the users;

config sys admin
 edit "user1"
        set trusthost1 10.10.80.12 255.255.255.255
        set accprofile "myadmingroup1"
        set vdom "root"

        set password  blahblahblah
       next 
edit "user21"
        set trusthost1 10.10.80.12 255.255.255.255

        set trusthost2 10.10.90.0  255.255.255.0
        set accprofile "myadmingroup1"
        set vdom "root"

        set password  blahblahblah
       next 
edit "socuser1"
        set trusthost1 10.10.80.12 255.255.255.255

        set trusthost2 10.10.90.0  255.255.255.128
        set trusthost3 73.26.220.1 255.255.255.255
        set trusthost4 10.10.0.0  255.255.255.248
        set accprofile "mysocusers"
        set vdom "root"

        set password  blahblahblah
       next
edit "socuser"
        set accprofile "limited"
        set vdom "root"

        set password  blahblahblah
       next

All of the above users accept the "socuser" will be matched at the L3 source address. If you don't match the trusthost address or range, your login will not succeed. In all case the set  accprofile<named>  will be applied for each user.

Hands down, the fortinet security appliance works with flexibility and access controls. No other security firewall product allows for controls to this degree.


Key points to take away;

  •   by the applying administrators account profiles , you can control advance read/write access to various systems objects ( firewall policies, logs, system information, ips, etc....)
  •   schedule can be crafted but must be applied the CLI  level for users ( by default no schedule is applied or the general anytime/always is applied )
  •   trusthosts or ip6-trusthost (ipv4/ipv6 )  can really help control access at the network layer ( based on source )

 with time based schedules make sure you use ntp and ensure that your firewall is ntp synchronize. You can use the  get system status and diag sys ntp commands to validate time and if ntp time-sync is enabled




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

     ^      ^
=(   *  * )=
         o 
        /  \



Monday, December 22, 2014

Android 5.0.1 upgrades

My nexus10 tablet was migrated to 5.0.1, I didn't have  any issues with  5.0, but took the dip into 5.0.1





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

     ^      ^
=(  @  @ )=
         o 
        /  \

HP iLO app

I want to comment on the HP iLO mobile app. I used it the 1st time today for configuration a hp pl360 g8 server and the app is good quality.

With a big tablet like a 10" or larger and a BT-keyboard, you can easily access the KVMoIP and perform full administration of a HP server.

Here's the guide link
 http://h20565.www2.hp.com/hpsc/doc/public/display?docId=emr_na-c03195498



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

     ^      ^
=(  @  @ )=
         o 
        /  \

Some Cool stuff in cisco ASA 9.3 release

I want to point out some new features that cisco just introduce in the new 9.3 asa-code


1st , the ASA1000v  virtual firewall has support for KVM.  In my SRX  vrs ASA comparison post, this was one item that I mention that was lacking



Next, here's a few items in the 9.3 release

  • BGP ipv6 support

  • image signing & verification ( that's interesting & needs more investigating)

  • interface-group for load-balance and ECMP ( this is probably to  combat fortinet virtual-wan-interface concepts )

  • systems backup and restore commands ( this is another commands that needs further investigations )
 So that's a few of the items that caught my attention



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

     ^      ^
=(  @  @ )=
         o 
        /  \

ASA 9.3.2 upgrades whent smooth

I took the dip and upgraded a  Cisco ASA5558-X cluster to 9.3.2. This went smoothly and allowed me to test the backup command

The upgrade messages after upgrading one peer.


Now here's the backup in operation. It was quite simple to execute, just type "backup" and the context that you want to backup.

NOTE: this ASA cluster is running in multi-contexts



This created a file name <FW-name-context-date>.tar.gz  in the default disk0 storage analyzing the tarball shows the following files;

The file named "Version.Properties" is just a version file with a single line entry.


So that's it for  9.3.2 it was a simple upgrade from  9.3.1 and so far nothing looks out of ordinary. I will run the asdm later and look for any backup tools and options within the asdm. I believe I will need to check the asdm release for the latest asdm version.

I didn't do a restoral, the restore operation look simple also.

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

     ^      ^
=(  @  @ )=
         o 
        /  \

Thursday, December 18, 2014

Juniper SRX vrs cisco ASA

I think I get ask what's the better firewall between these 2 vendors at least every month now.

It's a hard question to answer, but I would like to point out just some of the few differences that you should be aware of. This comparison list is not 100% complete,  and is just a few of the highlights that I've found or crossed when designing and deploying security gateways for enterprises and service-providers networks.

1st I would like to say,  neither vendors are a slam dunk in all categories,  but many  differences exists  between these 2 platforms. Both of these platform could be very well become a  multi-box solution if you need advance security services and to take advantage of UTM features.




======================================================================

The SRX  is used in every sector from SME to Enterprise, but is not well received like that of the cisco ASA and the former PIX. You will probably find more cisco ASA products out on the streets, and that's because cisco is better at peddling the ASA, than what  juniper is at selling the SRX. But keep in mind, the meer more appliances ( volume )  don't always mean better. I 'm sure there's more Hyundai KIA cars on the streets of NYC than the Mercedes Benz, but that doesn't make the KIA a better car over the Mercedes.
^
 PRO cisco ASA widely used &  more than SRX in the NA/EU markets more support and more Security Engineers aligned with cisco

The Jweb WebGUI interface is integral, you do not need an "asdm"  package software like that of a cisco ASA. The jweb runs okay, but it's not speedy as the cisco asdm and this more evident under the smaller branch series models, ( think a tortoise  vrs a rabbit ). I tried to avoid the jweb at all cost, 78-92%  of the time  I'm in the CLI. This holds true on the cisco ASA, but I don't have any real complaints with ASDM accept it's awkward for me to use.
^
 PRO cisco ASDM

Junos works, but some of the basic features somethings ; just don't work, and when they don't work; "  it a very bad outcome ". ASA has been slightly better with asa code and it has been a more stable within the codeset from my experiences. JTAC will resolve the issues and identify the problems but you could struggle to get the resolution.
^
 PRO cisco ASA for stability in the OS releases

Routing features, the ASA is a few years behind the SRX ( period ). No need to go further in this area. Juniper has shared a lot of the routing features in the SRX  & from the M series. The cisco folks are still playing catch-up.
^
 PRO juniper SRX for routing and advance L3 unicast/multicast support

Config archival and rollback,  hands down a  SRX has better diff controls on cfg and retsoral. I really wish cisco would make improvements in this area. Change controls and configuration commits and restores is not very well planned in a cisco or to recovery.
^
 PRO juniper SRX cfg management and control points locally within  CLI


IPV6 support, more mature, better and  much stronger in a SRX
^
 PRO juniper SRX IPV6

For WAN interface models or  add-on WAN interfaces, hands-down the SRX leads the pack in this area. Your not going to get a E1/T1, ISDN, 3gCelluar  or  ADSL interface in a cisco ASA, but you can easily do this with a cisco ISR and their security ios codeset.

In fact cisco off-load these lacking features to a cisco router as a quick sell and pitch to the end-user, but they forget to tell you  that the router is not going to be as quick or have high thruput as the firewall.
^
PRO juniper SRX WAN availability

For services restarts ( daemons )  the SRX is hands down better. In a ASA, you have very little to no means to restart a services for the most part. If it stops, you need the reboot the appliance to get it rolling again.
^
 PRO juniper SRX services managements start and kill


The https/ssh  allow-access is much easier to deploy in in a cisco ASA. Also the SRX is complicated with simple services enabling from dhcp to ipv6 neighbor-discovery and the various filter. When local source features and functions don't work,  9 out of 10 times it's due to the service filter.
^
 PRO cisco ASA for management access configuration

The SRX  has higher  port density than a ASA, in fact you have more ports and more 10gige ports than the top-end cisco ASA. I believe the  SRX was the 1st to offer  40gige  and  100gige interfaces iirc. This is not even on the grid or radar for our cisco ASA. Both the  40 & 100gige interfaces are foreign words for the cisco ASA  lineup ;)
^
 PRO juniper SRX for higher thruput and faster interfaces

The SRX allows you access to a limited shell. here you can do captures, execute scripts, and do stuff that you can do from the simple unix  sysadmin approach. For the cisco ASA ... this is not going  to happen.
^
 PRO juniper SRX  for the shell access

Software code upgrades or download.....The ASA is a breeze in  this area. The juniper requires more thought and preparations when doing systems upgrades.

^
 PRO ciscoASA for code deployment ( simple , sweet ,and to the spot )

For the  SRX SNAT, much easier to manipulate. Cisco requires a PhD to just about NAT any thing outside of a 1-to-Many ;)
^
 PRO juniper SRX NAT'ing

Firewall HA clustering is very straight forward in the cisco ASA and you need a PhD to figure it out in a SRX ;). Doing a ISSU is simpler and let's of an issues in a cisco ASA. I always recommend opening a JTAC case, and get a 2nd opinions on your maintenace-operation-plan for any upgrades when you have a clustered pair.
^
 PRO cisco failover creation and management

Integration into a l2/l3switch, will the cisco ASA has a firewall blade. But be careful and review what features are NOT  available on the blade.
^
 PRO  cisco integration for existing multislot chassis

The Cisco software virtual firewall has been out ahead of juniper Firefly, but one key plus here is that the juniper version  has support for KVM, where cisco is all VMware. If you have access to Junos software you can still get a 60day eval image for testing.
^
 PRO juniper SRX firefly

UTM features like Anti-Spam exists in a SRX but requires a license and is not available across all models. I believe that cisco ASA NGFW still don't have am on appliance AS/AV UTM feature. Most of any UTM features in a cisco ASA 5558-X will be external or a cloud based solution  & at some extra-license and cost. 

Application visibility is a big weak spot in the cisco ASA, where-as  Juniper AppSecure is available but not refined as let's say  PaloAlto or Fortinets , but it works and can be buggy in earlier JunOS codes. Also Juniper AppSecure is for a higher end model SRX and is not available across all platforms. Cisco has recently  bought and now includes FirePower, but little information and use can be found about it's accuracy in application visibility.
^
 PRO juniper SRX for application awareness but still is not a single-box solution , & neither is the cisco ASA

Layer3 and 4  attack mitigation is slightly better with Juniper "Screens" in the SRX. At least the concept and controls are better.
The Cisco ASA will probably need a few ACL and service policys or other methods. Everything in a SRX is "security screen" single line configuration item.
^
 PRO juniper SRX for simple L3/4 flooding and L3/4 based attacks

GRE tunneling support is available in a SRX and not even an options in a ASA.
^
 PRO juniper SRX for ad-hoc GRE tunnels or other tunneling-support

Multiple VirtualRouter instances is probably better designed within the SRX than the ASA 's multi-context. You don't need to reboot the  firewall when  deploying VRinstances  as what you need to do when converting from single context to multi-context or back in a  ASA.
^
 PRO for juniper on multiple instances support, design and exchange  of information between instances

Cisco TAC and Juniper JTAC have both declined in the past 5 years or so.Cisco still has a better RMA  process for relacement and delivery. Juniper has gotten better with Kb knowledge. It's still hit & miss on each person feedback  and experience with working with these 2 outfits, but cisco has a slight edge.
^
 PRO cisco

For SSLvpn , we have the availability in the cisco ASA for ipv4/v6 sslvpns, but still the SRX has no means for SSL based vpns.  For Juniper, you will need a SecureAccess appliance or a MAG, which is yet another box.
^
 PRO for cisco ASA on webvpn availabilities integral to the appliance


Speaking of SSLVPN, the Juniper SA/MAG is a cheaper solution for SSLVPN users. The average cost for example with a  SA2500  vrs the  basic 100  cisco-ASA-webvpn license will place the  Juniper SA/MAG appliance cheaper per sslvpn-users.
^
 PRO juniper per sslvpn seat cost


======================================================================


Okay that's a wrap on my SRX vrs ASA comparison. Keep in mind, they both offer great firewall in the security  realm & the sectors they serve. To be fair,  don't try to think of "which one is better", but look at what's your need and them decide after doing a 1-to -1 comparison and cost analysis.

With these appliances, you have understand that the Juniper SRX is a zone-based firewall &  where the cisco ASA is a  ACL based filter firewall. They do the same thing, but the concepts are very different. There's pro/cons within these 2 strategies  but that another thread and only become a factor when you have dozens+  of interfaces or more.

lastly,  I hate the cisco/juniper shops that only expect one vendor to be present from switching/routing./firewall/others services. Some of the best networks that I ever worked  and consulted  for, where a mix of everything from A to Z.

Ken Felix
Freelance Network/Security Engineer Mail Security Specialist
kfelix  -----a----t---- socpuppets ---dot---com

     ^    ^
=(  % $  )=
      @
      /   \

Wednesday, December 17, 2014

howto: change the ssh encrypted private-key cipher

I was working on a site-security-checklist,  and one of the requirements was to use aes256 encryption.

Will one thing that was flagged on our initial audit,  all local users  ssh-key private-keys where set for  aes128cbc.

So I will show you how you  can use openssl to change the  private-key key encryption cipher that's set on your key. 1st let's create a rsa and dsa  keypair that's  passphrase protected ( encrypted )

As yo can see the  key  has been encrypted with  AES-128-CBC by default for this host.







Okay so now we have the private-key crafted, and encrypted with a passphrase.

Please use a strong passphrase in real life, socpuppets is not a strong passphrase


So to change the encryption to aes256, we need to read the  private-key back in and write it back out and while specifying a new passphrase



and validation;



So that's how you can change the encryption format for your private-key. Keep in mind the passphrase length and format is really the most secure item when it comes to a private-key. You should avoid des and 3des if possible

Pick a good length and mix it up;

bad  ==  socpuppets , 123456, changeme, password
good ==  " Security Is a MVst" , "I'm B88l3t Pr00f & Hack Pr00f!"





Ken Felix
Freelance Network/Security Engineer Mail Security Specialist
kfelix  -----a----t---- socpuppets ---dot---com

     ^    ^
 =( 1  1  )=
      @
      /   \

Monday, December 15, 2014

Happy Holidays from SocPuppets


I just want to say;

" Have a  happy  holiday seasons &  be safe "

And finally, remember the network attackers don't sleep or take off.


Ken Felix
Freelance Network/Security Engineer Mail Security Specialist
kfelix  -----a----t---- socpuppets ---dot---com

    ^    ^
=(  |   |  )=
      @
      /   \

Saturday, December 13, 2014

Hardening your unix ssh-server access ( howto by socpuppets )


howto
  
Here’s a quick and dirty ssh-server security improvement howto . Most of these settings are done within the sshd_config file similar to the following file;

# Package generated configuration file
# See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for
Port 2022
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::

ListenAddress 1.1.1.1
ListenAddress 1.1.1.3

 Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 1024

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin no
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile    %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
#PasswordAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding no
X11DisplayOffset 10
PrintMotd yes
PrintLastLog yes
TCPKeepAlive yes

UseLogin no



sshd_config
==============
1st
deny ssh  protocol version#1 support, it’s weaker and prone to abused.
  Protocol 2

==============

Now craft RSA keys with a minimum of  4048bit
ssh-keygen –t rsa –b 4048

Install the key in your correct location for the sshd daemon config. Also, if possible, deploy ECDSA keys  with sha1 and shas256  ( use ssh-keygen -t to specicy key  type )
==============

Remove & disallow rootlogin via ssh
 PermitRootLogin no

==============

Just allow only specific users that needs access via ssh.
 allowUser kfelix1 kfelix2 kfelix2 admin1 database user1 remoteAdmin1 remoteAdmin2

==============

Disable password logins
  PasswordAuthentication no

==============
 
Set SSHD listener to ipv4 or ipv6  or both if required, don't run it blindly on both stacks unless required

==============

Disable empty passwords logins

PermitEmptyPasswords no
==============


With multihomed machines, set the SSHD listener on just the interfaces that's required for ssh. Avoid using 0.0.0.0 ( any )


 ListenAddress  1.1.1.1

==============

Set strict modes for directory checking  to  yes

StrictModes yes

==============

Lastly, if you want to be slick, modify the OpenSSH source code and allow only the ciphers that your want and eliminate potential weaker ciphers.
The source code file  cipher.c file lists the ciphers



Alternate you can set the cipher list in the sshd_config file

Ciphers aes256-cbc,aes256-ctr, blowfish-cbc,aes256-cbc


I personally would strike des and 3des, Don't know what clients still support des, but you are not serious if you allow des imho ;)

============== 

Always deploy firewalls policies to allow what needs access to ssh-servers or use iptables locally. If on a public access network and you have to use  port22, deploy a fail2ban  or similar, but be advise this could lead to valid accounts being block


For  openssh server sources  try the following ftp site;

ftp://ftp.fr.openbsd.org/pub/OpenBSD/OpenSSH/portable/


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

    ^    ^
=(  +  -  )=
      @
      /   \

Thursday, December 11, 2014

Signing files with openssl and s/mime

Okay here's my signing datafiles via S/MIME ( Secure/Multipurpose Internet Mail Extensions ). Openssl has the ability for signing files using S/MIME. In fact it's  as easy as 1-2-3 to sign & verify a file.

S/MIME is commonly used in SMTP and mail-messages but the use has grown from just doing mail. It's probably one of the more commonly used encryption for mailsystems that use a CentralAuthority for certificates. It 's  widely used by mail-servers and clients and it's  one of the best & probably better suited for the general user  than PGP for end-2-end mail security.

note: If I didn't use PGP, I would use S/MIME for mail security

Now, to sign a datafile, the sender ( signer ) will need the following;

    1: certificate 
    2: the private-key for the certificate we will sign with
    3: and obvious the datafile ( message, text,binary......)

On the receiver side of things ( recipient ),  he/she only needs the certificate or access to the certificate.

And if not obvious, the private-key stays private with the signer.

Okay so let's look at my sender, and the files we have on my host SOC01. SOC1 will sign a file and then we verify it on another machine.


Okay,

We have the certificate labeled as "mycert.pem" and the private-key, plus the datafile named "file".
We will sign the datafile with the certificate and key. The file named "file",  is a simple text file



This process creates the signature which holds the original data along with attach signature. The cool thing about this, the file named "file" was a text file.

So we can open  the file.smime_sign and see the begin and ending parts of the signature and the original file. The lines between "------D0EC78ECFEFE5115C43A0E08FEB87DE8" will contain our original data.  This is known as the boundary and the 1st line in the file gives you details on the ; content-type, sha version,  boundary, etc.....





The verification process on the receiver is very simple, we only need the file and certificate and we reverse the process of the signing.



note: this was a self-signed certificate and not issued by a CA

Now the cool thing about this process, if the datafile was corrupted or tampered with,  the verification will always  fail.  The same for if  the certificate was corrupted or the wrong certificate was used during the verification, openssl will complain  with an "Verificiation failure"  or   "Error loading file ....."


Now , let's look at what happens when we add one whitespace to the signed.filed and try to re-verify the signature.


Signing ensure that the recipient knows with 100% confidence that the holder of the certificate sign the file. This can't be  repudiate. Also with the  passphrase assigned, the owner must know the passphrase used with the private-key and certificate.

So  signing  and verification is simple. Key points to  keep in mind;

  • the private-key is critical and needs to stay private
  • the signer is protected by the private-key and passphrase
  • signing  and than verify, that the author indeed  is the author
  • if your signing a binary file and not using -binary, the signature will be dettached


Ken Felix
Freelance Network/Security Engineer Mail Security Specialist
kfelix  -----a----t---- socpuppets ---dot---com

    ^    ^
=(  !  !  )=
      @
      /   \

Should you be parnoid with a voice response systems? ( hell yes! )

From a security standpoint, the telephone usage  while dialing up to a bank customer service center  is greatly overlooked.

The common practice of entering digits while dialing or access your account  with a bank by phone system, or voicemail, insurance company, etc...... should not be taken lightly.

Most of today modern systems have a IVR/IVRS ( Interactive Voice Response System  ) systems that "improves" you access to account information , and eliminates human interaction , but put's your  at risk. We use these in a regular duty/roles/function.

e.g ( a typical  IVR menu.. I bold some sensitive details )
  1. dial # 1 for ingles or #2 for spanish
  2. dial your  4 digit pin
  3. dial the last 4 of your SSN
  4. dial your DoB
  5. dial 1 to get your balance
  6. dial 2 to speaker to a customer service representative
  7. dial 9 or hangup to complete this call 
  8. or dial # to return to the start of the menu

This is good for the banks/hospitals/insurance companies/onlineshopping outlets, but the end-user needs to be aware that this is not secure.   Even the banks reps have you provide even more account details, by requesting more information about you. This place more sensitive data out in the air and over the call paths.

e.g ( a typical dialog of an unsecured transmissions to bank XYZ )

Hello , I'm Jane at Bank Blah Blah your today's customer-service representative
I need you to tell me your security code or password
can you provide your mother maiden name
Can you confirm your zipcode that's on-file
Can you give me the account digits
Thank you , now how can I help you ?

Yes, we provide all of the above and don't bat an eye & never suspect that evil joe is capturing your transmission.

My parents for example, hate using the phone and internet  for conducting ANY business & they have valid reasons. They are also old and afraid of technology, which is another story.

1st the digits you transfer to the IVRs are  typically in the media path and can be capture and decoded with ease. So a hacker ( unethical ) could gather your information. This means any of the following;
  • SSN
  • DOB
  • ACT#
  • PIN
  • CreditCard #
  • CVV code
  • zipcode 
  • etc.....
Yes with analog trunk or  VoIP trunk systems, the DTMF tones can easily be captured. So think twice when you dial your bank up and the potential harm that could come about if a MiTM captures your details.

The same holds true for a voicemail system. Entering your account details on a call to a IVR is about as secure as you " saying it our loud  & in the open on a  business  NYC street corner in uptown Manhattan " ;)


NOTE: When I was younger and dumb, we regularly capture DTMF tones from various VoiceMail access systems  when I was communication specialist in the military. And then we would hack a person VoiceMail or delete messages for fun ;) 

We would also intercept random numbers and calls to ensure COMSEC was being used.






http://en.wikipedia.org/wiki/Communications_security 
"loose lips sinks  ships !"

Nobody in a military outfit would discuss a classified pending military operation over an unsecured phone or radio, but to a lesser degree, we pass out our personnel details over a phone without thinking twice.

NOTE: Most of the banks, provide a calling_party number lookups to see if the number is present in the personnel account, but this with someone gathering the last 4 of the SSN , DOB, ACT#, etc...... but your still exposing critical information.

The best system would be fully-enclosed and 100% secured from end-2-end , but the TDM and SIP trunks to include the gateways would be un-secured & if no encryption was provided end-2-end. Also you have NO IDEAL if encryption is/was  used for any paths or legs of that call.

The diagram below will show you a typical multi-call path and the risk at each leg is very high. You call might terminate thru 3 or more carriers or nodes.

e.g


So any path between you and the IVR is at risk of tapping. The ole hollywood movies with the guy on the telephone pole wiretapping a call is now made even simpler with VoIP.

Now for the bad news, we have no way to know the  security that used on call unless you had  your own STU or similar device on the call  & at both ends of the call ( caller and called parties )

note: Read about a STU here; http://en.wikipedia.org/wiki/STU-III

So we know that's not going to happen, so you are S%#$T our of luck.

Even a facsimile transmission can be capture and decode to reveal  the document details. So that application form you fill out and fax in with your details, can be decode with ease. This means any of the following;

 DOB
 SSN
 address
 place of employment
 etc......

Your at risk & the sad thing, the Public Telephone Network is probably bigger than the Internet.



A few common voip security tools/method

for cpature dialed numbers using DTMF :  tshark -R 'rtpevent'
( https://www.wireshark.org/ )

faxscan or fax decoder for capturing T.38 modem transmission ( http://www.vocal.com/specialties/t-38-image-extraction-library/ )

faxTap ( http://www.netgencommunications.com/ )

wireshark/tshark for RTP streams analysis
( https://www.wireshark.org/ )
 
poing media grabber


In conclusions most enterprise site2site voip systems have much ease with securing calls end-2-end due to the nature of less devices out of control of the operator. You have less devices and can actually encrypted the path end-2-end ( phone-2-phone or between VoiceGateways )



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

    ^    ^
=( &  ! )=
      @
      /   \