NAT Configuration on OpenSense
interface > other types > vlan > Add
interfaces > assignments > Add new interface > assign name, ip address, mru etc
Firewall > nat > outbound > clone existing rule and edit network address &
NAT Configuration on OpenSense
interface > other types > vlan > Add
interfaces > assignments > Add new interface > assign name, ip address, mru etc
Firewall > nat > outbound > clone existing rule and edit network address &
Notes on installing and using Silk network monitoring on a pre-configured log server named Wonderland
Following the setup I then created my first set and within that my first query through the GUI which resulted in these options for the command line:
rwfilter --type=out,outweb,in,inweb --sensors=S1 --start-date=2016/07/18:18 --end-date=2016/07/19:01 --proto=0-255 --max-pass-records=0 --ip-version=4 --pass=FirstQuery.rwf --print-filenames
There is a known issue with certain wireless access points and some clients. The solution is to:
1. Forget the Eduroam network from your device
2. Using your mobile data connection or via OWL (if you use OWL you will need to connect to it, close the browser pop up, connect to it again and close the browser pop up a second time – now you will have the option to “Use without Internet”) visit :
3. Download the configuration tool for your device and launch it, entering your username in the format email@example.com along with your Eduroam / Remote Access password
4. Now connect to the Eduroam network and all should be well.
Steve Kersley provided me with a quick tute in using the native Mac OSX tools to monitor the local wifi clients and access points.
First prep the symlink on the machines
sudo ln -s /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport /usr/sbin/airport
Next run the dissassociate command on the wireless adpater:
sudo airport -z
finally run the tcpdump command to begin monitoring the wireless activity in realtime
sudo tcpdump -i en1 -I -n type mgt and not subtype beacon
The previous command is broken down into:
The above is fairly self-explanatory except for the last options for filtering by type.
An excellent resource I used for reference to understand this can be found at http://www.wildpackets.com/resources/compendium/wireless_lan/wlan_packet_types
and is included below for reference:
The table below lists the various packet types and subtypes specified in the 802.11 WLAN standard, and describes their usage briefly.
|00||mgmt||0000||Association Request||This packet is sent to an access point (in a BSS or ESS) or to any other peer (in an IBSS or ad hoc network). The sender must already be authenticated in order to gain a successful association.|
|00||mgmt||0001||Association Response||This packet is sent from an access point (in a BSS or ESS) or from any other peer (in an IBSS or ad hoc network) in response to an association request packet. If the request is successful, the response will include the Association ID of the requester.|
|00||mgmt||0010||Reassociation Request||Like an association request, but it includes information about the current association at the same time as it requests a new association (either with the original Station after some lapse of time, or with a new station upon moving from one BSS to another). This packet is sent to an access point (in a BSS or ESS) or to any other peer (in an IBSS or ad hoc network). The sender must already be authenticated in order to gain a successful association.|
|00||mgmt||0011||Reassociation Response||Like an association response, but in response to a reassociation request. This packet is sent from an access point (in a BSS or ESS) or from any other peer (in an IBSS or ad hoc network) in response to a reassociation request packet. If the request is successful, the response will include the Association ID of the requester.|
|00||mgmt||0100||Probe Request||Probe request is used to actively seek any, or a particular, access point or BSS.|
|00||mgmt||0101||Probe Response||Probe response replies with station parameters and supported data rates.|
|00||mgmt||1000||Beacon||Beacon packets are sent by the access point in a BSS (or its equivalent in an IBSS) to announce the beginning of a Contention Free period (CF), during which the right to transmit is conferred by the access point by polling. Beacon management packets carry BSS timestamps to help synchronize member stations with the BSS, and other information to help them locate and choose the BSS with the best signal and availability.|
|00||mgmt||1001||ATIM||Announcement Traffic Indication Message. This packet serves much the same function in an IBSS that the Beacon packet does in an infrastructure (BSS or ESS) topology. The packet sets the synchronization of the group and announces that messages are waiting to be delivered. Stations in Power Save mode wake up periodically to listen for ATIM packets in ad hoc (IBSS) networks, just as they do for Beacon packets in infrastructure (BSS or ESS) networks.|
|00||mgmt||1010||Disassociation||This packet is an announcement breaking an existing association. It is a one-way communication (meaning it does not require or accept a reply), and must be accepted. It can be sent by any associated station or BSS and it takes effect immediately.|
|00||mgmt||1011||Authentication||Authentication packets are sent back and forth between the station requesting authentication and the station to which it is attempting to assert its authentic identity. The number of packets exchanged depends on the authentication method employed. Information relating to the particular scheme is carried in the body of the Authentication packet.|
|00||mgmt||1100||Deauthentication||This packet is an announcement stating that the receiver is no longer authenticated. It is a one-way communication from the authenticating station (a BSS or functional equivalent), and must be accepted. It takes effect immediately.|
|01||ctrl||1010||PS-Poll||Power Save polling packet. Stations in power save mode awaken periodically to listen to selected Beacons. If they hear that data is waiting for them, they will awake more fully and send a PS-Poll packet to the access point (BSS) to request the transmission of this waiting data. In Control packets of the Power Save-Poll type, the Duration/ID field contains the association ID (AID) for the station sending the packet.|
|01||ctrl||1011||RTS||Request To Send. Coordinates access to airwaves.|
|01||ctrl||1100||CTS||Clear To Send. Response to a RTS, coordinates access to airwaves.|
|01||ctrl||1101||ACK||Acknowledges receipt of transmitted data.|
|01||ctrl||1110||CF End||Signals the end of Contention Free period.|
|01||ctrl||1111||CF End + CF ACK||Signals the end of the Contention Free period and Acknowledges the receipt of some packet in a single message.|
|10||data||any||any||Multiple subtypes exist for Data type packets, but all have the same basic format, as described above. (see Appendix C, “802.11 WLAN Packets and Protocols”.) The different Data subtypes essentially just piggyback CF-Poll, CF-ACK, and CF-End messages onto the data message in a single transmission. This allows the BSS to gain higher throughputs possible using PCF (point coordinating function).|
sudo ifconfig ethX promisc tshark -i ethX -n port 68 -R 'bootp.type == 2'
sudo tcpdump -i eth0 port 67 or port 68 -nev and “ether host <<MAC ADDRESS>>”
ether host <mac address>
packet size for full details:
prevent name resolution:
To add an additional IP to a network interface on OSX using the GUI simply “replicate service” on any interface via the cog in [Network Settings] and then assign the IP to the replicated interface manually.
From the terminal:
sudo ifconfig en1 inet xxx.xxx.xxx.xxx netmask 255.255.255.0 alias
Where sudo = execute as root, en1 = the interface you want to add an alias to, xxx.xxx.xxx.xxx = ip you wan to add, 255.255.255.0 = desired netmask.
dhcp server lease list (lists the current DHCP clients)
dhcp server lease delete clientid=xx:xx:xx:xx:xx:xx ( xx etc. is the MAC address of appropriate client from above list – deletes the current lease)
dhcp server lease add clientid=xx:xx:xx:xx:xx:xx pool=LAN_private addr=192.168.1.x leasetime=0 (adds required IP for appropriate client with infinite lease time)
verbatim from http://www.danielmiessler.com/study/tcpdump/
Image from securitywizardry.com
[ Check out my latest post on the HP Security Blog: “Thoughts on the Heartbleed Bug” ]
tcpdump is the premier network analysis tool for information security professionals. Having a solid grasp of this über-powerful application is mandatory for anyone desiring a thorough understanding of TCP/IP. Many prefer to use higher level analysis tools such as Ethereal Wireshark, but I believe this to usually be a mistake.
In a discipline so dependent on a true understanding of concepts vs.rote learning, it’s important to stay fluent in the underlying mechanics of the TCP/IP suite. A thorough grasp of these protocols allows one to troubleshoot at a level far beyond the average analyst, but mastery of the protocols is only possible through continued exposure to them.
When using a tool that displays network traffic a more natural (raw) way the burden of analysis is placed directly on the human rather than the application. This approach cultivates continued and elevated understanding of the TCP/IP suite, and for this reason Istrongly advocate using
tcpdump instead of other tools whenever possible.
15:31:34.079416 IP (tos 0x0, ttl 64, id 20244, offset 0, flags [DF], proto: TCP (6), length: 60) source.35970 > dest.80: S, cksum 0x0ac1 (correct), 2647022145:2647022145(0) win 5840 0x0000: 4500 003c 4f14 4000 4006 7417 0afb 0257 E.. 0x0010: 4815 222a 8c82 0050 9dc6 5a41 0000 0000 H."*...P..ZA.... 0x0020: a002 16d0 0ac1 0000 0204 05b4 0402 080a ................ 0x0030: 14b4 1555 0000 0000 0103 0302
Below are a few options (with examples) that will help you greatly when working with the tool. They’re easy to forget and/or confuse with other types of filters, i.e. ethereal, so hopefully this page can serve as a reference for you, as it does me.
First off, I like to add a few options to the
tcpdump command itself, depending on what I’m looking at. The first of these is -n, which requests that names are not resolved, resulting in the IPs themselves always being displayed. The second is -X, which displays both hex and ascii content within the packet. The final one is -S, which changes the display of sequence numbers to absolute rather than relative. The idea there is that you can’t see weirdness in the sequence numbers if they’re being hidden from you. Remember, the advantage of using
tcpdump vs. another tool is getting manual interaction with the packets.
It’s also important to note that
tcpdump only takes the first 68 96 bytes of data from a packet by default. If you would like to look at more, add the -s number option to the mix, where number is the number of bytes you want to capture. I recommend using 0 (zero) for a snaplength, which gets everything. Here’s a short list of the options I use most:
-i any: Listen on all interfaces just to see if you’re seeing any traffic.
-n: Don’t resolve hostnames.
-nn: Don’t resolve hostnames or port names.
-X: Show the packet’s contents in both hex and ASCII.
-XX: Same as
-X, but also shows the ethernet header.
-v, -vv, -vvv: Increase the amount of packet information you get back.
-c: Only get x number of packets and then stop.
-s: Define the snaplength (size) of the capture in bytes. Use
-s0to get everything, unless you are intentionally capturing less.
-S: Print absolute sequence numbers.
-e: Get the ethernet header as well.
-q: Show less protocol information.
-E: Decrypt IPSEC traffic by providing an encryption key.
[ The default snaplength as of
tcpdump 4.0 has changed from 68 bytes to 96 bytes. While this will give you more of a packet to see, it still won’t get everything. Use
-s 1514 to get full coverage ]
So, based on the kind of traffic I’m looking for, I use a different combination of options to
tcpdump, as can be seen below:
# tcpdump -nS
# tcpdump -nnvvS
# tcpdump -nnvvXS
# tcpdump -nnvvXSs 1514
hermes root # tcpdump -nnvXSs 0 -c2 icmp tcpdump: listening on eth0, link-type EN10MB (Ethernet), 23:11:10.370321 IP (tos 0x20, ttl 48, id 34859, offset 0, flags [none], length: 84) 18.104.22.168 > 22.214.171.124: icmp 64: echo request seq 0 0x0000: 4520 0054 882b 0000 3001 7cf5 45fe d52b E..T.+..0.|.E..+ 0x0010: 4815 222a 0800 3530 272a 0000 25ff d744 H."*..50'*..%..D 0x0020: ae5e 0500 0809 0a0b 0c0d 0e0f 1011 1213 .^.............. 0x0030: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 .............!"# 0x0040: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 $%&'()*+,-./0123 0x0050: 3435 3637 4567 23:11:10.370344 IP (tos 0x20, ttl 64, id 35612, offset 0, flags [none], length: 84) 126.96.36.199 > 188.8.131.52: icmp 64: echo reply seq 0 0x0000: 4520 0054 8b1c 0000 4001 6a04 4815 222a E..T....@.j.H."* 0x0010: 45fe d52b 0000 3d30 272a 0000 25ff d744 E..+..=0'*..%..D 0x0020: ae5e 0500 0809 0a0b 0c0d 0e0f 1011 1213 .^.............. 0x0030: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 .............!"# 0x0040: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 $%&'()*+,-./0123 0x0050: 3435 3637 4567 2 packets captured 2 packets received by filter 0 packets dropped by kernel hermes root #
Expressions allow you to trim out various types of traffic and find exactly what you’re looking for. Mastering the expressions and learning to combine them creatively is what makes one truly powerful with
tcpdump. There are three main types of expression:
Type options are
port. Direction is indicated by
dir, and there you can have
src or dst, and
src and dst. Here are a few that you should definitely be comfortable with:
host// look for traffic based on IP address (also works with hostname if you’re not using -n)
# tcpdump host 184.108.40.206
dst// find traffic from only a source or destination (eliminates one side of a host conversation)
# tcpdump src 220.127.116.11
# tcpdump dst 18.104.22.168
net// capture an entire network using CIDR notation
# tcpdump net 22.214.171.124/24
proto// works for tcp, udp, and icmp. Note that you don’t have to type
# tcpdump icmp
port// see only traffic to or from a certain port
# tcpdump port 3389
src, dst port// filter based on the source or destination port
# tcpdump src port 1025
# tcpdump dst port 389
src/dst, port, protocol// combine all three
# tcpdump src port 1025 and tcp
# tcpdump udp and src port 53
You also have the option to filter by a range of ports instead of declaring them individually, and to only see packets that are above or below a certain size.
tcpdump portrange 21-23
tcpdump less 32
tcpdump greater 128
[ You can use the symbols for less than, greater than, and less than or equal / greater than or equal signs as well. ]
// filtering for size using symbols
tcpdump > 32
tcpdump <= 128
tcpdump allows you to send what you’re capturing to a file for later use using the
-w option, and then to read it back using the
-roption. This is an excellent way to capture raw traffic and then run it through various tools later.
The traffic captured in this way is stored in
tcpdump format, which is pretty much universal in the network analysis space. This means it can be read in by all sorts of tools, including Wireshark, Snort, etc.
# tcpdump -s 1514 port 80 -w capture_file
Then, at some point in the future, you can then read the traffic back in like so:
# tcpdump -r capture_file
Expressions are nice, but the real magic of
tcpdump comes from the ability to combine them in creative ways in order to isolate exactly what you’re looking for. There are three ways to do combinations, and if you’ve studied computers at all they’ll be pretty familar to you:
# TCP traffic from 10.5.2.3 destined for port 3389
tcpdump -nnvvS and src 10.5.2.3 and dst port 3389
# Traffic originating from the 192.168 network headed for the 10 or 172.16 networks
tcpdump -nvX src net 192.168.0.0/16 and dst net 10.0.0.0/8 or172.16.0.0/16
# Non-ICMP traffic destined for 192.168.0.2 from the 172.16 network
tcpdump -nvvXSs 1514 dst 192.168.0.2 and src net and not icmp
# Traffic originating from Mars or Pluto that isn’t to the SSH port
tcpdump -vv src mars and not dst port 22
As you can see, you can build queries to find just about anything you need. The key is to first figure out precisely what you’re looking for and then to build the syntax to isolate that specific type of traffic.
Also keep in mind that when you’re building complex queries you might have to group your options using single quotes. Single quotes are used in order to tell
tcpdump to ignore certain special characters — in this case the “( )” brackets. This same technique can be used to group using other expressions such as
net, etc. Take a look at the command below:
# Traffic that’s from 10.0.2.4 AND destined for ports 3389 or 22(incorrect)
tcpdump src 10.0.2.4 and (dst port 3389 or 22)
If you tried to run this otherwise very useful command, you’d get an error because of the parenthesis. You can either fix this by escaping the parenthesis (putting a before each one), or by putting the entire command within single quotes:
# Traffic that’s from 10.0.2.4 AND destined for ports 3389 or 22(correct)
tcpdump ‘src 10.0.2.4 and (dst port 3389 or 22)’
You can also filter based on specific portions of a packet, as well as combine multiple conditions into groups. The former is useful when looking for only SYNs or RSTs, for example, and the latter for even more advanced traffic isolation.
[ Hint: An anagram for the TCP flags: Unskilled Attackers Pester RealSecurity Folk ]
Show me all URGENT (URG) packets…
# tcpdump ‘tcp & 32!=0‘
Show me all ACKNOWLEDGE (ACK) packets…
# tcpdump ‘tcp & 16!=0‘
Show me all PUSH (PSH) packets…
# tcpdump ‘tcp & 8!=0‘
Show me all RESET (RST) packets…
# tcpdump ‘tcp & 4!=0‘
Show me all SYNCHRONIZE (SYN) packets…
# tcpdump ‘tcp & 2!=0‘
Show me all FINISH (FIN) packets…
# tcpdump ‘tcp & 1!=0‘
Show me all SYNCHRONIZE/ACKNOWLEDGE(SYNACK) packets…
# tcpdump ‘tcp=18‘
[ Note: Only the PSH, RST, SYN, and FIN flags are displayed in
tcpdump‘s flag field output. URGs and ACKs are displayed, but they are shown elsewhere in the output rather than in the flags field ]
Keep in mind the reasons these filters work. The filters above find these various packets because
tcp looks at offset 13 in the TCP header, the number represents the location within the byte, and the !=0 means that the flag in question is set to 1, i.e. it’s on.
As with most powerful tools, however, there are multiple ways to do things. The example below shows another way to capture packets with specific TCP flags set.
Capture TCP Flags Using the
# tcpdump ‘tcp[tcpflags] & & tcp-syn != 0‘
Finally, there are a few quick recipes you’ll want to remember for catching specific and specialized traffic, such as IPv6 and malformed/likely-malicious packets.
# tcpdump ip6
Packets with both the RST and SYN flags set (why?)
# tcpdump ‘tcp = 6’
Traffic with the ‘Evil Bit’ Set
# tcpdump ‘ip & 128 != 0‘
Well, this primer should get you going strong, but the man pageshould always be handy for the most advanced and one-off usage scenarios. I truly hope this has been useful to you, and feel free tocontact me if you have any questions. ::
RIPPED DIRECTLY FROM: http://linuxaria.com/article/tool-command-line-bandwidth-linux
[expand title=”3 Command line tools to test bandwidth between 2 servers “]
One element that is often not know, or that should be measured after a problem statement or after a change in the infrastructure is the network . But how do you accurately measure the speed between two servers?
Someone use ftp, scp or other file transfer protocols, these can give some indication, but probably you’ll measure the limit of your disks or CPU.
In this article I will show you 3 way to measure the bandwidth from the command line, without using the disks.
Iperf was developed by NLANR/DAST as a modern alternative for measuring maximum TCP and UDP bandwidth performance. Iperf allows the tuning of various parameters and UDP characteristics. Iperf reports bandwidth, delay jitter, datagram loss.
The quality of a link can be tested as follows:
– Latency (response time or RTT): can be measured with the Ping command.
– Jitter (latency variation): can be measured with an Iperf UDP test.
– Datagram loss: can be measured with an Iperf UDP test.
The bandwidth is measured through TCP tests.
To be clear, the difference between TCP (Transmission Control Protocol) and UDP (User Datagram Protocol) is that TCP use processes to check that the packets are correctly sent to the receiver whereas with UDP the packets are sent without any checks but with the advantage of being quicker than TCP.
Iperf uses the different capacities of TCP and UDP to provide statistics about network links.
With Iperf you have a server machine where iperf put itself in listening and the other that is the client that send the informations.
#iperf -s ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 8.00 KByte (default) ------------------------------------------------------------  local 10.1.1.1 port 5001 connected with 10.6.2.5 port 54355 [ ID] Interval Transfer Bandwidth  0.0-10.1 sec 1.15 MBytes 956 Kbits/sec ------------------------------------------------------------ Client connecting to 10.6.2.5, TCP port 5001 TCP window size: 8.00 KByte (default) ------------------------------------------------------------  local 10.1.1.1 port 1646 connected with 10.6.2.5 port 5001 [ ID] Interval Transfer Bandwidth  0.0-10.0 sec 73.3 MBytes 61.4 Mbits/sec
#iperf -c 10.1.1.1 -d ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 85.3 KByte (default) ------------------------------------------------------------ ------------------------------------------------------------ Client connecting to 10.1.1.1, TCP port 5001 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 5] local 10.6.2.5 port 60270 connected with 10.1.1.1 port 5001 [ 4] local 10.6.2.5 port 5001 connected with 10.1.1.1 port 2643 [ 4] 0.0-10.0 sec 76.3 MBytes 63.9 Mbits/sec [ 5] 0.0-10.1 sec 1.55 MBytes 1.29 Mbits/sec
So using Iperf (with appropriate flags) on both our machines we can simply measure the bandwidth between them.
Iperf is available also for Windows.
Complete guide: http://openmaniak.com/iperf.php
To eliminate the disks from having any part of the transfer, we will use netcat transferring the output of command yes. Netcat is described as being a “feature-rich network debugging and exploration tool”. It can be obtained from Source Forge, or it may already be available in your distribution.
Again we will use one of the machines as a server that receives the data and the other as a client that sends the information.
On th server machine
nc -v -v -l -n 2222 >/dev/null listening on [any] 2222 ...
On the client machine
time yes|nc -v -v -n 10.1.1.1 2222 >/dev/null
On client stop the process after 10 seconds (more or less) with ctrl-c, you’ll get something like:
sent 87478272, rcvd 0 real 0m9.993s user 0m2.075s sys 0m0.939s
On the server machine, note the data received (in bytes)
sent 0, rcvd 87478392
Now multiply the bytes rcvd by 8 to get total bits, then divide by the time: Result in this example is 70Mb/s
BWCTL is a command line client application and a scheduling and policy daemon. These tests can measure maximum TCP bandwidth, with various tuning options available, or, by doing a UDP test, the delay, jitter, and datagram loss of a network.
The bwctl client application works by contacting a bwctld process on the two test endpoint systems. BWCTL will work as a 3-party application. The client can arrange a test between two servers on two different systems. If the local system is intended to be one of the endpoints of the test, bwctl will detect whether a local bwctld is running and will handle the required server functionality if needed.
The bwctl client is used to request the type of throughput test wanted. Furthermore, it requests when the test should be executed. bwctld either responds with a tentative reservation or a test denied message. Once bwctl is able to get a matching reservation from both bwctld processes (one for each host involved in the test), it confirms the reservation. Then, the bwctld processes run the test and return the results. The results are returned to the client from both sides of the test. Additionally, the bwctld processes share the results from their respective sides of the test with each other.
For more information check the man page: http://www.internet2.edu/performance/bwctl/manpages.html[/expand]