Hacking, Anonymous, Antisec, and the Problem With Their Reasons

DISCLAIMER: I DO NOT IN ANY WAY, SHAPE, OR FORM SUPPORT “BLACK HAT” HACKING OR ANY OF IT’S AFFILIATED TOPICS.  I DO NOT SUPPORT OR KNOW ANYONE IN LULZSEC, ANONYMOUS, OR ANY OTHER ANTISEC OR BLACK HAT GROUP.

 

Anonymous and the various #Antisec groups out there always seem to claim that they’re doing something in the name of freedom.  Information should be publicly available.  We should protect those that wish to speak out against their governments.  They say that they’re hacking corporations and governments to attack oppression.

 

I support the freedom of information.  I’m an American, and despite the problems my country has, I am a patriot.  I believe that we should be able to express ourselves freely.  I’m against oppression of any kind, but some things aren’t oppression.  Some things are just policies. 

 

Maybe Bank of America, Sony, et al. don’t have the best security practices.  Does that mean that Anonymous should hack them and release the people’s personal, private information to the world?  Definitely not.  That’s unprofessional and childish.

 

How can you say that you’re trying to help people, that you’re carrying out retribution, if you’re exposing the personal information of the very people you claim to be fighting for?

 

If you’re truly fighting for freedom, for the people, for the common man, for the freedom of information–stop exposing our information to the world.  Maybe Anonymous isn’t specifically using our information, but they’re giving it to people who will.  And why?  Because they’re trying to expose a corporation or government’s incompetence?

 

My honest opinion is that the #Antisec groups that claim to be doing things for the people or freedom of information are either lying or extremely immature.  You can’t protect people by exposing their logins and credit card numbers.  You’re doing nothing but harm.

 

Here’s a suggestion.  If you truly want to do something, do something that won’t affect the innocent people who are using a service.  Contact the corporation or government privately, with proof of your deed, and if they don’t fix it, then go to the press.  But even when you go to the press, don’t release information about individual users.

 

If you continue to expose innocent, common users, you’re only doing it for fame or to say you can do it.  And any banner of truth or freedom that you’re trying to hide behind is a lie.  If that’s the case, how much better are you than the very governments and corporations you’re trying to expose?

 

Bottom line: hacking is bad.  I don’t support it.  I support freedom and believe in transparency.  If you must hack, then do so professionally and discretely.  If you truly want to follow through with the statements you make, expose and exploit the governments and corporations, not the innocent individuals who subscribe to a service.

Advertisements

Certification Future

2012 – The Year of Certifications.

This month alone, I plan on taking three certification exams. I’m waiting on a voucher to be e-mailed to me by the company, and if I get it in time, I’ll be taking my Network+ on Friday, January 13th.

I’ve scheduled my CCENT for Friday, January 20th.

I plan on taking my CCNA SP Ops (SSPO) on Friday, January 27th.

My JNCIS-ENT exam should be on Friday, February 10th.

Wish me luck!

Feature Lab Friday #3 – Securing Telnet Access

Feature Lab Friday #3 – Securing Telnet Access

This coincides with the previous JNCIA Question of the Week regarding how to secure access via telnet. Our objective here is to limit telnet access to a router to only a specific subnet. We want to allow telnet access only from the router’s loopback address. To test this, we will make use of advanced pinging techniques available in the Junos software.

First, we will assume that you have two routers configured in the following way:

  • R1 – em0.0 172.16.0.1/30
  • R1 – em1.0 192.168.1.1/24
  • R1 – lo0.0 10.1.1.1
  • R2 – em0.0 172.16.0.2/30
  • R2 – em1.0 192.168.2.1/24
  • R2 – lo0.0 10.2.2.2

We will assume that you have the em0.0 interfaces directly connected to each other. We will also assume that we have routes to all subnets, whether they are statically or dynamically configured.

First, log into R2 and issue the following command:
telnet source 192.168.2.1 10.1.1.1
It should succeed. Now issue this command:
telnet source 10.2.2.2 10.1.1.1
This should also succeed. Right now, we can telnet to this device from anywhere in the world. We’re going to apply a firewall filter that allows us to restrict telnet access to R1 to only the 10.2.2.2 address. Obviously this isn’t very practical in the real world since you would only be able to access R1 by first being in R2, but this will give you an idea as to how to configure for a more practical situation.

The following commands will restrict telnet access to R1. Only the 10.2.2.2 IP address will be able to access the router remotely.

[edit]
root# edit firewall filter restrict-telnet term accept-telnet

[edit firewall filter restrict-telnet term accept-telnet]
root# set from source-prefix-list trusted-subnets

