MystaJoneS

If you're not making mistakes, then you're not doing anything.

  • The most sure-fire way to do this is to start a command-line session with the router, erase the startup-config and reload the router. The command syntax for that would be:

    router>en
    router#write erase
    router#reload

    *If you don’t have the login credentials for the router to get in, do this:

    -Start a terminal session with the router via the Console port (telnet will not work for this). Physically reload the router, and from the console repeatedly hit the “Break” key, normally on the upper right hand side of the keyboard.

    -You should now be in ROMMON mode. Type “confreg 0x2142” without quotes and hit Enter. Now type “reset” without quotes and hit Enter.

    -Allow the router to restart, and hit “n” followed by Enter to stop the startup wizard.

    -Type the following command sequence:

    enable
    conf t
    config-register 0x2102
    exit
    write erase
    <Enter key>
    reload

    The router will now boot normally, with a factory default configuration, even if you did not know any of the password(s) securing the router.

    +
  • Download PuTTY

    PuTTY is an SSH and telnet client, developed originally by Simon Tatham for the Windows platform. PuTTY is open source software that is available with source code and is developed and supported by a group of volunteers.

    You can download PuTTY here.

    Bitvise Tunnelier

    Tunnelier is an SSH and SFTP client for Windows. It is developed and supported professionally by Bitvise. Tunnelier is robust, easy to install, easy to use, and supports all features supported by PuTTY, as well as the following:

    • graphical SFTP file transfer;
    • single-click Remote Desktop tunneling;
    • auto-reconnecting capability;
    • dynamic port forwarding through an integrated proxy;
    • an FTP-to-SFTP protocol bridge.

    Tunnelier is free for personal use, as well as for individual commercial use inside organizations. You can download Tunnelier here.

    Bitvise WinSSHD

    WinSSHD is an SSH, SFTP and SCP server for Windows. It is robust, easy to install, easy to use, and works well with a variety of SSH clients, including Tunnelier, OpenSSH, and PuTTY. WinSSHD is developed and supported professionally by Bitvise.

    You can download WinSSHD here.

    +
  • Network Time Protocol (NTP) is used for network devices, servers and workstations to periodically correct deviations in the system time reported by operating systems through a synchronisation process. The protocol is designed to compensate for variable latencies in the network.

    Accurate time on network devices, servers and workstations ensures that timestamps tat are reported in log files such as the system log (SYSLOG) are within minimal tolerance, facilitating comparison of log entries between different systems and devices.  This is essential when an intrusion or security breach has been detected, and for a corresponding forensic investigation.

    For redundancy purposes, two or more internal time servers should be created. A list of publicly accessible and restricted-access time sources is provided by the Internet Systems Consortium (ISC) or dedicated time server can be implemented which can synchronise time via GPS or GSM networks.

    NTP should be protected using authentication to ensure that communication with NTP server cannot be interfered with.  An MD5 hash should be used was the authentication text.  Access Controls Lists (ACL’s) should be used on the nominated NTP server to limit which systems are able to update the time and which systems are allowed to synchronise from the server.  This is done with the ’ntp access-group’ command on Cisco devices.

    All Client XYZ network devices should obtain time from a centralised time source.

    Client XYZ to implement Network Time Protocol (NTP) capabilities within the network.  The internal time servers should synchronise their time with a known time source ever 1-2 days. It is recommended that a stratum 1 or stratum 2 server be used, or if one is not available, then a time source from Oceania pool is recommended.

    All network devices, servers and workstations within the internal network should periodically synchronise their system time with the internal time servers.  A synchronisation interval of less than 14 days is recommended to reduce the impact of clock drift on these NTP clients.

    + ,
  • While reviewing the ASA logs in relation to a large wireless metering project in WA, i came across a number of log entries that were just there (hundreds of thousands of them), so here’s how to disable them:

    %ASA-6-302013: Built inbound TCP connection……
    %ASA-6-302013: Built inbound TCP connection…..
    %ASA-6-302015: Built outbound UDP connection…..
    %ASA-6-302014: Teardown TCP connection…….
    %ASA-6-302013: Built inbound TCP connection ………
    %ASA-6-302020: Built outbound ICMP connection………
    %ASA-6-302013: Built inbound TCP connection……

    To exclude these types of log messages from being recorded. Simply login to the CLI and type the following:

    ASA#config t
    ASA(config)#no logging message 302016

    Each log message has a syslog-id which is the 6 digit number. If there are additional types of logs you want to block, simply repeat the command above for each syslog-id. Link to the massive list of syslog-id messages and their descriptions:
    http://www.cisco.com/c/en/us/td/docs/security/asa/syslog-guide/syslogs/logmsgs.html

    And the command reference:
    http://www.cisco.com/c/en/us/td/docs/security/asa/asa82/command/reference/cmd_ref/l2.html#wp1773284

    +
  • I thought i better just make a link to this guys website, to help with any future upgrades given I’ll need to.

    http://www.duppeditten.com/blog/qnap-ts-870-ultimate-nas-on-steroids

    +
  • http://www.cisco.com/c/en/us/support/docs/wireless/5500-series-wireless-controllers/115756-avc-guide-00.html

    AVC provides application-aware control on a wireless network and enhances manageability and productivity. AVC is already supported on ASR and ISR G2 platforms. The support of AVC embedded within the WLAN infrastructure extends as this as an end-to-end solution, which gives a complete visibility of applications in the network and allows the administrator to take some action on the same.

    +
  • A useful read around Cisco APs and Rouge Management.

    Wireless networks extend wired networks and increase worker productivity and access to information. However, an unauthorized wireless network presents an additional layer of security concern. Less thought is put into port security on wired networks, and wireless networks are an easy extension to wired networks.

    Click to access 112045-handling-rogue-cuwn-00.pdf

    +
  • In a CAPWAP environment, a lightweight access point discovers a controller by using CAPWAP discovery mechanisms and then sends it a CAPWAP join request. The controller sends the access point a CAPWAP join response allowing the access point to join the controller. When the access point joins
    the controller, the controller manages its configuration, firmware, control transactions, and data transactions.

    Lightweight access points must be discovered by a controller before they can become an active part of the network. The lightweight access points support the following controller discovery processes:

    • Layer 3 CAPWAP or LWAPP discovery — Can occur on different subnets from the access point and uses IP addresses and UDP packets rather than the MAC addresses used by Layer 2 discovery.

    • Over-the-air provisioning (OTAP)—This feature is supported by Cisco 4400 series controllers. If this feature is enabled on the controller (in the controller General page), all associated access points transmit wireless CAPWAP or LWAPP neighbor messages, and new access points receive the controller IP address from these messages. This feature is disabled by default and should remain disabled when all access points are installed.

    • Locally stored controller IP address discovery—If the access point was previously associated to a controller, the IP addresses of the primary, secondary, and tertiary controllers are stored in the non-volatile memory of an access point. This process of storing controller IP addresses on access points for later deployment is called priming the access point.

    • DHCP server discovery—This feature uses DHCP option 43 to provide controller IP addresses to the access points. Cisco switches support a DHCP server option that is typically used for this capability.

    • DNS discovery—The access point can discover controllers through your domain name server (DNS). For the access point to do so, you must configure your DNS to return controller IP addresses in response to CISCO-CAPWAP-CONTROLLER.localdomain or CISCO-LWAPP-CONTROLLER.localdomain, where localdomain is the access point domain name.
    When an access point receives an IP address and DNS information from a DHCP server, it contacts the DNS to resolve CISCO-CAPWAP-CONTROLLER.localdomain or CISCO-LWAPP-CONTROLLER.localdomain. When the DNS sends a list of controller IP addresses, the access point sends discovery requests to the controllers.

    +