I noticed that when I ping different sites, the outgoing ICMP has varying TTL values for example:
ping 8.8.8.8
Pinging 8.8.8.8 with 32 bytes of data:
Reply from 8.8.8.8: bytes=32 time=68ms TTL=116
Reply from 8.8.8.8: bytes=32 time=71ms TTL=116
Reply from 8.8.8.8: bytes=32 time=69ms TTL=116
Reply from 8.8.8.8: bytes=32 time=69ms TTL=116
whereas
ping 1.1.1.1
Pinging 1.1.1.1 with 32 bytes of data:
Reply from 1.1.1.1: bytes=32 time=94ms TTL=52
Reply from 1.1.1.1: bytes=32 time=89ms TTL=52
Reply from 1.1.1.1: bytes=32 time=87ms TTL=52
Reply from 1.1.1.1: bytes=32 time=92ms TTL=52
So, how does the OS decide that for 8.8.8.8 it is good to set high TTL whereas for 1.1.1.1 a lower TTL is fine?
The TTL is determined by the remote host. The ping you see in the shell is the echo response. The initial TTL is set by the OS. Linux uses 64, Windows 128 and Routers 255. Every Hop reduces the TTL by at least 1.
For example: If you ping an Linux Host and there are 12 Hops between, than the TTL is 64-12 = 52.
Related
I'm in a test environment trying to use Wireshark to capture credentials being passed to MySQL. I've done some digging and I read that the MySQL client hashes the password before sending even when passing unencrypted. So, when I capture the packet containing the credentials, I'm expecting to see the username in the clear and the hashed password being passed, but that's not what I see. The username is in the clear, but the password doesn't equal the hashed password from the database. What's even weirder is the password changes in the packet, each time I log in.
WireShark Login Packet #1:
MAX Packet: 16777216
Charset: utf8 COLLATE utf8_general_ci (33)
Username: root
Password: ada5be054b6a9b44eaa0d86e33fb9442e8af7169
Client Auth Plugin: mysql_native_password
WireShark Login Packet #2:
MAX Packet: 16777216
Charset: utf8 COLLATE utf8_general_ci (33)
Username: root
Password: 78a85ed4ba56ae733057226fdc0a189b7672a0a7
Client Auth Plugin: mysql_native_password
WireShark Login Packet #3:
MAX Packet: 16777216
Charset: utf8 COLLATE utf8_general_ci (33)
Username: root
Password: f097e87cbba8f39cbaa3403dd5f7c966e3ed3969
Client Auth Plugin: mysql_native_password
I've looked at MySQL documentation and searched the Internet and can't seem to find anything on this. Does anyone have any thoughts/ideas?
Thanks for your help!
Not an expert in MySQL, but typically password authorization is protected from replay attack, so sniffing network shouldn't allow attacker to authorize by sending exactly the same data. This is usually done with nonce: server sends unique data, so client must provide hash(nonce + password_hash) in order to authorize. On next connection different nonce is provided, different authorization data must be sent, so previous authorization data can't be reused.
Also note, that hash might be hash of hash of hash of hash and include salt on one or multiple steps, so comparing sent data with known password requires knowing exact algorithm.
Lets observe a wireshark dump of a mysql_native_password authentication of username "apoc" with the password "rockyou".
First we receive a MySQL Protocol Server Greeting (using MariaDB 10.3.31):
MySQL Protocol
Packet Length: 111
Packet Number: 0
Server Greeting
Protocol: 10
Version: 5.5.5-10.3.31-MariaDB-1:10.3.31+maria~focal
Thread ID: 10
Salt: rC6%U]Tk
Server Capabilities: 0xf7fe
Server Language: latin1 COLLATE latin1_swedish_ci (8)
Server Status: 0x0002
Extended Server Capabilities: 0x81bf
Authentication Plugin Length: 21
Unused: 000000000000
MariaDB Extended Server Capabilities: 0x00000007
Salt: #;H8~5)orp]_
Authentication Plugin: mysql_native_password
Our client responds with the Login Request:
MySQL Protocol
Packet Length: 208
Packet Number: 1
Login Request
Client Capabilities: 0xa684
Extended Client Capabilities: 0x20ff
MAX Packet: 16777216
Charset: utf8 COLLATE utf8_general_ci (33)
Unused: 00000000000000000000000000000000000000
MariaDB Extended Client Capabilities: 0x00000005
Username: apoc
Password: e12a39bbf61a19c68413fa57fc65c7af3a86b85f
Client Auth Plugin: mysql_native_password
Connection Attributes
The way mysql_native_password is calculating the client password that is sent in the Login Request is using this formular (documented here):
SHA1( password ) XOR
SHA1( "20-bytes random data from server" <concat> SHA1( SHA1( password ) ) )
To reconstruct the password we received in the Login Request (e12a39bbf61a19c68413fa57fc65c7af3a86b85f) we need the 20 bytes of random data (the salts) in the server greeting request.
The seed is made up of the two Salt parameters received in the Server Welcome request, rC6%U]Tk and #;H8~5)orp]_ (20 bytes concatenated).
To calculate the client password hash the client uses this formular:
SHA1( "rockyou" ) XOR
SHA1( "rC6%U]Tk#;H8~5)orp]_" <concat> SHA1( SHA1( "rockyou" ) ) )
= "e12a39bbf61a19c68413fa57fc65c7af3a86b85f"
You can use this python code to reconstruct the hash:
from binascii import hexlify
from hashlib import sha1 as sha1_
def sha1(data):
h = sha1_()
h.update(data)
return h.digest()
def xor(x, y):
return (int.from_bytes(x, 'little') ^
int.from_bytes(y, 'little')).to_bytes(len(x), 'little')
# in numpy this is:
# data = np.bitwise_xor(
# np.frombuffer(x, dtype=np.uint8), np.frombuffer(y, dtype=np.uint8))
# return data.tobytes()
password = b'rockyou'
salt = b"rC6%U]Tk"
salt += b"#;H8~5)orp]_"
hashed = xor(sha1(password), sha1(salt + sha1(sha1(password))))
print(hexlify(hashed))
I have a peculiar problem with Postfix 3.1.0:
When a connecting client issues EHLO, the server responds with a line that contains its internal hostname, instead of the expected value of the smtpd_banner parameter.
telnet 127.0.0.1 25
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
220 mxdomain.com ESMTP
EHLO a.aa
250-localhost.name.internal
250-PIPELINING
250-SIZE 41943040
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250 8BITMIME
In the above example
the mxdomain.com ESMTP has been configured using smtpd_banner = mxdomain.com ESMTP in main.cf.
The localhost.name.internal text, I would like to have to be the same mxdomain.com text. The current value comes from $myhostname
How do I make the second banner contain mxdomain.com, or can it be removed somehow?
How do I make the second banner contain mxdomain.com, or can it be removed somehow?
Don't set smtpd_banner, set myhostname instead e.g.:
myhostnasme = mx.domain.com
The Ping command uses an ICMP request as far as I know
So is it possible to send a short text with the ping command right from commandline?
What about ping -p pattern? Keep in mind that not all of versions of ping support -p option.
You may specify up to 16 ''pad'' bytes to fill out the packet you
send. This is useful for diagnosing data-dependent problems in a
network. For example, -p ff will cause the sent packet to be filled
with all ones.
E.g. ping -p 486920686572652e www.example.com, where 486920686572652e = Hi here.
#!/bin/python3
import sys, subprocess
text = sys.argv[1]
target = sys.argv[2]
if len(text)>16:
print("Text too long!")
exit()
enctext = r''.join( hex(ord(c)).split("x")[1] for c in text )
subprocess.check_output(["ping", "-p", enctext, "-c", "1", target])
Maybe this piece of code is helpful for somebody
when i try ping command and when i see it in wireshark first ARP request is going and after the ARP reply only ICMP request is going ,
i think this is what the reason for the ARP request going in the first,,
while trying ping it need to know the MAC address of the target device,
so its trying to the get the MAC address first and then its sending ICMP request
if that is true is it possible to mention the mac address in the ping command(not to try for ARP)
if that is not true what's the reason
You'll note that the ARP request only happens the first time you run ping. If you run it a second time (shortly after the first run), you'll see that the ping start immediately with an ICMP request. This is because when a system discovers the IP address/MAC address association via ARP, it stores the result in a local arp cache. Entries in the cache do expire after some amount of time.
You can manually populate the ARP cache using the arp command:
arp -s <ipaddr> <macaddr>
E.g.:
arp -s 192.168.1.1 192.168.1.1
You can see the contents of your ARP cache like this:
arp -an
So if you were to manually update the ARP cache with the MAC address of your target host, you would be able to ping it with an ARP request going over the network.
I have been able to reach e7502.ce.akamaiedge.net from compute engine instances until yesterday.
Tried to ping the host, giving me the following result:
$ ping -w 5 e7502.ce.akamaiedge.net
PING e7502.ce.akamaiedge.net (23.35.168.70) 56(84) bytes of data.
--- e7502.ce.akamaiedge.net ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 5000ms
While the host is reachable from another PC:
>ping 23.35.168.70
Pinging 23.35.168.70 with 32 bytes of data:
Reply from 23.35.168.70: bytes=32 time=186ms TTL=54
Reply from 23.35.168.70: bytes=32 time=187ms TTL=54
Reply from 23.35.168.70: bytes=32 time=186ms TTL=54
Reply from 23.35.168.70: bytes=32 time=187ms TTL=54
Ping statistics for 23.35.168.70:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 186ms, Maximum = 187ms, Average = 186ms
Any idea how to fix this? Thanks for your help.