[edit firewall filter restrict-telnet term accept-telnet]
root# set from protocol tcp

[edit firewall filter restrict-telnet term accept-telnet]
root# set from destination-port telnet

[edit firewall filter restrict-telnet term accept-telnet]
root# set then accept

[edit firewall filter restrict-telnet term accept-telnet]
root# up

[edit firewall filter restrict-telnet]
root# edit term reject-telnet

[edit firewall filter restrict-telnet term reject-telnet]
root# set from protocol tcp

[edit firewall filter restrict-telnet term reject-telnet]
root# set from destination-port telnet

[edit firewall filter restrict-telnet term reject-telnet]
root# set then discard

[edit firewall filter restrict-telnet term reject-telnet]
root# up

[edit firewall filter restrict-telnet]
root# set term accept-other-traffic then accept

[edit firewall filter restrict-telnet]
root# top

[edit]
root# set policy-options prefix-list trusted-subnets 10.2.2.2

Now, if we try to telnet from our 192.168.2.0/24 subnet, telnet will simply hang.

root> telnet source 192.168.2.1 10.1.1.1
Trying 10.1.1.1…
^C
root>

But if we telnet from the 10.2.2.2 address, we will get our login prompt:

root> telnet source 10.2.2.2 10.1.1.1
Trying 10.1.1.1…
Connected to 10.1.1.1.
Escape character is ‘^]’.

(ttyp0)

login:

JNCIA Question of the Week #4 – Securing Remote Access

JNCIA Question of the Week #4

After several weeks off due to heavy work load and vacation, we’re back with the JNCIA Question of the Week. And to start the week off, we’re going to be asking a more complicated question than has been customary.

Q:

This week, we want to allow telnet access only from a specific subnet.

Assume we have the following scenario:

  • Two routers directly connected through their em0 interfaces on the 172.16.0.0/30 subnet
  • R1’s lo0.0 address is 10.1.1.1
  • R2’s lo0.0 address is 10.2.2.2
  • R1 has the 192.168.1.0/24 network attached to its em1 interface
  • R2 has the 192.168.2.0/24 network attached to its em1 interface
  • We only want to allow telnet access to R1 from R2 from the 10.2.2.2/32 address.

What firewall filter(s) need to be created, to which device(s) and interface(s) must it/they be applied to and in which direction (ingress/egress), and how can we verify the firewall filter(s) work as intended?

This is a very open-ended question. Substitute IP addresses as you want. These were provided strictly as guidelines.

The answer to this week’s question will not be provided until Friday due to its complexity relative to previous questions. Also on Friday will be a Feature Lab Friday detailing how this can be accomplished and why we would want to accomplish such a thing.

[edit]

A:

Please refer to the post here for details on how to answer this question.
[/edit]

Content Resumes Soon! – On December 26

Hey everyone. There haven’t been updates in a while, I know. I’ve been in Little Rock meeting the managers behind our data NOC. This week, I’ve been in class all day, every day. Next week is vacation and Christmas.

I’ll be back on December 26, though, so updates will resume then.

No Lab Today

I’ve been getting ready for a business trip to Little Rock all day, so no lab today.

We’ll pick up next week. Happy networking!

JNCIA and Network Fundamentals

There is a very fundamental concept behind the Juniper JNCIA-Junos exams: they expect you to have an understanding of networks before you ever take the exam.

The exam itself expects you to understand concepts such as subnetting and other networking basics. If you are not familiar with subnetting, how it’s done, why it’s done, what it means, etc., please consider taking the CompTIA Network+ exam. The official materials for the JNCIA-Junos exam do not really go over the fundamentals of data networking. (please see the note at the end of this post)

If you need to study or brush up on your networking fundamentals, I can recommend Michael Meyers’ CompTIA Network+ Guide to Managing and Troubleshooting Networks, Second Edition. It is several years old now, but it is still an excellent book.

If you’re looking for something more up-to-date, or if you prefer videos to books, check out Professor Messer’s N10-004 CompTIA Network+ Training Course. They’re free, too!

I don’t think that anyone could stress enough how important the fundamentals are. Although subnetting seemed to be the only fundamental stressed on the JNCIA-Junos exam that wasn’t covered in the official materials, everything on the Network+ exam is important to a career as a network technician, analyst, or engineer.

[note]
When I say “official materials,” I am talking about the materials offered via FastTrack. I don’t have the funds to purchase the JNCIA-Junos handbooks or attend the JNCIA-Junos classes. While the FastTrack video does talk about several fundamental concepts, I feel that it does not touch on them enough.
[/note]