[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [cobalt-users] RE: NTP Servers Again
- Subject: Re: [cobalt-users] RE: NTP Servers Again
- From: "E.B. Dreger" <eddy+public+spam@xxxxxxxxxxxxxxxxx>
- Date: Sat Jul 6 19:19:00 2002
- List-id: Mailing list for users to share thoughts on Sun Cobalt products. <cobalt-users.list.cobalt.com>
c> Date: Sun, 07 Jul 2002 13:21:41 +1200
c> From: chae
c> Portsentry:
c> TCP_PORTS="1,11,15,143,540,635,1080,1524,2000,5742,6667,..."
c> UDP_PORTS="1,513,635,640,641,700,32770,32771,32772,..."
No conflicts here.
c> IPChains:
c>
c> /sbin/ipchains -F
c> /sbin/ipchains -X
c>
c> /sbin/ipchains -P input DENY
c> /sbin/ipchains -P forward DENY
c> /sbin/ipchains -P output REJECT
Note the policies set for input and output are DENY and REJECT,
respectively. DENY silently drops a packet without proper error
in return; this often is good for inbound. REJECT will return a
proper error -- the "permission denied" that you received.
c> /sbin/ipchains -A input -i lo -j ACCEPT
c> /sbin/ipchains -A input -s 10.0.0.0/255.0.0.0 -j DENY
c> /sbin/ipchains -A input -s 172.16.0.0/255.240.0.0 -j DENY
c> /sbin/ipchains -A input -s 192.168.0.0/255.255.0.0 -j DENY
c> /sbin/ipchains -A input -s 255.255.255.255/255.255.255.255 -j DENY
c> /sbin/ipchains -A input -d 0.0.0.0/255.255.255.255 -j DENY
c> /sbin/ipchains -A input -s 224.0.0.0/240.0.0.0 -j DENY
c> /sbin/ipchains -A input -s 240.0.0.0/248.0.0.0 -j DENY
c> /sbin/ipchains -A input -s 0.0.0.0/255.0.0.0 -j DENY
c> /sbin/ipchains -A input -s 127.0.0.0/255.0.0.0 -j DENY
c> /sbin/ipchains -A input -s 169.254.0.0/255.255.0.0 -j DENY
c> /sbin/ipchains -A input -s 192.0.2.0/255.255.255.0 -j DENY
c> /sbin/ipchains -A input -s 224.0.0.0/224.0.0.0 -j DENY
So far so good.
At this point, let's add a few things for diagnostics. Note
that, to combat line wrap, I use "\" to indicate continuation of
a line.
/sbin/ipchains -A input -s 0.0.0.0/0.0.0.0 XXX \
-d 0.0.0.0/0.0.0.0 XXX \
-i eth0 -p udp -j ACCEPT
/sbin/ipchains -A input -s 0.0.0.0/0.0.0.0 1024:65535 \
-d 0.0.0.0/0.0.0.0 XXX \
-i eth0 -p udp -j ACCEPT
/sbin/ipchains -A input -s 0.0.0.0/0.0.0.0 XXX \
-d 0.0.0.0/0.0.0.0 1024:65535 \
-i eth0 -p udp -j ACCEPT
/sbin/ipchains -A output -s 0.0.0.0/0.0.0.0 XXX \
-d 0.0.0.0/0.0.0.0 XXX \
-i eth0 -p udp -j ACCEPT
/sbin/ipchains -A output -s 0.0.0.0/0.0.0.0 XXX \
-d 0.0.0.0/0.0.0.0 1024:65535 \
-i eth0 -p udp -j ACCEPT
/sbin/ipchains -A output -s 0.0.0.0/0.0.0.0 1024:65535 \
-d 0.0.0.0/0.0.0.0 XXX \
-i eth0 -p udp -j ACCEPT
DO NOT enter this verbatim. Replace XXX with 123 for ntpdate or
with 37 for rdate.
Note also that I'm less than fond of ipchains... the rules that I
gave are in the same style as the rest that you posted, but
really are only enough to "keep the good guys out". Stateful
rules are better, but I won't go there. (You can't do that with
ipchains.)
[ ...farther down the ruleset... ]
c> /sbin/ipchains -A input -d 0.0.0.0/0.0.0.0 37 \
c> -i eth0 -p tcp -j DENY
c>
c> /sbin/ipchains -A input -d 0.0.0.0/0.0.0.0 37 \
c> -i eth0 -p udp -j DENY
This will prevent rdate from working. However, the rules that I
gave above should be processed first; leave this in for now.
c> Now I notice that port 37 is being denied but 123 isn't being
c> denied.
That blocks rdate. Unless I skipped some broad ALLOW rule, 123
is being blocked implicitly at the end.
c> There is also a rule for NNTP servers above, are these
c> the same as NTP servers if so then it's blocking port 119 and
c> not 123.
No. NNTP is Usenet news.
c> Or if port 37 is being blocked will this stop the Cobalt
c> NTPDate from working or in that case rdate??
Port 37 blocking will thwart rdate.
Eddy
--
Brotsman & Dreger, Inc. - EverQuick Internet Division
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 (785) 865-5885 Lawrence and [inter]national
Phone: +1 (316) 794-8922 Wichita
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Date: Mon, 21 May 2001 11:23:58 +0000 (GMT)
From: A Trap <blacklist@xxxxxxxxx>
To: blacklist@xxxxxxxxx
Subject: Please ignore this portion of my mail signature.
These last few lines are a trap for address-harvesting spambots.
Do NOT send mail to <blacklist@xxxxxxxxx>, or you are likely to
be blocked.