I have a customer with a "beeping" Check Point management station. Its a little hard to hear in the data center with all the noise, but you can hear it if you listen closely. I ended up running the hardware diagnostics tool off of a USB drive, and it came back clean. So I ran the command "raidconfig status" and found that I had a hard drive go bad. You will see it says "degraded" and "failed" on drive 2. Time for a replacement.
Smart1> raidconfig status
-- Controller Information --
ID MODEL
C0 MegaRAID SAS 8704EM2
-- Arrays information --
ID Type Size State
C0V0 RAID10 1.816 TB Degraded
-- Disks information --
ID Model Size Status
DISK #1 WD1003FBYX-01Y7B0 931.512GB Online
DISK #2 WD1003FBYX-01Y7B0 931.512GB Failed
DISK #3 WD1003FBYX-01Y7B0 931.512GB Online
DISK #4 WD1003FBYX-01Y7B0 931.512GB Online
Smart1>
This is the retired Shane Killen personal blog, an IT technical blog about configs and topics related to the Network and Security Engineer working with Cisco, Brocade, Check Point, and Palo Alto and Sonicwall. I hope this blog serves you well. -- May The Lord bless you and keep you. May He shine His face upon you, and bring you peace.
Wednesday, March 30, 2016
Monday, March 28, 2016
Brocade R&S: Firmware Versions Update
I just talked with a guy about firmware versions for a ICX6430. See below. Im going with these recommendations from Brocade.
Sunday, March 27, 2016
Saturday, March 26, 2016
Friday, March 25, 2016
Wednesday, March 23, 2016
Firewalls And NAT'ing And The Traveling Packet
Its an interesting thing to me, that NAT'ing takes place before routing does on most firewalls. So, if your public IP address space was 10.10.10.X/24, and you decided that you wanted to NAT your internal 192.168.1.10 server to the public IP address of 10.4.4.4, you could. Now, you might start to think that "you cant do that" because your 10.4.4.4 is not on your 10.10.10.X/24 address space, right? Well, actually, that is wrong. You actually CAN have a public IP address that is not on your public IP range and have it NAT through to your internal server. Routing at the upstream router certainly poses a problem, but if a packet can make it to your firewall, then you can NAT your traffic to any public IP address you want to, even if its not part of your IP range on your firewall interface.
I actually went through this recently on a certain problem I was having on a Check Point firewall. You see, it was the same thing really. I had a public range of, lets say, 40.40.40.0/25. This gives us 126 usable IP addresses (1-126). However, in the config, they had some NATs that were outside of that range. Now, just so you know, they actually owned the whole /24 of 40.40.40.0. But, on the firewall interface, they had split up this subnet and were not using anything above this range (40.40.40.0/25).
In our example, they had a static NAT translation of 40.40.40.200 pointing to a webserver inside the network at 192.168.1.200. I thought that since it was not on the subnet of the public facing NIC on the firewall, the firewall would try to route it out its default gateway (the upstream router), which would try to send it back and ultimately the TTL would hit 0 and the packet would drop. But, this is NOT what happens. What actually happens is that NAT is checked FIRST.
Below, I have the best explanation (from Cisco) of the process the packet actually takes going through the firewall from the outside to the inside. This process also applies to Check Point as well. Notice that first, the ACL is checked to see if the packet is allowed, then NAT. Notice its not until step 7 and 8 where routing comes into place. Its a very interesting process for sure. Take a walk through the steps below. Its a really good read through.
Steps
1. The packet is reached at the ingress interface. Once the packet reaches the internal buffer of the interface, the input counter of the interface is incremented by one.
2. Cisco ASA first looks at its internal connection table details in order to verify if this is a current connection. If the packet flow matches a current connection, then the Access Control List (ACL) check is bypassed and the packet is moved forward.If packet flow does not match a current connection, then the TCP state is verified. If it is a SYN packet or UDP (User Datagram Protocol) packet, then the connection counter is incremented by one and the packet is sent for an ACL check. If it is not a SYN packet, the packet is dropped and the event is logged.
3. The packet is processed as per the interface ACLs. It is verified in sequential order of the ACL entries and if it matches any of the ACL entries, it moves forward. Otherwise, the packet is dropped and the information is logged. The ACL hit count is incremented by one when the packet matches the ACL entry.
4. The packet is verified for the translation rules. If a packet passes through this check, then a connection entry is created for this flow and the packet moves forward. Otherwise, the packet is dropped and the information is logged.
5. The packet is subjected to an Inspection Check. This inspection verifies whether or not this specific packet flow is in compliance with the protocol. Cisco ASA has a built-in inspection engine that inspects each connection as per its pre-defined set of application-level functionality. If it passed the inspection, it is moved forward. Otherwise, the packet is dropped and the information is logged.Additional security checks will be implemented if a Content Security (CSC) module is involved.
6. The IP header information is translated as per the Network Address Translation/ Port Address Translation (NAT/PAT) rule and checksums are updated accordingly. The packet is forwarded to Advanced Inspection and Prevention Security Services Module (AIP-SSM) for IPS related security checks when the AIP module is involved.
7. The packet is forwarded to the egress interface based on the translation rules. If no egress interface is specified in the translation rule, then the destination interface is decided based on the global route lookup.
8. On the egress interface, the interface route lookup is performed. Remember, the egress interface is determined by the translation rule that takes the priority.
9. Once a Layer 3 route has been found and the next hop identified, Layer 2 resolution is performed. The Layer 2 rewrite of the MAC header happens at this stage.
10. The packet is transmitted on the wire, and interface counters increment on the egress interface.
11. The packet is transmitted on the wire, and interface counters increment on the egress interface.
I actually went through this recently on a certain problem I was having on a Check Point firewall. You see, it was the same thing really. I had a public range of, lets say, 40.40.40.0/25. This gives us 126 usable IP addresses (1-126). However, in the config, they had some NATs that were outside of that range. Now, just so you know, they actually owned the whole /24 of 40.40.40.0. But, on the firewall interface, they had split up this subnet and were not using anything above this range (40.40.40.0/25).
In our example, they had a static NAT translation of 40.40.40.200 pointing to a webserver inside the network at 192.168.1.200. I thought that since it was not on the subnet of the public facing NIC on the firewall, the firewall would try to route it out its default gateway (the upstream router), which would try to send it back and ultimately the TTL would hit 0 and the packet would drop. But, this is NOT what happens. What actually happens is that NAT is checked FIRST.
Below, I have the best explanation (from Cisco) of the process the packet actually takes going through the firewall from the outside to the inside. This process also applies to Check Point as well. Notice that first, the ACL is checked to see if the packet is allowed, then NAT. Notice its not until step 7 and 8 where routing comes into place. Its a very interesting process for sure. Take a walk through the steps below. Its a really good read through.
Steps
1. The packet is reached at the ingress interface. Once the packet reaches the internal buffer of the interface, the input counter of the interface is incremented by one.
2. Cisco ASA first looks at its internal connection table details in order to verify if this is a current connection. If the packet flow matches a current connection, then the Access Control List (ACL) check is bypassed and the packet is moved forward.If packet flow does not match a current connection, then the TCP state is verified. If it is a SYN packet or UDP (User Datagram Protocol) packet, then the connection counter is incremented by one and the packet is sent for an ACL check. If it is not a SYN packet, the packet is dropped and the event is logged.
3. The packet is processed as per the interface ACLs. It is verified in sequential order of the ACL entries and if it matches any of the ACL entries, it moves forward. Otherwise, the packet is dropped and the information is logged. The ACL hit count is incremented by one when the packet matches the ACL entry.
4. The packet is verified for the translation rules. If a packet passes through this check, then a connection entry is created for this flow and the packet moves forward. Otherwise, the packet is dropped and the information is logged.
5. The packet is subjected to an Inspection Check. This inspection verifies whether or not this specific packet flow is in compliance with the protocol. Cisco ASA has a built-in inspection engine that inspects each connection as per its pre-defined set of application-level functionality. If it passed the inspection, it is moved forward. Otherwise, the packet is dropped and the information is logged.Additional security checks will be implemented if a Content Security (CSC) module is involved.
6. The IP header information is translated as per the Network Address Translation/ Port Address Translation (NAT/PAT) rule and checksums are updated accordingly. The packet is forwarded to Advanced Inspection and Prevention Security Services Module (AIP-SSM) for IPS related security checks when the AIP module is involved.
7. The packet is forwarded to the egress interface based on the translation rules. If no egress interface is specified in the translation rule, then the destination interface is decided based on the global route lookup.
8. On the egress interface, the interface route lookup is performed. Remember, the egress interface is determined by the translation rule that takes the priority.
9. Once a Layer 3 route has been found and the next hop identified, Layer 2 resolution is performed. The Layer 2 rewrite of the MAC header happens at this stage.
10. The packet is transmitted on the wire, and interface counters increment on the egress interface.
11. The packet is transmitted on the wire, and interface counters increment on the egress interface.
Below is Check Points explanation in the CP documentation. Very similar.
Tuesday, March 22, 2016
Monday, March 21, 2016
Sunday, March 20, 2016
Saturday, March 19, 2016
Friday, March 18, 2016
Cisco R&S: Nexus 9372 Upgrade
I've been working with a team of people in a data center replacement of equipment. One of the first things we are doing is upgrading all the Nexus 9372s and burning everything in. Here is an upgrade template that one of the other guys came up with.
Switch boots up...
Abort Auto Provisioning and continue with normal setup ?(yes/no)[n]: yes
Enter the password for "admin": cisco!123
Confirm the password for "admin": cisco!123
Would you like to enter the basic configuration dialog (yes/no): no
User Access Verification
login: admin
Password:cisco!123
copy usb1:nxos.7.0.3.I2.2a.bin bootflash:
Copy progress 100% 537972KB
Copy complete, now saving to disk (please wait)...
install all nxos bootflash:nxos.7.0.3.I2.2a.bin
Switch will be reloaded for disruptive upgrade.
Do you want to continue with the installation (y/n)? [n] yes
################ Switch Reloads ################
Switch boots up...
Abort Auto Provisioning and continue with normal setup ?(yes/no)[n]: yes
Enter the password for "admin": cisco!123
Confirm the password for "admin": cisco!123
Would you like to enter the basic configuration dialog (yes/no): no
User Access Verification
login: admin
Password:cisco!123
copy usb1:nxos.7.0.3.I2.2a.bin bootflash:
Copy progress 100% 537972KB
Copy complete, now saving to disk (please wait)...
install all nxos bootflash:nxos.7.0.3.I2.2a.bin
Switch will be reloaded for disruptive upgrade.
Do you want to continue with the installation (y/n)? [n] yes
################ Switch Reloads ################
Wednesday, March 16, 2016
Cisco R&S: Autocommand Command
I came across a case where I needed a guy to, on occasion, check, the uptime of the switch. I didnt want him to access anything else, since he really wasnt a switch guy at all. But, I needed him to do this function instead of me doing it. So, all I wanted him to do was to do the "show version", so he could check the uptime and report it to me if it looked like it had rebooted. However, I didnt want this guy to have the ability to do anything else. So, I used the "autocommand" command. Below, you can see three commands. First, I create the username/password. Second, I set it where when John logs in, it will run the "show version" command for him. Third, I tell it not to disconnect the session, so that he can view the uptime.
Core1(config)#username john pass j0yhnc6d
Core1(config)#username john privilege 6 autocommand show version
Core1(config)#username john nohangup
Core1(config)#exit
Here is what happens when John telnets in. Notice that John never runs the command. It runs it for him. Also notice, that it logs him out automatically after the command is run. However, it doesnt close out the window, so that he can read the uptime.
User Access Verification
Username: john
Password:
Cisco IOS Software, C3560 Software (C3560-IPBASE-M), Version 12.2(35)SE5, RELEASE SOFTWARE (fc1)
Copyright (c) 1986-2007 by Cisco Systems, Inc.
Compiled Thu 19-Jul-07 18:15 by nachen
Image text-base: 0x00003000, data-base: 0x01100000
ROM: Bootstrap program is C3560 boot loader
BOOTLDR: C3560 Boot Loader (C3560-HBOOT-M) Version 12.2(25r)SEE4, RELEASE SOFTWARE (fc1)
Core1 uptime is 10 weeks, 4 days, 2 hours, 51 minutes
System returned to ROM by power-on
System image file is "flash:c3560-ipbase-mz.122-35.SE5/c3560-ipbase-mz.122-35.SE5.bin"
cisco WS-C3560G-48PS (PowerPC405) processor (revision F0) with 122880K/8184K bytes of memory.
Processor board ID FOC1203XXXX
Last reset from power-on
8 Virtual Ethernet interfaces
52 Gigabit Ethernet interfaces
The password-recovery mechanism is enabled.
512K bytes of flash-simulated non-volatile configuration memory.
Base ethernet MAC Address : 00:1F:26:FD:XX:XX
Motherboard assembly number : 73-10212-04
Power supply part number : 341-0108-03
Motherboard serial number : FOC1203XXXX
Power supply serial number : DCA1152XXXX
Model revision number : F0
Motherboard revision number : B0
Model number : WS-C3560G-48PS-S
System serial number : FOC1203XXXX
Top Assembly Part Number : 800-26845-01
Top Assembly Revision Number : B0
Version ID : V05
CLEI Code Number : CNMWW00ARC
Hardware Board Revision Number : 0x09
Switch Ports Model SW Version SW Image
------ ----- ----- ---------- ----------
* 1 52 WS-C3560G-48PS 12.2(35)SE5 C3560-IPBASE-M
Configuration register is 0xF
User Access Verification
Username:
Core1(config)#username john pass j0yhnc6d
Core1(config)#username john privilege 6 autocommand show version
Core1(config)#username john nohangup
Core1(config)#exit
Here is what happens when John telnets in. Notice that John never runs the command. It runs it for him. Also notice, that it logs him out automatically after the command is run. However, it doesnt close out the window, so that he can read the uptime.
User Access Verification
Username: john
Password:
Cisco IOS Software, C3560 Software (C3560-IPBASE-M), Version 12.2(35)SE5, RELEASE SOFTWARE (fc1)
Copyright (c) 1986-2007 by Cisco Systems, Inc.
Compiled Thu 19-Jul-07 18:15 by nachen
Image text-base: 0x00003000, data-base: 0x01100000
ROM: Bootstrap program is C3560 boot loader
BOOTLDR: C3560 Boot Loader (C3560-HBOOT-M) Version 12.2(25r)SEE4, RELEASE SOFTWARE (fc1)
Core1 uptime is 10 weeks, 4 days, 2 hours, 51 minutes
System returned to ROM by power-on
System image file is "flash:c3560-ipbase-mz.122-35.SE5/c3560-ipbase-mz.122-35.SE5.bin"
cisco WS-C3560G-48PS (PowerPC405) processor (revision F0) with 122880K/8184K bytes of memory.
Processor board ID FOC1203XXXX
Last reset from power-on
8 Virtual Ethernet interfaces
52 Gigabit Ethernet interfaces
The password-recovery mechanism is enabled.
512K bytes of flash-simulated non-volatile configuration memory.
Base ethernet MAC Address : 00:1F:26:FD:XX:XX
Motherboard assembly number : 73-10212-04
Power supply part number : 341-0108-03
Motherboard serial number : FOC1203XXXX
Power supply serial number : DCA1152XXXX
Model revision number : F0
Motherboard revision number : B0
Model number : WS-C3560G-48PS-S
System serial number : FOC1203XXXX
Top Assembly Part Number : 800-26845-01
Top Assembly Revision Number : B0
Version ID : V05
CLEI Code Number : CNMWW00ARC
Hardware Board Revision Number : 0x09
Switch Ports Model SW Version SW Image
------ ----- ----- ---------- ----------
* 1 52 WS-C3560G-48PS 12.2(35)SE5 C3560-IPBASE-M
Configuration register is 0xF
User Access Verification
Username:
Tuesday, March 15, 2016
Quote For The Day: 13
"I try to learn from the past, but I plan for the future by focusing exclusively on the present. That's were the fun is." ~~ Donald Trump
Monday, March 14, 2016
Palo Alto Firewall: How To Create A NAT Translation
Below, I created a NAT translation for ALL ports to this server. In this case, the customer has a lot of things that will be opened up, and my ruleset will keep unwanted ports out. Under Policies --> NAT, you create a static NAT translation.
Sunday, March 13, 2016
Saturday, March 12, 2016
Friday, March 11, 2016
Cisco Voice: Prime And Licensing
When you add a license to your existing CUCM setup, you are going to do this in Cisco Prime now. Make sure you synchronize Prime with CUCM. If you don't, CUCM wont know about the new licenses. Just FYI.
Wednesday, March 9, 2016
Packet Capture: CDP And What It Can Tell You
Information is a good thing, especially if you don't have it. So what do you do when you don't have information? You get it.
CDP has some really good information about the network in the packet if you need to gather information. See below. I have only concentrated on gathering the core IP address, its software version, and the platform it is. There is more information, but for today's post, we don't care about it. I really just want you to see what you can gain if you don't have access to the network devices, but can gain sniffing capability.
Generically, here is the fields you can expect to see.
You can see above, I captured the software version of the core, its platform, and its IP address. Nice! Wireshark is a great tool to utilize.
CDP has some really good information about the network in the packet if you need to gather information. See below. I have only concentrated on gathering the core IP address, its software version, and the platform it is. There is more information, but for today's post, we don't care about it. I really just want you to see what you can gain if you don't have access to the network devices, but can gain sniffing capability.
Generically, here is the fields you can expect to see.
And to get specific info you may want, dive deeper.
Tuesday, March 8, 2016
Cisco Firewall: How To Copy The Config To A TFTP Location Directly
Here is a quick post on how to send the config to a TFTP in CLI on the ASA. I typically just log it in my Tera Term session. But this works too.
ASA# copy running-config tftp
Source filename [running-config]?
Address or name of remote host []? 10.1.1.30
Destination filename [running-config]?
Cryptochecksum: 0d26cd13 fe9f6f96 d8c80803 2ff55825
!!!!!!!!!!!!
46613 bytes copied in 3.330 secs (15537 bytes/sec)
ASA#
ASA# copy running-config tftp
Source filename [running-config]?
Address or name of remote host []? 10.1.1.30
Destination filename [running-config]?
Cryptochecksum: 0d26cd13 fe9f6f96 d8c80803 2ff55825
!!!!!!!!!!!!
46613 bytes copied in 3.330 secs (15537 bytes/sec)
ASA#
Monday, March 7, 2016
Quote For The Day: 12
For all you who live in the South of the USA, you will know what I mean here. With "Freebird" playing in the restaurant we are eating in, I'm told the following: "We can't leave yet. That would be disrespectful!" ~~ My Wife
Saturday, March 5, 2016
Thursday, March 3, 2016
Brocade ICX Switch: Option 150 For Cisco IP Phone
I put in a new ICX7250 lately that was acting as a small core for a very small facility. They had a few Cisco IP phones (which are great) on the network, and the core switch was giving out DHCP for them. So, when we replaced the switch with the ICX7250, we needed to accommodate for that. Below is the DHCP config I did for the IP phones. Note the two bold commands. These two are for telling the IP phone to look at the CUCM for its TFTP files.
ip dhcp-server pool voice
dhcp-default-router 192.168.1.1
excluded-address 192.168.1.1 192.168.1.40
lease 1 0 0
network 192.168.1.0 255.255.255.0
tftp-server 192.168.2.250
vendor-class ascii 150
deploy
ip dhcp-server pool voice
dhcp-default-router 192.168.1.1
excluded-address 192.168.1.1 192.168.1.40
lease 1 0 0
network 192.168.1.0 255.255.255.0
tftp-server 192.168.2.250
vendor-class ascii 150
deploy
Wednesday, March 2, 2016
Home Projects: Shiplap Walls
In the old 1935 house, we decided to do some of the walls in shiplap. Below is the start of one of the bedrooms. I think it's going to look good when it's done. In this room, we will paint it white. I'll put up a final picture later when we have it all done. We still have a lot of work to do.
Tuesday, March 1, 2016
Cisco R&S: Nexus "Read-Only" Login
Im going to keep this short. But I needed to create a login for a guy who just needed read-only access on the N5K we were working on. Here is how I did it:
N5K(config)# username pretenduser role network-operator password pretendpassword
N5K(config)# username pretenduser role network-operator password pretendpassword
Subscribe to:
Posts (Atom)