prowler - Tool for AWS security assessment, auditing and hardening by @Alfresco.
A2SV - Auto Scanning to SSL Vulnerability by @hahwul.
Reconnaissance
OSINT - Open-Source Intelligence
Shodan - Shodan is the world’s first search engine for Internet-connected devices by @shodanhq.
Censys - Censys is a search engine that allows computer scientists to ask questions about the devices and networks that compose the Internet by University of Michigan.
urlscan.io - Service which analyses websites and the resources they request by @heipei.
NSFOCUS - THREAT INTELLIGENCE PORTAL by NSFOCUS GLOBAL.
FOCA - FOCA (Fingerprinting Organizations with Collected Archives) is a tool used mainly to find metadata and hidden information in the documents its scans by ElevenPaths.
SpiderFoot - Open source footprinting and intelligence-gathering tool by @binarypool.
xray - XRay is a tool for recon, mapping and OSINT gathering from public networks by @evilsocket.
GSIL - Github Sensitive Information Leakage（Github敏感信息泄露）by @FeeiCN.
raven - raven is a Linkedin information gathering tool that can be used by pentesters to gather information about an organization employees using Linkedin by @0x09AL.
ReconDog - Recon Dog is an all in one tool for all your basic information gathering needs by @UltimateHackers.
EyeWitness - EyeWitness is designed to take screenshots of websites, provide some server header info, and identify default credentials if possible by @ChrisTruncer.
Certificate Transparency - Google’s Certificate Transparency project fixes several structural flaws in the SSL certificate system by @google.
Certificate Search - Enter an Identity (Domain Name, Organization Name, etc), a Certificate Fingerprint (SHA-1 or SHA-256) or a crt.sh ID to search certificate(s) by @crtsh.
GSDF - Domain searcher named GoogleSSLdomainFinder by @We5ter.
Code Generating
VWGen - Vulnerable Web applications Generator by @qazbnm456.
OpenRASP - An open source RASP solution actively maintained by Baidu Inc. With context-aware detection algorithm the project achieved nearly no false positives. And less than 3% performance reduction is observed under heavy server load.
Preventing
js-xss - Sanitize untrusted HTML (to prevent XSS) with a configuration specified by a Whitelist by @leizongmin.
Proxy
Charles - HTTP proxy / HTTP monitor / Reverse Proxy that enables a developer to view all of the HTTP and SSL / HTTPS traffic between their machine and the Internet.
mitmproxy - Interactive TLS-capable intercepting HTTP proxy for penetration testers and software developers by @mitmproxy.
Webshell
webshell - This is a webshell open source project by @tennc.
That’s good, but I was thinking something more to highlighting the common mistakes that have happened.
Like the samba add-on, x-forward, password leak with github…
Trying to concentrate some knowledge instead of being lost in different posts.
That is the basic idea of things. That way you can have multiple stuff in different folders like if you want to point /mymodem to your http interface of your cable modem you could. It would be wrapped in HTTPS then you could do a user ID/password as well. You could also run your own fail2ban filters as well for brute force checking. The one downside I found to HA was you couldn’t do a base URL on it like other apps that you can use with a reverse proxy. This put the HA login front line and center for some pen testing unlike say another app you put at /SDJ39SJ9JSJD-JDFI3JSCNSJS9JD or whatever other long location name you wanted. It’s a little bit of security by obscurity but someone would have to know that long URL to even begin beating on your login to figure out the user/password combo.
It isn’t only for serving multiple servers. It’s about what you trust as your front door.
HA is a very complex project that has access to a huge number of services and devices within your home. It’s only trivially protected by a single password. Even if you assume that HA has no backdoors or bugs that allow access, that’s like leaving your important documents filing cabinet out in the open. Even if the filing cabinet is secure, everyone will see it’s there and every bump goes directly to it.
Putting a reverse proxy in front, whether it be haproxy/nginx/apache limits your attack surface by effectively putting that file cabinet inside a room with a door. That door is now what everything has to go through to get to your file cabinet. Even if you accidentally left the cabinet open, like if you accidentally forgot to set a password on your HA instance, people still have to get through the door first. Alternatively, even if the cabinet was broken and had a hole in the back(i.e. has a horrible security bug), well it wouldn’t matter because people still have to go through the door, and they wouldn’t even know about the cabinet unless they got through the door first.
Now you can easily set up the proxy poorly, in effect leaving the door wide open and you gain no protection at all. But It is much easier to set up properly since it only does ONE thing, making it a much smaller attack surface, and more importantly, proxies are designed with access control in mind as a primary function. This means I would generally trust my proxy to be better at access control than an app like HA where access control is a secondary priority compared to functionality, and there are multiple methods of authenticating (password/api/token/headers etc etc) that need to be tested and protected.
Just for clarification I have Hassio and samba add on with guest activated and no password on Samba, but on Home Assistant. I haven’t opened any ports myself, but do have a Google Wifi router with UPNP activated. Does this then mean I unintentionally have opened my installation for everyone looking?
What is/are the preferred configuration(s) if I wish to utilize Amazon Echos or Google Homes with Home Assistant? Using these devices are the primary reason I have my Home Assistant instance exposed to the internet.
I only have port 443 forwarded to HA and UPNP is disabled. Guest SMB access is disabled. I don’t use the HA Cloud service. I’d like to continue to use Google Home and Amazon Echo, but would like greater security than one password for HA.
I know enough about network security to know that I don’t know enough about network security, It seems seeing up Nginx would be preferred, but that would break the Google and Amazon integrations. Is this correct? Before integrating these services, I would only access HA via a VPN into my network.
Any advice on beefing up my security while still using Google Home and Alexa? Thanks.
In theory this might be the case. But you should realize it’s not just Hassio Samba addon which could open ports. If UPnP is enabled any device or program (including mailware, etc.) could compromise the security of your network.
I tried yesterday to deactivate UPnP and that seems to render the Chromecats unusable. It also seems like it in Google’s docs:
“Learn More: Router has UPnP disabled
UPnP (Universal Plug and Play), also known as multicast, allows for the discovery of UPnP enabled devices on the same Wi-Fi network.
It appears that you have UPnP disabled on your router. This makes Chromecast undiscoverable”
UPnP isn’t just for “opening the ports” and UPnP discovery part of the protocol does use multicast. So depending on your network topology, you many need to have multicast enabled on the router in order for UPnP to work. Usually it is not a problem, when all devices are on the same network subnet.
Basically still using my own scripted Lets Encrypt certs rather than using caddy, mainly because I have my router scripted to open port 80 to HA when the cert is renewed, and then closed afterwards. Would rather not leave it permanently open for caddy. Caddy is also issuing a fake cert if users dont know my domain name and try to use IP address.
I also have caddy set to overwrite the X-Forwards-For header to the clients address to prevent faking of the clients IP address.
I am then using X-Forwards-For=true in configuration.yaml. I have tested curl with X-Forwards-For set to a fake address and it is replaced by the clients actual address. This means my fail2ban will still work.
With all of that taken into account, is it safe then to use X-Forwards-For and Trusted Networks together in HA?
