These are my notes basically. At first i created this gist just as a reminder for myself. But feel free to use this for your project as a starting point. If you have questions you can find me on twitter @thomasf https://twitter.com/thomasf This is how i used it on a Debian Wheezy testing (https://www.debian.org/releases/testing/)
Discuss, ask questions, etc. here https://news.ycombinator.com/item?id=7445545
| -- show running queries (pre 9.2) | |
| SELECT procpid, age(query_start, clock_timestamp()), usename, current_query | |
| FROM pg_stat_activity | |
| WHERE current_query != '<IDLE>' AND current_query NOT ILIKE '%pg_stat_activity%' | |
| ORDER BY query_start desc; | |
| -- show running queries (9.2) | |
| SELECT pid, age(query_start, clock_timestamp()), usename, query | |
| FROM pg_stat_activity | |
| WHERE query != '<IDLE>' AND query NOT ILIKE '%pg_stat_activity%' |
./bin/drill-embedded
OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=512M; support was removed in 8.0
Apr 19, 2017 4:53:50 PM org.glassfish.jersey.server.ApplicationHandler initialize
INFO: Initiating Jersey application, version Jersey: 2.8 2014-04-29 01:25:26...
apache drill 1.10.0
"drill baby drill"
Now visit link http://localhost:8047 to open up Apache Drill explorer and configure S3 storage plugin refer
| #!/bin/bash | |
| # Title: kinit_brute.sh | |
| # Author: @ropnop | |
| # Description: This is a PoC for bruteforcing passwords using 'kinit' to try to check out a TGT from a Domain Controller | |
| # The script configures the realm and KDC for you based on the domain provided and the domain controller | |
| # Since this configuration is only temporary though, if you want to actually *use* the TGT you should actually edit /etc/krb5.conf | |
| # Only tested with Heimdal kerberos (error messages might be different for MIT clients) | |
| # Note: this *will* lock out accounts if a domain lockout policy is set. Be careful |
| /* | |
| Metabase is lacking in some of the management information I’d like to see. Hopefully the queries below will help a few others build up a management dashboard too. | |
| In summary: | |
| 1. List of Dashboards | |
| 2. List of Questions | |
| 3. List of Questions in each Dashboard | |
| 4. List of Questions not in any Dashboard | |
| 5. List of Users | |
| 6. LIst of Users who have never logged in |
| #!/usr/bin/env bash | |
| sudo add-apt-repository -y ppa:ubuntu-toolchain-r/test | |
| sudo apt update | |
| sudo update-alternatives --remove-all gcc | |
| sudo update-alternatives --remove-all g++ | |
| sudo apt-get install -y gcc-4.8 g++-4.8 gcc-4.9 g++-4.9 gcc-5 g++-5 gcc-6 g++-6 gcc-7 g++-7 | |
| sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.8 10 |
| /* | |
| * Name: proc_mon.c | |
| * Compile: gcc proc_mon.c -o proc_mon | |
| * License: GNU GPL v2 (see LICENSE) | |
| */ | |
| #include <sys/socket.h> | |
| #include <linux/netlink.h> | |
| #include <linux/connector.h> | |
| #include <linux/cn_proc.h> | |
| #include <signal.h> |
One common and effective mitigation against Cross-Site Scripting (XSS) is to set the HTTPOnly flag on session cookies. This will generally prevent an attacker from stealing users' session cookies with XSS. There are ways of circumventing this (e.g. the HTTP TRACE method), but generally speaking, it is fairly effective. That being said, an attacker can still cause significant damage without being able to steal the session cookie.
A variety of client-side attacks are possible, but an attacker is also often able to circumvent Cross-Site Request Forgery (CSRF) protections via XSS and thereby submit various forms within the application. The worst case scenario with this type of attack would be that there is no confirmation for email address or password changes and the attacker can change users' passwords. From an attacker's perspective this is valuable, but not as valuable as being able to steal a user's session. By reseting the password, the attacker is giving away his presence and the extent to which
| /* | |
| ##Device = Desktops | |
| ##Screen = 1281px to higher resolution desktops | |
| */ | |
| @media (min-width: 1281px) { | |
| /* CSS */ | |
Despite how VPNs are often marketed, they do not make a person absolutely anonymous online. They only disguise your traffic to some third parties. A VPN will not stop services like Google or Amazon from recognizing you if you sign into their services, and VPNs also cannot stop the types of invasive data fingerprinting or web tracking technologies that are pretty good at guessing who you are without your knowledge or participation. VPNs are just one tool among many to protect your online privacy.
And they are a tool that requires you to trust the provider of the VPN service, which can be easier said than done. Trust, or lack thereof, is a huge problem in the world of VPNs. Even the Federal Trade Commission has basically suggested that “buyer beware” when it comes to researching and choosing a