Monthly Archives: February 2014

I doubt people are wondering…

I doubt it, but in case people are wondering why I’ve move to more of a book review format… My class load is taking up a lot of my free time. In fact I should be working on my Art project for EMU Gen-Ed Right now (well now when I’m writing this, not when you read this).

Doing homework is more or less preventing me from doing a lot of the things I would rather be doing. Granted I have a nice stack of books that tie in to Information and Cyber Security to read as well. However, while my Digital Forensics class occasionally brings up interesting things to talk about, the majority of my time is spent in Psych 101 and Psych 103 (Lab). This week has been tied up with a 1 week accelerated class, but it hasn’t left time for me to do other things. It’s not as easy as the Counter Terrorism class was last year. Ok, yes my Saturday’s are tied up with an interesting OSINT project, but I can’t talk about that yet.

Anyway, back to the point of this post. I know it seems like my content has gone from a really cool OSINT post (which I have at least 2 follow ups to), to mostly book reviews, but I’m trying to kill 2 birds with one stone here.

I do have some topics from other books I’ve been reading (I’m usually reading more than one non-school books at a time), the project above, some followup OSINT posts, a paper from last year to finish water marking and sharing on here, and a few other things. But those have to wait until I have some free time. Now… where did I put those crayons for intro to art?

Book Review: Infiltration Presents: Access All Areas

I’ve finally finished “Infiltration Presents: Access All Areas – A User’s Guide to the Art of Urban Exploration” by Ninjalicious. This is one of a handful of books I have on Physical Security, and it’s taken me a couple of years to read it, because it kept getting lost in moves, and forgotten about when I when class loads got heavy.

I like this book, because it’s about accessing the area’s that are normally off limit to the public. It talks about Social Engineering, the equipment you’ll need (hint leave the lock picks at home), but most importantly HOW to find the places to explorer, and how to by-pass the systems put in place. Nice alarm there, shame you disconnected it due to all the false rings.

If you have an interest in the physical side, or an interest in historical building and abandoned things, this is a decent read.

Zero Day by Mark Russinovich and Howard Schmidt

I recently finished reading Zero Day. Over all I liked the concept. The end was interesting but easy to see coming. The biggest issue I had with the book though was it came off under-researched when it came to the cultures.

The portrayal of foreign cultures in the book were very stereotypical of what we’ve seen from American propaganda, known as television and movies. It doesn’t fit with other books that I’ve read that have taken place in those cultures. Mostly they have been non-fiction and travel books.

Over all the story was pretty good, but the they were not as good as Daniel Saurez‘s books, I’m not sure if I’m going to get the book by Mark Russinovich yet.

I like the fact that we’re seeing more techno-thrillers coming on to the market, especially since they’re written by people that know the technology. They’re good reads, for general mass market reads. It also makes what we do accessible to people outside of our industry.

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.