In following up on the rsh "problem" I was having earlier, I decided to try out the suggestion Felipe sent about using system-config-securitylevel-tui to open up ports 513 and 514, but that doesn't seem to do the job, either.
# iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination RH-Firewall-1-INPUT all -- anywhere anywhere
Chain FORWARD (policy ACCEPT) target prot opt source destination RH-Firewall-1-INPUT all -- anywhere anywhere
Chain OUTPUT (policy ACCEPT) target prot opt source destination
Chain RH-Firewall-1-INPUT (2 references) target prot opt source destination ACCEPT all -- anywhere anywhere ACCEPT icmp -- anywhere anywhere icmp any ACCEPT esp -- anywhere anywhere ACCEPT ah -- anywhere anywhere ACCEPT udp -- anywhere 224.0.0.251 udp dpt:mdns ACCEPT udp -- anywhere anywhere udp dpt:ipp ACCEPT tcp -- anywhere anywhere tcp dpt:ipp ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:login ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:shell ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:telnet REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
Shouldn't this work given the login and shell lines above? Or do they need to come before the ESTABLISHED line, too?
Thanks.
mhr
Quoting MHR mhullrich@gmail.com:
In following up on the rsh "problem" I was having earlier, I decided to try out the suggestion Felipe sent about using system-config-securitylevel-tui to open up ports 513 and 514, but that doesn't seem to do the job, either.
I could be remembering this wrong, but I believe these are udp, not tcp.
Barry
On Thu, Jul 10, 2008 at 3:17 PM, Barry Brimer lists@brimer.org wrote:
Quoting MHR mhullrich@gmail.com:
In following up on the rsh "problem" I was having earlier, I decided to try out the suggestion Felipe sent about using system-config-securitylevel-tui to open up ports 513 and 514, but that doesn't seem to do the job, either.
I could be remembering this wrong, but I believe these are udp, not tcp.
Barry
According to http://www.spirit.com/Resources/ports.html, the udp services on those ports are who and syslog....
Thanks.
mhr
On Thu, 2008-07-10 at 15:40 -0700, MHR wrote:
On Thu, Jul 10, 2008 at 3:17 PM, Barry Brimer lists@brimer.org wrote:
Quoting MHR mhullrich@gmail.com:
<snip>
system-config-securitylevel-tui to open up ports 513 and 514, but that doesn't seem to do the job, either.
I could be remembering this wrong, but I believe these are udp, not tcp.
Barry
According to http://www.spirit.com/Resources/ports.html, the udp services on those ports are who and syslog....
From the authoritative /etc/services
:g/51[34]/p login 513/tcp who 513/udp whod shell 514/tcp cmd # no passwords used syslog 514/udp
Just thought you should know that you have this and /etc/protocols locally so you don't have to trust some unknown website.
And it's faster to lookup locally, of course.
Thanks.
mhr
<snip sig stuff>
On Thu, Jul 10, 2008 at 6:08 PM, MHR mhullrich@gmail.com wrote:
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:login ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:shell
It seems right to me...
Try using "iptables -vL", it will show you how many packets have matched that rule. Then try to rsh or rlogin and see if the numbers change. That should give you a clue to whether it's working or not.
HTH, Filipe
P.S.: Once again: although it's great that you are digging into the problem, using iptables, and learning a lot on the process, you should *REALLY* consider ditching rsh/rlogin and sticking to SSH. I would consider using rsh/rlogin instead of SSH today about the same as using gopher instead of the WWW these days (for those of you who still remember it).
P.S.: Once again: although it's great that you are digging into the problem, using iptables, and learning a lot on the process, you should *REALLY* consider ditching rsh/rlogin and sticking to SSH. I would consider using rsh/rlogin instead of SSH today about the same as using gopher instead of the WWW these days (for those of you who still remember it).
what are you talking about? I'm writing a Tor wrapper that funnels all my http requests thru gopher for extra security. It's called Gor. And I'm writing it in GW-BASIC!
we don't need no steenkin new fangled tecnomologies.
next you'll be telling me our internets shouldn't use tubes.
On Thu, Jul 10, 2008 at 6:43 PM, Spiro Harvey, Knossos Networks Ltd spiro@knossos.net.nz wrote:
next you'll be telling me our internets shouldn't use tubes.
You're up to tubes? Hippy freak!
mhr
On Fri, 2008-07-11 at 13:43 +1200, Spiro Harvey, Knossos Networks Ltd wrote:
<snip>
what are you talking about? I'm writing a Tor wrapper that funnels all my http requests thru gopher for extra security. It's called Gor. And I'm writing it in GW-BASIC!
we don't need no steenkin new fangled tecnomologies.
next you'll be telling me our internets shouldn't use tubes.
That's right! Since most of you youngsters can't swim worth a crap, your intertubes should use nets!
On Thu, Jul 10, 2008 at 6:29 PM, Filipe Brandenburger filbranden@gmail.com wrote:
Try using "iptables -vL", it will show you how many packets have matched that rule. Then try to rsh or rlogin and see if the numbers change. That should give you a clue to whether it's working or not.
Before:
6 360 ACCEPT tcp -- any any anywhere anywhere state NEW tcp dpt:login 0 0 ACCEPT tcp -- any any anywhere anywhere state NEW tcp dpt:shell 619 22772 REJECT all -- any any anywhere anywhere reject-with icmp-host-prohibited
[summarized to include only the relevant ports]
After:
6 360 ACCEPT tcp -- any any anywhere anywhere state NEW tcp dpt:login 6 360 ACCEPT tcp -- any any anywhere anywhere state NEW tcp dpt:shell 619 22772 REJECT all -- any any anywhere anywhere reject-with icmp-host-prohibited
Interesting that the shell count went up to 6 and the reject count did not change, but no login occurred:
[mrichter@khan mrichter]$ rsh sushi ls sushi: Connection refused
I might not have waited long enough for the reject count to go up - just repeated the experiment and got this:
[before] 6 360 ACCEPT tcp -- any any anywhere anywhere state NEW tcp dpt:login 6 360 ACCEPT tcp -- any any anywhere anywhere state NEW tcp dpt:shell 627 23044 REJECT all -- any any anywhere anywhere reject-with icmp-host-prohibited
[after] 6 360 ACCEPT tcp -- any any anywhere anywhere state NEW tcp dpt:login 12 720 ACCEPT tcp -- any any anywhere anywhere state NEW tcp dpt:shell 628 23072 REJECT all -- any any anywhere anywhere reject-with icmp-host-prohibited
But why is it still rejecting the login, or is it the placement of the lines?
P.S.: Once again: although it's great that you are digging into the problem, using iptables, and learning a lot on the process, you should *REALLY* consider ditching rsh/rlogin and sticking to SSH. I would consider using rsh/rlogin instead of SSH today about the same as using gopher instead of the WWW these days (for those of you who still remember it).
Did that - this is just for my better understanding of the whole setup.
On Thu, Jul 10, 2008 at 9:53 PM, MHR mhullrich@gmail.com wrote:
[mrichter@khan mrichter]$ rsh sushi ls sushi: Connection refused
Are you sure the daemons are up and listening on those ports? What does "netstat -ltp" says on sushi?
Filipe
On Thu, 2008-07-10 at 21:29 -0400, Filipe Brandenburger wrote:
<snip>
P.S.: Once again: although it's great that you are digging into the problem, using iptables, and learning a lot on the process, you should *REALLY* consider ditching rsh/rlogin and sticking to SSH. I would consider using rsh/rlogin instead of SSH today about the same as using gopher instead of the WWW these days (for those of you who still remember it).
Of course! And it has a new career too! NASCAR on Fox has an "in track" camera system that uses gopher as its character. They have named it "Digger".
<snip sig stuff>
Filipe Brandenburger schrieb:
P.S.: Once again: although it's great that you are digging into the problem, using iptables, and learning a lot on the process, you should *REALLY* consider ditching rsh/rlogin and sticking to SSH. I would consider using rsh/rlogin instead of SSH today about the same as using gopher instead of the WWW these days (for those of you who still remember it).
In an isolated subnet (where the only users are root anyway on all machines - think research lab), it might have its uses (e.g. when ssh via key-authentication is too slow for whatever is needed).
So, I wouldn't ditch it completely. But on a normal LAN, it's not a good idea.
Rainer
On Thursday 10 July 2008 18:08, MHR wrote:
In following up on the rsh "problem" I was having earlier, I decided to try out the suggestion Felipe sent about using system-config-securitylevel-tui to open up ports 513 and 514, but that doesn't seem to do the job, either.
# iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination RH-Firewall-1-INPUT all -- anywhere anywhere
[snip]
I hate reading the firewall like this. Could you post /etc/sysconfig/iptables?
On Thu, Jul 10, 2008 at 10:42 PM, Robert Spangler mlists@zoominternet.net wrote:
Could you post /etc/sysconfig/iptables?
/etc/sysconfig/iptables doesn't necessarily reflect what is running right now, and you can't include the counters with it.
An acceptable compromise would be posting the output of the "iptables-save -c" command, which doesn't have the two issues above.
However, I still think that anyone handling firewalls on Linux using iptables should be familiar with the output of "iptables -nvL" which IMO is quite useful itself.
Filipe
On Thursday 10 July 2008 22:49, Filipe Brandenburger wrote:
Could you post /etc/sysconfig/iptables?
/etc/sysconfig/iptables doesn't necessarily reflect what is running right now, and you can't include the counters with it.
I'm not interested in the counters I want to see how the rules are applied. Are you telling me that the GUI tool he is using to write the rules doesn't write them to the iptables file when he exits the program?
An acceptable compromise would be posting the output of the "iptables-save -c" command, which doesn't have the two issues above.
However, I still think that anyone handling firewalls on Linux using iptables should be familiar with the output of "iptables -nvL" which IMO is quite useful itself.
I handle firewall rules quit nice thank you.
Since you are in the mood to tell me I should know how to read this output please tell me what this means:
[snip] Chain RH-Firewall-1-INPUT (2 references) target prot opt source destination ACCEPT all -- anywhere anywhere [/snip]
What are we accepting here? All packets? If this is the case then there is no need for the rest of the rules in this chain.
Oh, by the way I prefer to use
iptables -L -v -n | less -SCi
I also prefer not to write any rules in the FORWARDing chain except the rules that JUMP to predefined chains LAN or WAN. Make it easier to read the rules and know what applies to what interface at a glance also making it easier to add rules or remove them in the order you want.
Again this is all personal preference.
Could you post /etc/sysconfig/iptables?
/etc/sysconfig/iptables doesn't necessarily reflect what is running right now, and you can't include the counters with it.
I'm not interested in the counters I want to see how the rules are
I think he's trying to tell you that any changes made since the *last* write to /etc/sysconfig/iptables won't be reflected in that file. Or rather, what if that file has been written to, but not read from? The fact remains that "iptables -L" is more useful because it is a live state.
In fact, I've got a few machines where all my rules are only kept in running memory. They're all activated/reactivated/modified using scripts. No state is stored on disk.
[snip] Chain RH-Firewall-1-INPUT (2 references) target prot opt source destination ACCEPT all -- anywhere anywhere [/snip] What are we accepting here? All packets? If this is the case then there is no need for the rest of the rules in this chain.
depends on the INPUT rule that references this. but yes, once a packet has been filtered to get here, then it will be accepted.
see? you can read this output.
-
Barry Brimer -
Filipe Brandenburger -
MHR -
Rainer Duffner -
Robert Spangler -
Spiro Harvey, Knossos Networks Ltd -
William L. Maltby