Excel find/replace with line-break within cells
- Open the find/replace pop-up with CTRL+H
- Set find value to the character to be replaced with line-break
- In the Replace With field, pless CTRL+J
First, use hashdeep to capture the hash of the first directory:
$ hashdeep -b -r /home/user/one/ > one-results.txt
Then do the same for the second directory:
$ hashdeep -b -r /home/user/one > two-results.txt
Now you need to compare the two resulting files. Their order is likely to be different, so you will need to sort them first.
$ sort one-results.txt > one-results-sorted.txt
$ sort two-results.txt > two-results-sorted.txt
$ diff one-results-sorted.txt two-results-sorted.txt
If the directories match, the only output of the diff command will be the headers showing the two files you are comparing. Like this:
10c10
\ ## $ hashdeep -b -r /home/user/one — \ ## $ hashdeep -b -r /home/user/two
You can use the -a command of hashdeep, but that will only if the directors are the same or not, it won’t show you what is different between them.
The -b flag is important – without this, hashdeep will store the full file path in the output files, which will never match between two directories. Using the -b flag ensure that only the filename is saves, not the full path, and this can be checked against different directories.
If you have a pair of HA Fortigates, sometimes you need to log into the slave device via SSH. Common examples including wanting to run a packet capture.
To do so, log into the primary device as usual, then run this command:
Fortigate1 # config global
Fortigate1 (global)# execute ha manage 0
Fortigate2 $
That’s it, you are now logged onto the slave Fortigate.
If you find a situation where a site to site IPsec VPN on a Fortigate is apparently up and passing traffic, except ping (ICMP) is not flowing over the VPN, here is a solution.
The cause can be if the VPN flaps momentarily, and an ICMP packet is received in the short space of time while the IPsec tunnel is down, the Fortigate will create a new session via the routed interface. Even when the tunnel is re-established, the incorrect session will persist via the physical interface, as opposed to via the correct tunnel interface.
To clear this erroneous session, run the following commands. Note that the first command (vd 2) is only required if you are using multiple Virtual Domains (VDOMS), and the number should correspond to the number of the impacted VDOM. If you don’t have VDOM’s in use, skip to the ‘proto’ command.
FORTIGATE (vdom) # diagnose system session filter vd 2
FORTIGATE (vdom) # diagnose system session filter proto 1
FORTIGATE (vdom) # diagnose system session filter
session filter:
vd: 2
sintf: any
dintf: any
proto: 1-1
proto-state: any
source ip: any
NAT'd source ip: any
dest ip: any
source port: any
NAT'd source port: any
dest port: any
policy id: any
expire: any
duration: any
FORTIGATE (vdom) # diagnose system session clear
FORTIGATE (vdom) #
Once you have cleared the session, you may need to restart the VPN tunnel. The next ICMP packet should bring up the session over the correct IPsec tunnel interface.
A common requirement is to generate a random, unique and secure pre-shared key, typically for use in VPN’s. The Linux tool, APG (Automated Password Generator), is a great tool for this job, but you need to specify a few options to get the correct output.
If you just run ‘apg’, you get output that is designed to be read over the phone. This is not what we would consider secure. Here is my suggested command:
apg -a 1 -m 16 -n 1 -c /dev/random
What does each option do?
-a 1
This disables the ‘pronounceable’ password generation option, making password unpronounceable over the phone, and thus more random.
-m 16
This sets the length of the output to 16 characters. Feel free to substitute ’16’ with your own minimum requirement, just make sure that you make it larger than the default of 6.
-n 1
This produces only 1 password. If you need say 4 passwords, use -n 4. The default is 6.
-c /dev/random
By default, APG asks you to enter random data, which it will use as the seed for its PRNG. By using this option, we provide truly random data as the seed. Note that if your OS is low on entropy, using this option may take longer than usual.
If you want to avoid using symbols that might cause issues with input validation, try this command instead:
apg -a 1 -m 22 -n 1 -c /dev/random -M NCL
This will force the use of upper case, lower case and numbers, but no symbols. The number of characters has also been increased to 22, due to the lower entropy due the reduced character set.
firewall-asa(config)# no route INSIDE 192.168.0.0 255.255.255.0 172.16.0.254
ERROR: Cannot remove connected route
firewall-asa(config)#
The above error is caused when you try to route a directly connected interface to another subnet. In order to remove this route, you need to shutown the interface, then remove the route.
For example, if you have 172.16.0.0/24 assigned to your INSIDE interface, and 192.168.0.0/24 routed to an IP within 172.16.0.0, and you want to move 192.168.0.0/24 to a dedicated segment on the FW (say DMZ), you will run into this problem. You need to shutdown the INSIDE segment in order to remove the route.
firewall-asa(config)# interface Ethernet0/1
firewall-asa(config-subif)# shut
firewall-asa(config-subif)# exit
firewall-asa(config)#
firewall-asa(config)# no route INSIDE 192.168.0.0 255.255.255.0 172.16.0.254
firewall-asa(config)#
firewall-asa(config)# interface Ethernet0/1.100
firewall-asa(config-subif)# no shut
Problem solved.
The normal commands to show configuration items don’t work as expected for sysopt.
asa/pri/act# sh run sysopt
asa/pri/act#
asa/pri/act# sh run | include sysopt
asa/pri/act#
asa/pri/act# more system:running-config | include sysopt
asa/pri/act#
You need to use the “show run all sysopt” command.
asa/pri/act# show run all sysopt
no sysopt connection timewait
sysopt connection tcpmss 1380
sysopt connection tcpmss minimum 0
no sysopt nodnsalias inbound
no sysopt nodnsalias outbound
no sysopt radius ignore-secret
sysopt connection permit-vpn
no sysopt connection reclassify-vpn
no sysopt connection preserve-vpn-flows
asa/pri/act#
Never specific anything other than IP (such as TCP or UDP), when creating an ACL on the ASA for an ACL used within a NAT statement. If you do, you may get this error:
ERROR: ACE contains port, protocol, or deny. Removing NAT configuration
The above means that all of your NAT config has now been removed. Depending on your config, this can break a lot of traffic.
Here is an example:
ciscoasa/pri/act# show run nat nat (outside) 0 access-list nat-exempt nat (dmz) 0 access-list nat-exempt nat (inside) 0 access-list nat-exempt ciscoasa/pri/act# ciscoasa/pri/act# sh run access-list nat-exempt access-list nat-exempt extended permit ip 10.101.0.0 255.255.255.0 10.120.0.0 255.255.255.0 ciscoasa/pri/act# configure terminal ciscoasa/pri/act(config)# access-list nat-exempt extended permit tcp 10.96.0.0 255.255.255.0 172.19.19.0 255.255.255.0 eq 80 ERROR: ACE contains port, protocol, or deny. Removing NAT configuration nat (outside) 0 access-list nat-exempt ERROR: ACE contains port, protocol, or deny. Removing NAT configuration nat (dmz) 0 access-list nat-exempt ERROR: ACE contains port, protocol, or deny. Removing NAT configuration nat (inside) 0 access-list nat-exempt ciscoasa/pri/act(config)# exit ciscoasa/pri/act# ciscoasa/pri/act# show run nat ciscoasa/pri/act#
Notice that the NAT rules were removed completely when we added the incorrect ACE. We need to replace them manually:
ciscoasa/pri/act(config)# no access-list nat-exempt extended permit tcp 10.96.0.0 255.255.255.0 172.19.19.0 255.255.255.0 eq 80 ciscoasa/pri/act(config)# nat (outside) 0 access-list nat-exempt ciscoasa/pri/act(config)# nat (dmz) 0 access-list nat-exempt ciscoasa/pri/act(config)# nat (inside) 0 access-list nat-exempt
If your phase 1 negotiation is timing out from your SRX, it may be due to lack of IKE setting on the host-inbound-traffic setting.
Here is a typical error:
Jan 01 12:00:00 Phase-1 negotiation failed with error Timeout for p1_local=ipv4(
udp:500,[0..3]=192.0.2.1) p1_remote=ipv4(udp:500,[0..3]=198.51.100.1)
A broken config will look like this – notice the lack of IKE.
root@srx> show configuration security
security {
security-zone untrust {
address-book {
address 10.0.0.0/24 10.0.0.0/24;
address 10.0.1.0/24 10.0.1.0/24;
}
host-inbound-traffic {
system-services {
ping;
ssh;
}
}
interfaces {
fe-0/0/2.0;
st0.0;
}
}
}
Note the lack of IKE on host-inbound-traffic. Here is how you fix it.
root@srx# set security security-zone untrust host-inbound-traffic system-services ike
Here is the update config
root@srx> show configuration security
security {
security-zone untrust {
address-book {
address 10.0.0.0/24 10.0.0.0/24;
address 10.0.1.0/24 10.0.1.0/24;
}
host-inbound-traffic {
system-services {
ping;
ssh;
ike;
}
}
interfaces {
fe-0/0/2.0;
st0.0;
}
}
}
A Juniper SRX cluster configuration does not allow access to the secondary device, even by out-of-band management, but default. This is expected behaviour, as the non-primary device in a cluster will not start the router process. So, unless your out-of-band management gives you access from the same layer 2 network, the secondary SRX will not respond to SSH/HTTPS
To resolve this, you need set a backup-router. A backup-router is a static route which is active before the routing engine starts. Typically, this is useful while the SRX is booting, as it allows BOOTSTRAP or PXE based boots, but presents a problem in cluster.
root@srx-secondary> show route
error: the routing subsystem is not running
Fix this problem, with the following command:
set groups node1 system backup-router 172.29.0.1 destination 0.0.0.0/0
This will appear in the groups configuration as such:
node0 {
system {
host-name srx-primary;
}
interfaces {
fxp0 {
unit 0 {
family inet {
address 172.29.0.100/24;
}
}
}
}
}
node1 {
system {
host-name srx-secondary;
backup-router 172.29.0.1 destination 0.0.0.0/0;
}
interfaces {
fxp0 {
unit 0 {
family inet {
address 172.29.0.101/24
}
}
}
}
}
You will now have SSH/HTTPS access to your secondary device. It is a good idea to also add a backup-router to the primary device, in case the router daemon on the primary crashes or fails.