Tag Archives: tools

Raspberry Pi projects

Back in May and June, I did a project for school with 6 Raspberry Pis to build a WIDs. It went good. I wrote an article, I’m waiting to hear back if it’ll get published.

After the project, I had 6 Raspberry Pis kicking around. I have a project I want to work on, that could lead to another article. I just need to build my skills up to that first.

To get there, I wanted to build an Onion Pi. This will tie in to another project I’m working on. As some of you know I’m a fan of The Onion Router (TOR), especially when I’m doing Intelligence related research. The Onion Pi would be a good thing to have in the bag of tricks.

To get the Onion Pi working, I needed to go through the Adafruit Wifi Access Point. This is the second time I build an AP. This one is just a little different than last time. This time instead of an Edimax wireless card, I went with one of my TP Link TL-WN722Ns. I wanted the external antenna. I was using the 2014-09-09_wheezy_raspbian image.

Hostapd didn’t work right. It kept throwing errors on start about nl80211 not being a known driver. I had to build hostapd from source, which needed to have libssl-dev and libnl-1.1 installed, to get hostpad to build right. Then I needed to copy my built version into the right place.

I also had problems with isc-dhcp-server and tor starting. It looks like wlan0 isn’t starting properly. I’ll have to troubleshoot it more later. Adafruit has a comment about disabling wpa_supplicant. I don’t know if that will fix the problem though. I’ll follow up after.

Practical Anonymity by Peter Loshin

I got a copy of Practical Anonymity by Peter Loshin a while back via O’Reilly, had a sell on it. I finished it about two weeks ago. For what it sounded like it would be, I’m disappointed. I was expecting something more along the lines of “How to be Invisible”. For what it was, it was pretty good.

Continue reading

knowing what your tools do

When I changed my firewall rule policy, part the reason for doing it was because I was getting tired of seeing dovecot:auth failures in the logs. People around the world were brute forcing my mail server, and the rules were 100 lines long of just blocking. I had thought that they were coming from people hitting port 993 (IMAPS), and to a point there were. You can see below where it is dropping port 993 access attempts.

Continue reading

All the ip addresses that DenyHosts blocked

One of the things I did after getting iptables tweaked, was to clear my /etc/hosts.deny file. About 99% of these were put there by DenyHosts. Which is a great little background daemon that looks for failed log in attempts over ssh and then blocks the attacker by adding them to the /etc/hosts.deny file.

Since I know some people are looking for these types of addresses for different reasons, and there are over 2300+ unique ones in the list, I shared it publicly. You can get the list at pastebin.

 

 

Firewalls and the default deny rule, does that make us bad?

Over the last few weeks I’ve been thinking of redoing my iptables, but by putting in a default deny rule, does that make us bad netizens? By dropping everything that isn’t allowed, it actually makes it harder to fix the original problem. The fact that there are attacks to begin with, and the fact that boxes are compromised.

Over the last few months, since fixing the IMAPS part of my mail server, I noticed people hitting the server and failing to log in. These were not targeted attacks; they were automated bots, using the same users and possible passwords. I’d block them at the firewall but every day, there would be at least 2 new networks. Not all of them from overseas.

For historical reasons I take a stance of contacting the abuse email for North American companies, and some European ones. I found that the large Cable Company ISPs, usually turn out to be black holes. The smaller ones though actually reply back.

Last week I went through a week’s worth of logs, and out of the 47 ip addresses, there were about 30 networks. I actually sent 17 emails, and blocked only 13 networks. From that, 9 replied. Granted they were mostly the auto-replys, but I did have 2 that were interesting. One was from an ISP in England and they thanked me for letting them know. The other was an educational ISP in California. They replied back where they found the problem, and the IR procedures, with a thank you.

That worked because I wasn’t blocking the inbound connections, and letting other tools protect the server’s processes. However the iptable rules had become larger than I wanted to maintain (over 100) for inbound access.  So I re-wrote them using a default deny. I now state what on my network can be talked to, and in some cases by what networks. Everything else gets dropped and logged.

The down side to this is that while I can see the dropped connection attempts, I can’t see what the people are trying to do. Is it just a null hit, a failed loggin attempt, something else. I also can’t report it back to other interested parties. While I feel better about their failures, I realize that I’m a bad Netizen because I can’t contact their upstream, with logs showing the problem.

Yes, I know I could set up a honey pot system and fight for both the user and the internet that way, but it feels more like just being the complaint department than it does trying to solve things.

While I am going to keep using the default deny, because it’s easier to handle the rules on the firewall, I still don’t like that I’m walling myself off from the real problem, and not trying to fix underlying issue.

My name is Chris J, and this is how I do OSINT.

I’ve always been a fan of Lifehacker’s How I Work series, while this isn’t for Lifehacker, this is my “How I do Open Source Intelligence”. Recently a friend called and asked how I tracked data when doing OSINT. These are the tools and processes I use. It’s the what works for me, and your mileage may vary.

The tools I use are a legal pad, a computer, a web browser, a personal wiki, a data analysis tool and depending on the work Tails and a SD card. 

Continue reading