SSHFP records provide a secure method of distributing host public keys via DNS. The document discusses:
1) How SSHFP records store the fingerprint of a host's public key in DNS, allowing clients to validate the key via DNS lookup rather than trusting the host directly.
2) Instructions for generating SSHFP records for network devices that may not support all SSH commands, including extracting public keys and generating fingerprints.
3) Configuration details for distributing the SSHFP records in DNS and validating them during SSH connections using DNSSEC, avoiding the need to manually accept host keys.
Apresentação na Pós-Graduação em Segurança da Informação:
- Sniffer de senhas em plain text;
- Ataque de brute-force no SSH;
- Proteção: Firewall, IPS e/ou TCP Wrappers;
- Segurança básica no sshd_config;
- Chaves RSA/DSA para acesso remoto;
- SSH buscando chaves no LDAP;
- Porque previnir o acesso: Fork Bomb
Part 3 - Local Name Resolution in Linux, FreeBSD and macOS/iOSMen and Mice
The focus of this webinar will be to take a deeper look into this local name-resolution system and the implementations for other Unix systems like Linux and FreeBSD. Linux’s new über-Daemon “systemd” supports both mDNS and the Windows LLMNR (Link-Local-Multicast-Name-Resolution). We will also show how well a Systemd-Linux behaves in heterogenous networks running both Windows and macOS.
Apresentação na Pós-Graduação em Segurança da Informação:
- Sniffer de senhas em plain text;
- Ataque de brute-force no SSH;
- Proteção: Firewall, IPS e/ou TCP Wrappers;
- Segurança básica no sshd_config;
- Chaves RSA/DSA para acesso remoto;
- SSH buscando chaves no LDAP;
- Porque previnir o acesso: Fork Bomb
Part 3 - Local Name Resolution in Linux, FreeBSD and macOS/iOSMen and Mice
The focus of this webinar will be to take a deeper look into this local name-resolution system and the implementations for other Unix systems like Linux and FreeBSD. Linux’s new über-Daemon “systemd” supports both mDNS and the Windows LLMNR (Link-Local-Multicast-Name-Resolution). We will also show how well a Systemd-Linux behaves in heterogenous networks running both Windows and macOS.
Presentation done at Kamailio World 2013, Berlin, Germany - several options for scalability of SIP routing with Kamailio, from configuration file tricks to stateless and stateful load balancing with dispatcher module.
We present findings in addition to the work in the following analyses.Worm Backdoors and Secures QNAP Network Storage Devices. https://isc.sans.edu/forums/diary/Worm+Backdoors+and+Secures+QNAP+Network+Storage+Devices/19061
Shellshock Worm Exploiting Unpatched QNAP NAS Devices https://threatpost.com/shellshock-worm-exploiting-unpatched-qnap-nas-devices/109870
A little ShellShock fun http://jrnerqbbzrq.blogspot.com/2014/12/a-little-shellshock-fun.html
This is what we found, missing pieces from previous researches.
Relayd is a daemon to relay and dynamically redirect incoming connections to a target host.
Its main purposes are to run as a load-balancer, application layer gateway, or transparent proxy.
DNS High-Availability Tools - Open-Source Load Balancing SolutionsMen and Mice
The DNS protocol has built-in high availability for authoritative DNS servers (this will be better explained in the webinar!), but client machines can see a degraded DNS service if a DNS resolver (caching DNS server) is failing.
In this webinar, we will look into how the DNS clients in popular operating systems (Windows, Linux, macOS/iOS) choose the DNS resolver among a list of available servers, and how a DNS resolver service can be made failure-tolerant with open-source solutions such as “dnsdist” from PowerDNS and “relayd” from OpenBSD.
This webinar is designed as an easy-to-follow tutorial on DNSSEC signing a zone for DNS admins. Our focus will be on DNSSEC zone signing automation with the Knot DNS Server and BIND 9.
Yeti-DNS is an international research project with the purpose of testing new technologies and procedures in running the Internet root zone. The project runs tests on DNSSEC key rollovers in the root, as well as experimenting with new ways to manage the DNSSEC keys (multiple zone signing keys).
An interview with Shane Kerr, a coordinator for the Yeti-DNS project, forms part of this webinar. The interview sheds light on the technical and political aspects of the project and introduces the latest results from experiments.
The webinar also includes a tutorial on how to use the Yeti-DNS root name servers to configure a BIND 9 DNS resolver in order to take part in the project.
Managing server secrets at scale with SaltStack and a vaultless password managerIgnat Korchagin
Ever wondered how to quickly and efficiently roll over all of your 1000 servers’ SSH keys? How to securely manage diskless systems and horizontally / vertically scale their credentials? This talk will introduce a simple approach that combines some hardware support, a little cryptography and SaltStack to help operationalise the management of all the secrets in your cloud
I’ve been keeping a collection of Linux commands that are particularly useful; some are from websites I’ve visited, others from experience
I hope you find these are useful as I have. I’ll periodically add to the list, so check back occasionally.
DOD 2016 - Ignat Korchagin - Managing Server Secrets at ScalePROIDEA
Operating a large cluster, a datacenter or a distributed network involves dealing with a lot of secrets on your hardware. Almost in any case for any setup you have to deal with at least four types of secrets for each piece of hardware: SSH server key (or shell access key), key to bootstrap your configuration management system, disk encryption key and maybe some per-server credentials to access other services. Also, most of the times, these keys have to be set up before your configuration management kicks in, so automating this process may be hard. Security wise, it is important to control where and when those secrets are generated. Often, keys are generated by startup scripts. However, during initial boot (especially on diskless systems) the system may have low entropy level in its internal random number generator, so generated keys may end up being statistically weak. Once you have your keys, you need to store them somewhere securely. Encrypted disk is a great solution, but guess what? You need a key to access an encrypted disk, so there is a chicken-and-egg problem. Also, where do you store keys for diskless systems? This talk shows an approach how a simple combination of hardware support and little cryptography can deal with above issues and unify and simplify secret management for you hardware fleet.
Presentation done at Kamailio World 2013, Berlin, Germany - several options for scalability of SIP routing with Kamailio, from configuration file tricks to stateless and stateful load balancing with dispatcher module.
We present findings in addition to the work in the following analyses.Worm Backdoors and Secures QNAP Network Storage Devices. https://isc.sans.edu/forums/diary/Worm+Backdoors+and+Secures+QNAP+Network+Storage+Devices/19061
Shellshock Worm Exploiting Unpatched QNAP NAS Devices https://threatpost.com/shellshock-worm-exploiting-unpatched-qnap-nas-devices/109870
A little ShellShock fun http://jrnerqbbzrq.blogspot.com/2014/12/a-little-shellshock-fun.html
This is what we found, missing pieces from previous researches.
Relayd is a daemon to relay and dynamically redirect incoming connections to a target host.
Its main purposes are to run as a load-balancer, application layer gateway, or transparent proxy.
DNS High-Availability Tools - Open-Source Load Balancing SolutionsMen and Mice
The DNS protocol has built-in high availability for authoritative DNS servers (this will be better explained in the webinar!), but client machines can see a degraded DNS service if a DNS resolver (caching DNS server) is failing.
In this webinar, we will look into how the DNS clients in popular operating systems (Windows, Linux, macOS/iOS) choose the DNS resolver among a list of available servers, and how a DNS resolver service can be made failure-tolerant with open-source solutions such as “dnsdist” from PowerDNS and “relayd” from OpenBSD.
This webinar is designed as an easy-to-follow tutorial on DNSSEC signing a zone for DNS admins. Our focus will be on DNSSEC zone signing automation with the Knot DNS Server and BIND 9.
Yeti-DNS is an international research project with the purpose of testing new technologies and procedures in running the Internet root zone. The project runs tests on DNSSEC key rollovers in the root, as well as experimenting with new ways to manage the DNSSEC keys (multiple zone signing keys).
An interview with Shane Kerr, a coordinator for the Yeti-DNS project, forms part of this webinar. The interview sheds light on the technical and political aspects of the project and introduces the latest results from experiments.
The webinar also includes a tutorial on how to use the Yeti-DNS root name servers to configure a BIND 9 DNS resolver in order to take part in the project.
Managing server secrets at scale with SaltStack and a vaultless password managerIgnat Korchagin
Ever wondered how to quickly and efficiently roll over all of your 1000 servers’ SSH keys? How to securely manage diskless systems and horizontally / vertically scale their credentials? This talk will introduce a simple approach that combines some hardware support, a little cryptography and SaltStack to help operationalise the management of all the secrets in your cloud
I’ve been keeping a collection of Linux commands that are particularly useful; some are from websites I’ve visited, others from experience
I hope you find these are useful as I have. I’ll periodically add to the list, so check back occasionally.
DOD 2016 - Ignat Korchagin - Managing Server Secrets at ScalePROIDEA
Operating a large cluster, a datacenter or a distributed network involves dealing with a lot of secrets on your hardware. Almost in any case for any setup you have to deal with at least four types of secrets for each piece of hardware: SSH server key (or shell access key), key to bootstrap your configuration management system, disk encryption key and maybe some per-server credentials to access other services. Also, most of the times, these keys have to be set up before your configuration management kicks in, so automating this process may be hard. Security wise, it is important to control where and when those secrets are generated. Often, keys are generated by startup scripts. However, during initial boot (especially on diskless systems) the system may have low entropy level in its internal random number generator, so generated keys may end up being statistically weak. Once you have your keys, you need to store them somewhere securely. Encrypted disk is a great solution, but guess what? You need a key to access an encrypted disk, so there is a chicken-and-egg problem. Also, where do you store keys for diskless systems? This talk shows an approach how a simple combination of hardware support and little cryptography can deal with above issues and unify and simplify secret management for you hardware fleet.
Presenting adhocr (abbreviation for Ad-hoc copy and run) as a simple, but powerful UNIX administrator tool. If you like to retrieve data or execute commands on lots of systems simultaneously then this tool is your friend. There is no need to exchange your ssh keys as the power behind adhocr is the expect tool (language). For example, it is plain easy to use adhocr to distribute your public ssh key to all your systems. The real power of adhocr is the central point of logging, which is perfect for \'grep\'ing into stuff you\'re looking for.
You also have the ability to execute commands via the \'sudo su -\' way, which is a blessing in environments where root is not permitted to login directly.
You can even use it monitoring your systems thanks to the powerful error catching.
Jaime Piña, @variadico, Software Engineer at Apcera
Microservice issues are networking issues. Fixing code in your app is easy, but the hard part of using microservices is the networking. How do you actually know if you're sending what you think you are? Why does this request fail in my app, but not when I use curl? Is this service very slow or is it up at all?
This talk will help demystify some common problems you might experience while building out your collection of microservices. Once you can find the issue, it becomes way easier to fix.
In this workshop we will make a brief introduction to the basics of networking: IP addresses, MAC addresses, DNS, DHCP. Concepts as a router, gateway and firewall are explained. Then we will see in practice how to share files on a local network (NFS, Samba), establish a FTP connection, or log on to another (Linux) machine remotely (SSH, VNC, RDP). Finally, we review some useful networking tools like ping, netstat, lookup, port scan, traceroute, whois.
APNIC Foundation, presented by Ellisha Heppner at the PNG DNS Forum 2024APNIC
Ellisha Heppner, Grant Management Lead, presented an update on APNIC Foundation to the PNG DNS Forum held from 6 to 10 May, 2024 in Port Moresby, Papua New Guinea.
Registry Data Accuracy Improvements, presented by Chimi Dorji at SANOG 41 / I...APNIC
Chimi Dorji, Internet Resource Analyst at APNIC, presented on Registry Data Accuracy Improvements at SANOG 41 jointly held with INNOG 7 in Mumbai, India from 25 to 30 April 2024.
APNIC Policy Roundup, presented by Sunny Chendi at the 5th ICANN APAC-TWNIC E...APNIC
Sunny Chendi, Senior Advisor, Membership and Policy at APNIC, presents 'APNIC Policy Roundup' at the 5th ICANN APAC-TWNIC Engagement Forum and 41st TWNIC OPM in Taipei, Taiwan from 23 to 24 April.
DDoS In Oceania and the Pacific, presented by Dave Phelan at NZNOG 2024APNIC
Dave Phelan, Senior Network Analyst/Technical Trainer at APNIC, presents 'DDoS In Oceania and the Pacific' at NZNOG 2024 held in Nelson, New Zealand from 8 to 12 April 2024.
'Future Evolution of the Internet' delivered by Geoff Huston at Everything Op...APNIC
Geoff Huston, Chief Scientist at APNIC deliver keynote presentation on the 'Future Evolution of the Internet' at the Everything Open 2024 conference in Gladstone, Australia from 16 to 18 April 2024.
IP addressing and IPv6, presented by Paul Wilson at IETF 119APNIC
Paul Wilson, Director General of APNIC delivers a presentation on IP addressing and IPv6 to the Policymakers Program during IETF 119 in Brisbane Australia from 16 to 22 March 2024.
draft-harrison-sidrops-manifest-number-01, presented at IETF 119APNIC
Tom Harrison, Product and Delivery Manager at APNIC presents at the Registration Protocols Extensions working group during IETF 119 in Brisbane, Australia from 16-22 March 2024
Benefits of doing Internet peering and running an Internet Exchange (IX) pres...APNIC
Che-Hoo Cheng, Senior Director, Development at APNIC presents on the "Benefits of doing Internet peering and running an Internet Exchange (IX)" at the Communications Regulatory Commission of Mongolia's IPv6, IXP, Datacenter - Policy and Regulation International Trends Forum in Ulaanbaatar, Mongolia on 7 March 2024
APNIC Update and RIR Policies for ccTLDs, presented at APTLD 85APNIC
APNIC Senior Advisor, Membership and Policy, Sunny Chendi presented on APNIC updates and RIR Policies for ccTLDs at APTLD 85 in Goa, India from 19-22 February 2024.
This 7-second Brain Wave Ritual Attracts Money To You.!nirahealhty
Discover the power of a simple 7-second brain wave ritual that can attract wealth and abundance into your life. By tapping into specific brain frequencies, this technique helps you manifest financial success effortlessly. Ready to transform your financial future? Try this powerful ritual and start attracting money today!
Multi-cluster Kubernetes Networking- Patterns, Projects and GuidelinesSanjeev Rampal
Talk presented at Kubernetes Community Day, New York, May 2024.
Technical summary of Multi-Cluster Kubernetes Networking architectures with focus on 4 key topics.
1) Key patterns for Multi-cluster architectures
2) Architectural comparison of several OSS/ CNCF projects to address these patterns
3) Evolution trends for the APIs of these projects
4) Some design recommendations & guidelines for adopting/ deploying these solutions.
ER(Entity Relationship) Diagram for online shopping - TAEHimani415946
https://bit.ly/3KACoyV
The ER diagram for the project is the foundation for the building of the database of the project. The properties, datatypes, and attributes are defined by the ER diagram.
1.Wireless Communication System_Wireless communication is a broad term that i...JeyaPerumal1
Wireless communication involves the transmission of information over a distance without the help of wires, cables or any other forms of electrical conductors.
Wireless communication is a broad term that incorporates all procedures and forms of connecting and communicating between two or more devices using a wireless signal through wireless communication technologies and devices.
Features of Wireless Communication
The evolution of wireless technology has brought many advancements with its effective features.
The transmitted distance can be anywhere between a few meters (for example, a television's remote control) and thousands of kilometers (for example, radio communication).
Wireless communication can be used for cellular telephony, wireless access to the internet, wireless home networking, and so on.
2. SSHFP
root@ns:~ # ssh root@pdr.bofh.network
The authenticity of host 'pdr.bofh.network (2604:6800:0:162:0:1:0:1)'
can't be established.
ECDSA key fingerprint is
SHA256:AlzRr/ZNFC9fjs89jYAD1o2dFDs4vu3gUVUD7gI2QBk.
No matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)?
●
Have you ever logged in that host or device ?
●
Have you ever checked the public key ?
●
Do you know the SHA256 Fingerprint of the ECDSA Public Key?
●
99.9% Sysadmin or Network admin never checks it @ console
●
Victm of MITM Atack
3. SSHFP
●
First came up in 2006
●
Defined in RFC 4255
●
Creates a DNS record of type SSHFP
●
Distributed by DNS, Verified by DNS lookup and
secured by DNSSEC
6. Why SSHFP?
●
SSH Public Key size are large to distribute via DNS
●
So need the fingerprint
●
Fingerprint method
– Base64
– sha1/sha256 checksum
7. What we need?
●
Fingerprints of the host
●
Proper SSHFP DNS records
●
Zone must be DNSSEC signed
●
A DNSSEC validator DNS server or ldns support in
ssh client
●
A SSH client capable to verify DNSSEC validated
fingerprint
8. Fingerprints of the host?
root@pdr:~ # ssh-keygen -r pdr.bofh.network
pdr.bofh.network IN SSHFP 1 1 2cfb54c336799bf601a17a6b2723d096ed23ce55
pdr.bofh.network IN SSHFP 1 2
95a39495ec59ad717c0990bfe1f3c8ddd9e2b1201065e0ca5fc381cbc7ea8d8b
pdr.bofh.network IN SSHFP 2 1 90eb07d57e037aacbec479ed3a4c6a1264edf4f0
pdr.bofh.network IN SSHFP 2 2
eccdc4d93bb9af3eb4791e30f66aa327d9f0c9c388f5e950159ec285bb746783
pdr.bofh.network IN SSHFP 3 1 491ff6cd714362c5bae223fc2c942dbf78c3ba0e
pdr.bofh.network IN SSHFP 3 2
597d44db5b0e28f787ad5b1535e8b201e509373f8a8e711c71c950556ecdf799
pdr.bofh.network IN SSHFP 4 1 c63d32f031cc3fc7fe867baf2d0cd23d4ef25213
pdr.bofh.network IN SSHFP 4 2
15d249791d60bc46ec400c3a16a66b1cca191b2d30464707e8e5ba204dea1433
10. Algorithm
●
Most modern OS will show all 4
●
Old OS might show only RSA and DSA
●
ECDSA and Ed25519 are modern Cryptographic
algorithm
●
Ed25519 added in RFC7479
●
For ECDSA and Ed25519 we need OpenSSH=>6.7
11. Distributing via DNS
root@pdr:~ # drill -D pdr.bofh.network sshfp
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 60914
;; flags: qr rd ra ad ; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; pdr.bofh.network. IN SSHFP
;; ANSWER SECTION:
pdr.bofh.network. 3599 IN SSHFP 2 1 90eb07d57e037aacbec479ed3a4c6a1264edf4f0
pdr.bofh.network. 3599 IN SSHFP 3 2 597d44db5b0e28f787ad5b1535e8b201e509373f8a8e711c71c950556ecdf799
pdr.bofh.network. 3599 IN SSHFP 3 1 491ff6cd714362c5bae223fc2c942dbf78c3ba0e
pdr.bofh.network. 3599 IN SSHFP 4 2 15d249791d60bc46ec400c3a16a66b1cca191b2d30464707e8e5ba204dea1433
pdr.bofh.network. 3599 IN SSHFP 1 2 95a39495ec59ad717c0990bfe1f3c8ddd9e2b1201065e0ca5fc381cbc7ea8d8b
pdr.bofh.network. 3599 IN SSHFP 4 1 c63d32f031cc3fc7fe867baf2d0cd23d4ef25213
pdr.bofh.network. 3599 IN SSHFP 1 1 2cfb54c336799bf601a17a6b2723d096ed23ce55
pdr.bofh.network. 3599 IN SSHFP 2 2 eccdc4d93bb9af3eb4791e30f66aa327d9f0c9c388f5e950159ec285bb746783
pdr.bofh.network. 3599 IN RRSIG SSHFP 8 3 3600 20171114225917 20171031212226 15678 dzcrd.net.
QBTRbj8xtyEN/9WH/PL39n1mC0XOKmGDj5TzgP/Kkvo7ac3wPwZ92dEcVnKyi1H2e8wP6532NIMjmuveyundnavCCbstOUfFyN17fBuEtHQTJzLmp8XQ7JxDgXbzbp6bvaKrck/XBFbRfk895oI9+Spg09fYkfseN4axEVoscQY=
;; AUTHORITY SECTION:
;; ADDITIONAL SECTION:
;; Query time: 1750 msec
;; EDNS: version 0; flags: do ; udp: 512
;; SERVER: 127.0.0.1
;; WHEN: Wed Nov 1 21:35:20 2017
;; MSG SIZE rcvd: 530
13. If ldns is supported ..
●
Need to maintain a trust-anchor
● Run unbound-anchor
●
Add to /etc/resolv.conf
anchor /etc/unbound/root.key [*BSD]
anchor /var/lib/unbound/root.key [Linux]
14. Else ..
●
Run a validating resolver like Unbound
server:
auto-trust-anchor-file:
"/etc/unbound/root.key"
15. Test
● root@pdr:~$ ssh root@pdr.bofh.network
The authenticity of host 'pdr.bofh.network
(2003:51:6012:110::9)' can't be established.
ECDSA key fingerprint is
SHA256:T09/p/ZSubnkraG3oslDMehfIiLRe6UiVn1dGZvtjZE.
Are you sure you want to continue connecting (yes/no)?
^C
● root@pdr:~$ ssh -o VerifyHostKeyDNS=yes
root@pdr.bofh.network
root@pdr:~$
17. SSH/SSHFP Demystified
●
SSH Creates Public/Private Keys
– For Linux/Unix under /etc/ssh/ssh_host_<ALGORITHM>.*
– Normally during first run of sshd service
– This part is automatic and hidden
●
ssh-keygen creates fingerprints for those keys
18. SSHFP for Network Equipments
●
Network Equipments don’t have ssh-keygen command
●
Equipments comes with limited subset of ssh
●
Configure ssh service for devices preferably version 2
●
Create the public/private keys normally RSA only
●
Gather the public key connecting through console or
direct point-to-point connectivity
●
Generate the Fingerprints for SSHFP records
20. Extracting Key
●
Connect with Console
●
Connect directly with point to point LAN
●
Use show ip ssh
– Copy the string starting with “ssh-rsa” and ending till last line
●
For remote connection add the key with prompt and verify
the keys
●
Save the file in a Linux/Unix host with filename like
hostname_rsa_key.pub
21. Using the script
#!/usr/local/bin/bash
HOST="${1}"
if [[ "$1" == "-h" || "$1" == "--help" ]]
then
echo "Usage: sshfpgen <hostname>"
fi
for pubkey in *_key.pub
do
echo "$HOST IN SSHFP 1 1 $(cut -f2 -d ' ' "$pubkey" | base64 --decode | shasum | cut -f 1 -d ' ')"
echo "$HOST IN SSHFP 1 2 $(cut -f2 -d ' ' "$pubkey" | base64 --decode | shasum -a 256 | cut -f 1 -d ' ')"
done
22. Running the script
root@ns:~ # ./sshfpgen r1.bofh.network
r1.bofh.network IN SSHFP 1 1 96898fe4604ed5e7b1a1c80374b1200fae3f4adb
r1.bofh.network IN SSHFP 1 2 ebfca263706e4e12c7189ae377014f30467af6e6243d3b8a7e5f763d2813023b
23. Adding to DNS
●
Following records were added into the DNS
r1.bofh.network IN SSHFP 1 1 96898fe4604ed5e7b1a1c80374b1200fae3f4adb
r1.bofh.network IN SSHFP 1 2 ebfca263706e4e12c7189ae377014f30467af6e6243d3b8a7e5f763d2813023b
●
DNS Query Test
$ dig SSHFP +noadditional +noquestion +nocomments +nocmd +nostats r1.bofh.network
r1.bofh.network. 3600 IN SSHFP 1 1 96898fe4604ed5e7b1a1c80374b1200fae3f4adb
r1.bofh.network. 3600 IN SSHFP 1 2 ebfca263706e4e12c7189ae377014f30467af6e6243d3b8a7e5f763d2813023b
24. Connectivity Test
●
Connecting without DNSSEC validation
$ ssh VerifyHostKeyDNS=yes r1.bofh.network
The authenticity of host 'r1.bofh.network (192.168.100.100)' can't be established.
RSA key fingerprint is SHA256:y2STsQ4RA/8durhpic+pb6UjcKwz7+bUaKX3C40yOGk.
Matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)?
25. Connectivity Test
●
Connecting with DNSSEC validation
$ ssh VerifyHostKeyDNS=yes r1.bofh.network
Username:
●
Also no records will be added in .known_host file