That's one expensive preview...

I will probably fail the next exam too because I may end up doing the exact same thing when configuring the service. The only thing I may do differently is using the iptables command instead of the GUI.

hi rhel5, dont be discouraged. redhat website says that 75% of retakers passed the exam. I don't mean to not use gui.. Gui is good, I used it alot during the exam as well. policycoreutils is amazing. what i mean is to try and understand what the gui is doing and be able to edit the backend files by hand if need be. for example in the iptables config, being able to fully understand the rule:

-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT

instead of simply configuring it in the gui and forget about it.

You said you used tcp_wrappers. I suggest you look more into it if you are using it because it has its limitations, ie you cant rely it to control all your policies.

The last tip I have is to re-read and recheck many times. I finished part B in about 1.5 hrs and spend the rest of time rechecking.. Your rhce mark tells me that something is seriously wrong in your answer.

good luck.

descarte has some good tips and I recommend the same. I also finished the RHCE Config portion in 1.5 hours and spent ALL the rest of the time going over the test.

I can't say much about the test (as you know we singed an NDA), but all I can say is that knowing you got such a low score on your test; _SOMETHING_ went wrong.

For example...this is something that happened to me at work:

I had to open ssh to only one VLAN for a project. I set it up...and ALL MY RULES where good...but it didn't work. Why? It wasn't my rules or how I set it up...

After 2 hours of troubleshooting I found out what happened...I miss typed the IP address.

Lesson I learned: ALWAYS check the easy stuff first...

-C

Hmm... that's a new command to me. Is that the same as the iptables command? I kind of know how to use the iptables command, because I studied it for a month prior to the exam. I was just hesitating to use the iptables command because I was new at it.

Where can I learn more about that firewall command?

I don't recall reading that in Jang's Book. He mentioned that the Firewall tool was capable but it is very limited in terms of customization like NAT and Masquerading.

BTW, Thanks everyone for the kind tips...

I am learning alot from this discussion.

descarte put an example that is in the /etc/sysconfig/iptables file; which drops the iptables command in front of it...

It REALLY reads like this...
But if you are asking this question...

Then you probably need to become more familiar with the iptables command. Before retaking the test...plus the odds are in your favor since 75% of people that take it the second time pass!


-C

For heaven's sake... don't feel depressed. (At least, not for long. "Three beers. Max. Then, no more until morning, and in any case, no shots or chasers.")

Take your exam-results and pore over them very carefully. (You're not "in school," so do not pore over them that way.) You went into the exam feeling confident of your knowledge, and yet, when presented by a set of challenges that were specifically crafted for your education by others who have gone before you, "you fell into the pit."

Okay... "ouch." Yeah, I know. But this is professional (self-)education, and therefore, that's why that pit is there. It was selected to be there, and artfully arranged squarely in (one of) your chosen path(s). And more to the point, that's why the so-called "pit" has a nice, cushy, padded floor. Exactly as its designers intended, you bounced, with nothing more to show for it than a slightly-bruised ego and a little more experience. The good news is, you had that "experience" under safe and controlled conditions. Airplanes did not fall from the sky. It is not three o'clock in the morning.

Take the exercises and reverse-engineer them. Determine where the weaknesses (that you did not, until now, realize even existed...) lie, and consider... "what were the skills (which I obviously at the moment still lack), that the authors of this exam (and their reviewers) considered to be so-essential that they included them in this test? What were the scenarios that I mis-read? Why was I so surprised that I stumbled, when I confidently expected not to?"

As I said, "no more three beers ... then get to work." As any engineer will tell you, you learn much more about things that did not go the way that you expected them to. You have, in fact, stumbled precisely into a lesson that a substantial number of test-designers and test-reviewers consider it to be very, very important that you learn. Get busy. Discover what the lessons are, and make it your professional business to learn them.

Airplanes did not fall from the sky, this time. It is not three o'clock in the morning, this time. I'll bet that the people who designed that test can't say that.

You would do well to restrain yourself from "simply asking other folks around the water-cooler 'what the right answers were.'" After all, that is not really the point. Next time (and there will be a next time...), you won't have the water-cooler, and maybe next-time the screw-up will be real. You need to be the one who comes away, not only with "the knowledge," but with the means to obtain it.

And as always: when you finish with the exam to your satisfaction, or even right now, please don't forget to send detailed feeback to the test designers. Yeah, I'm serious. Stuff your bruised ego into your professional pocket, of course, and then, if you find that you've got constructive, implementable suggestions, send them on to the right people through the proper channels. (Hint: not "here.") Instructional design is much harder than it looks.

guys, with that iptables discussion a new question comes in mind...


on the test, if they ask, for example... user brad must access sshd from secure.com (192.168.10.0/24) but users on hacker.com(192.168.20.0/24) cannot access.


and them i set this rule:

iptables -A RH-Firewall-1-INPUT -s 192.168.10.0/24 -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT



this will just allow users on secure.com domain, and block everything else.

But i did what they ask right? it's allowing secure.com and blocking hacker.com..

Is that right? or they might misinterpreted the answer. like testing access from another network.

If someone asked me to do this at work for example (which this scenario has come up at my job...) I would use tcp_wrappers...

/etc/hosts.allow
/etc/host.deny
-C

but first you would have to disable iptables or leave enabled and put this rule

iptables -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT

Correct...

At work I use iptables to open the port, then I use tpc_wrappers for access control...

I know I _can_ do access controls with iptables...but it's easier with tcp_wrappers...in fact this is what I would do (step by step)

1) Use the GUI tool (system-config-securitylevel) and put a check mark on "ssh" on the Firewall GUI
2) Use tcp_wrappers (look at my configuration in my previous post) for access control...


-C

if you open on ssh there will be no need to allow on hosts.allow once you don't have ALL:ALL on your hosts.deny.

But my question is if they test access from another network. other them they are asking on the question.

If you have an "ALL:ALL" entry in your hosts.deny file without having anything in your hosts.allow file then all access to ssh will be blocked...so you can even get more granular with...

hosts.allow
hosts.deny
I Don't know.

Who knows how they test it...

-C

Regarding juscelino's question, couldn't you also do a

sshd:ALL EXCEPT 192.168.10.0/255.255.255.0

or

sshd:ALL EXCEPT .secure.com

in /etc/hosts.deny


Also for iptables, can I use the command?

iptables -t filter -A input -s ! 192.168.10.0/24 -p tcp --dport 22 -j REJECT

The above command will reject all packets outside of the 192.168.10.0/255.255.255.0 subnet for SSH port

Yes that will work.

In the RHCE it's results that matter; so any method that gets the results will be ok.

Just remember that your time is limited on the test; So use the method that is quickest for you.

Although the iptables command is the "fastest"...it isn't for me (since I'm no iptables guru). So the "fastest" for me would be to use system-config-securitylevel and check on ssh, then add the appropriate entries in the /etc/hosts.allow /etc/hosts.deny...that's the "fastest" way for me personally...

But you're right...it's much better to use iptables

Your above command could even be shortened ever more!
If you don't supply the -t it asumes you want the "filter" option...so you can drop it and save a few characters...

-C

Does any of you guys who take it the exam remember if RHEL had some fix pack version. 5.1, 5.2 or 5.3?

Tks