On Thu, Apr 05, 2001 at 01:15:14AM -0400, Noah L. Meyerhans wrote:
OK, I've made some patched files available for potato i386. I was not
able to get ntpd to build on my sid system. The files are available at
I got ntpd compiled on sid. Only thing I had to do was including time.h
in some
Hello!
Did someone tried to put kernel and some startup staff on CD, and next set
BIOS to
boot from CD-ROM ? This should prevent intruder from changing kernel/bootscripts and
i.e.
checksum database. To prevent changes in CMOS, it is possible to put system disk with
SCSI ID 2, or as
"Jarosaw Tabor" [EMAIL PROTECTED] writes:
Did someone tried to put kernel and some startup staff on CD,
and next set BIOS to boot from CD-ROM ? This should prevent intruder
from changing kernel/bootscripts and i.e. checksum database.
Nowadays, the BIOS isn't really stored in ROM. Go
unsubscribe [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
I guess we should expect a whole lot of attempts to connect to the ports
used by NTP once the script kiddies figure this one out.
I probably average about 20 connect attempts to ports 53 and 111 every day.
jmb
Package: ntp
Vulnerability: remote root exploit
Debian-specific: no
Przemyslaw
On Thu, Apr 05, 2001 at 01:31:31PM -0500, Lindsey Simon wrote:
I've been wondering why I get so many probes on port 53, what's the popular exploit
on it?
Myriad bugs in bind.
--
Nathan Norman - Staff Engineer | A good plan today is better
Micromuse Ltd. | than a perfect plan
I'm sucha yutz, I meant 443.. I know about 53 all too well.. l10n made our sysadmin's
redhat box toast.
Nathan E Norman in message Re: [SECURITY] [DSA 045-1] ntp remote root exploit fixed
(Thu, 04/05 13:37):
On Thu, Apr 05, 2001 at 01:31:31PM -0500, Lindsey Simon wrote:
I've been wondering
Why look it up when it's more fun to ask questions on a mailing list?
/sarcasm
/smart_alec
more_to_the_point
Here's a useful URL I have bookmarked:
http://www.isi.edu/in-notes/iana/assignments/port-numbers
/fake_metatags
At 03:55 PM 4/5/2001 -0300, Peter Cordes wrote:
There's a file
On Thu, Apr 05, 2001 at 02:21:03PM -0500, Lindsey Simon wrote:
"Duh" .. hmm, nice. If I wanted to know what the service was I might
not have asked what was the EXPLOIT that prompts the script kiddiez to
try it. Further, really all I mean is if anyone has an example of an
exploit handy or a
Does anyone have a recommendation of ports that should be blocked (via
ipchains/netfilter/etc) to make a system more secure?
In light of the recent security holes, I did a netstat -an, then lsof -i for
all ports that were listening and/or UDP. I put a filter in the way of
everything that I
I'd say to block all the ports you don't need to be available to the world.
Just leave opened the essencial ports you need to provide services.
Try nmap to see your opened ports.
On Thu, Apr 05, 2001 at 12:57:24PM -0700, Brandon High wrote:
Does anyone have a recommendation of ports that
On Thu, Apr 05, 2001 at 01:37:33PM -0500, Nathan E Norman wrote:
Myriad bugs in bind.
Beaucoup. You meant to say "beaucoup bugs in bind." :-)
Thanks to the team for the prompt action, BTW.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact
It is most secure to block everything and only open the ports that are
absolutely necessary.
They can only attack what they can see
If you run a web server then open port 80 tcp, if you have SMTP inbound
email then open port 25 tcp, if you run your own DNS for your domain
then open port 53
Ciao,
Thu, Apr 05, 2001 at 09:38:46PM +0100, Steve Ball wrote:
It is most secure to block everything and only open the ports that are
absolutely necessary.
ok, this is clear. What's the way you ppl do that throught ipchains/iptables
? Is it better to use the ACCEPT policy and then DENY all
It's better to do it this way:
ipchains -P input DENY
ipchains -A input -s (source add./port) -d (dest. add./port) -j ACCEPT
. . . (acceptance rules)
ipchains -A input -j DENY -l (logs all stuff not ACCEPTed above).
I also put other DENY statements on top of the last logging DENY for things
On Friday 06 April 2001 00:09, Cherubini Enrico wrote:
Ciao,
Thu, Apr 05, 2001 at 09:38:46PM +0100, Steve Ball wrote:
It is most secure to block everything and only open the ports that are
absolutely necessary.
ok, this is clear. What's the way you ppl do that throught
We were alerted to some of these messages in the log files and found a page where some
CERT folks described discovering a root hack on their box and these messages in the log
files. None of their other symptoms seems present on my box, though I do have a decent
number of these NOQUEUE messages,
On Thu, Apr 05, 2001 at 01:40:54PM -0700, Eric N. Valor wrote:
I work from a default-deny stance. Usual things to then allow in would be
25 (smtp), 80 (http), 22 (ssh, although be careful here), 53-UDP (DNS, if
This strickes me as odd, warning to be careful with ssd in the same
sentence
On Thu, 05 Apr 2001 13:40:54 -0700
Eric N Valor [EMAIL PROTECTED] wrote:
53-UDP (DNS, if you have bind running)
DNS will talk TCP on port 53 if the record requested is particularly
large.
--
J C Lawrence [EMAIL PROTECTED]
-(*)
Nate Duehr wrote:
On Thu, Apr 05, 2001 at 09:38:46PM +0100, Steve Ball wrote:
If you run a web server then open port 80 tcp, if you have SMTP inbound
email then open port 25 tcp, if you run your own DNS for your domain
then open port 53 udp.
You're going to be upset the first time
On Wednesday 04 April 2001 22:24, Noah L. Meyerhans wrote:
It would appear that every supported Debian version is currently
vulnerable... Note that I've not tested this myself, but our version of
ntp is definitely supposed to be vulnerable.
noah
And unfortunately, 4.0.99k seems to be the
On Wed, Apr 04, 2001 at 11:14:31PM -0500, Bud Rogers wrote:
On Wednesday 04 April 2001 22:24, Noah L. Meyerhans wrote:
It would appear that every supported Debian version is currently
vulnerable... Note that I've not tested this myself, but our version of
ntp is definitely supposed to be
On Thu, Apr 05, 2001 at 12:26:42AM -0400, Noah L. Meyerhans wrote:
Yes. The fix has been made in the FreeBSD CVS repository. I'm going to
see about integrating it with our sources now. If I get a safe copy
built I'll make a signed .deb available. I'm not a member of the
official Debian
On Thu, Apr 05, 2001 at 01:15:14AM -0400, Noah L. Meyerhans wrote:
OK, I've made some patched files available for potato i386. I was not
able to get ntpd to build on my sid system. The files are available at
I got ntpd compiled on sid. Only thing I had to do was including time.h
in some files
Hello!
Did someone tried to put kernel and some startup staff on CD, and next
set BIOS to
boot from CD-ROM ? This should prevent intruder from changing
kernel/bootscripts and i.e.
checksum database. To prevent changes in CMOS, it is possible to put system
disk with
SCSI ID 2, or as
Jarosław Tabor [EMAIL PROTECTED] writes:
Did someone tried to put kernel and some startup staff on CD,
and next set BIOS to boot from CD-ROM ? This should prevent intruder
from changing kernel/bootscripts and i.e. checksum database.
Nowadays, the BIOS isn't really stored in ROM. Go
unsubscribe [EMAIL PROTECTED]
I guess we should expect a whole lot of attempts to connect to the ports
used by NTP once the script kiddies figure this one out.
I probably average about 20 connect attempts to ports 53 and 111 every day.
jmb
Package: ntp
Vulnerability: remote root exploit
Debian-specific: no
Przemyslaw
On Thu, Apr 05, 2001 at 12:12:17PM -0500, JonesMB wrote:
I guess we should expect a whole lot of attempts to connect to the ports
used by NTP once the script kiddies figure this one out.
I probably average about 20 connect attempts to ports 53 and 111 every day.
port 137 has also a good
I guess we should expect a whole lot of attempts to connect to the ports
used by NTP once the script kiddies figure this one out.
I probably average about 20 connect attempts to ports 53 and 111 every day.
port 137 has also a good average.
oh yeah, I forgot about that one, along with 27374.
I've been wondering why I get so many probes on port 53, what's the popular
exploit on it?
JonesMB in message Re: [SECURITY] [DSA 045-1] ntp remote root exploit fixed
(Thu, 04/05 12:40):
I guess we should expect a whole lot of attempts to connect to the ports
used by NTP once the script
On Thu, Apr 05, 2001 at 01:31:31PM -0500, Lindsey Simon wrote:
I've been wondering why I get so many probes on port 53, what's the popular
exploit on it?
Myriad bugs in bind.
--
Nathan Norman - Staff Engineer | A good plan today is better
Micromuse Ltd. | than a perfect plan
On Thu, Apr 05, 2001 at 01:31:31PM -0500, Lindsey Simon wrote:
I've been wondering why I get so many probes on port 53, what's the
popular exploit on it?
Bind (DNS) listens on that port. Even if there weren't any current
exploits for bind, there are enough historical ones that people will
I'm sucha yutz, I meant 443.. I know about 53 all too well.. l10n made our
sysadmin's
redhat box toast.
Nathan E Norman in message Re: [SECURITY] [DSA 045-1] ntp remote root exploit
fixed (Thu, 04/05 13:37):
On Thu, Apr 05, 2001 at 01:31:31PM -0500, Lindsey Simon wrote:
I've been wondering
53 is DNS. I get a lot of probes because I don't allow TCP connections
(it's a UDP protocol, although TCP is used for zone xfers which I don't
allow). Unless the same IP is hitting your port 53 repeatedly, it's
probably nothing to worry about.
To keep from being vulnerable to nasties such
There's a file called /etc/services that has the answers to all these silly
questions. Try looking this stuff up, people.
llama:~$ grep 443 /etc/services
https 443/tcp # MCom
https 443/udp # MCom
Duh.
--
#define X(x,y)
Why look it up when it's more fun to ask questions on a mailing list?
/sarcasm
/smart_alec
more_to_the_point
Here's a useful URL I have bookmarked:
http://www.isi.edu/in-notes/iana/assignments/port-numbers
/fake_metatags
At 03:55 PM 4/5/2001 -0300, Peter Cordes wrote:
There's a file
On Thu, Apr 05, 2001 at 12:12:07PM -0700, Eric N. Valor wrote:
Here's a useful URL I have bookmarked:
http://www.isi.edu/in-notes/iana/assignments/port-numbers
/usr/share/nmap/nmap-services lists unofficial port numbers that are in
use.
yeti:~$ grep 2064 /usr/share/nmap/nmap-services
Duh .. hmm, nice. If I wanted to know what the service was I might not have
asked what was
the EXPLOIT that prompts the script kiddiez to try it. Further, really all I
mean is if anyone
has an example of an exploit handy or a url about one specifically, that'd be
neat. Sorry
if I offended
Peter Cordes wrote:
yeti:~$ grep 2064 /usr/share/nmap/nmap-services
distrib-net-losers 2064/tcp # A group of lamers working on a silly
closed-source client for solving the RSA cryptographic challenge. This is
the keyblock proxy port.
It used to be s/losers/assholes/ and s/silly/stupid/,
On Thu, Apr 05, 2001 at 02:21:03PM -0500, Lindsey Simon wrote:
Duh .. hmm, nice. If I wanted to know what the service was I might
not have asked what was the EXPLOIT that prompts the script kiddiez to
try it. Further, really all I mean is if anyone has an example of an
exploit handy or a
Does anyone have a recommendation of ports that should be blocked (via
ipchains/netfilter/etc) to make a system more secure?
In light of the recent security holes, I did a netstat -an, then lsof -i for
all ports that were listening and/or UDP. I put a filter in the way of
everything that I didn't
the silly question was not what service runs on a port. we all know that
information is readily available in /etc/services. the question was about
the bug in the service that made it vulnerable to an exploit.
jmb
There's a file called /etc/services that has the answers to all these silly
I like to look at it the other way around. What ports not to block?. I
block ALL ports except for the ones that *I* want to get through. This
increases the security of your firewall, because you have only allowed the
ports that YOU want open.
...adam
On Thu, Apr 05, 2001 at 12:57:24PM
Check out this page for some suggestions too,
-l
http://uw7doc.sco.com/NET_tcpip/filterD.block.html#filterT.block
Pedro Zorzenon Neto in message Re: Ports to block? (Thu, 04/05 17:04):
I'd say to block all the ports you don't need to be available to the world.
Just leave opened the
The first thing I do, right off, is block all ports 1024 coming in, then get a
list of what's running, and block everything else except those services I want
to
pass through...
Brandon High wrote:
Does anyone have a recommendation of ports that should be blocked (via
ipchains/netfilter/etc)
I work from a default-deny stance. Usual things to then allow in would be
25 (smtp), 80 (http), 22 (ssh, although be careful here), 53-UDP (DNS, if
you have bind running), and various ICMP (echo-reply/request,
source-quench, destination-unreachable, time-exceeded, and
parameter-problem are
On Thu, Apr 05, 2001 at 01:37:33PM -0500, Nathan E Norman wrote:
Myriad bugs in bind.
Beaucoup. You meant to say beaucoup bugs in bind. :-)
Thanks to the team for the prompt action, BTW.
It is most secure to block everything and only open the ports that are
absolutely necessary.
They can only attack what they can see
If you run a web server then open port 80 tcp, if you have SMTP inbound
email then open port 25 tcp, if you run your own DNS for your domain
then open port 53
You don't need to block any ports if you turn off unneeded services in
the first place. (You may only need sshd.) Put appropriate access
controls on the services you do provide. _Then_ consider packet
filtering. Packet filtering is only needed if your machine is a
firewall or if you want
Ciao,
Thu, Apr 05, 2001 at 09:38:46PM +0100, Steve Ball wrote:
It is most secure to block everything and only open the ports that are
absolutely necessary.
ok, this is clear. What's the way you ppl do that throught ipchains/iptables
? Is it better to use the ACCEPT policy and then DENY all or
It's better to do it this way:
ipchains -P input DENY
ipchains -A input -s (source add./port) -d (dest. add./port) -j ACCEPT
. . . (acceptance rules)
ipchains -A input -j DENY -l (logs all stuff not ACCEPTed above).
I also put other DENY statements on top of the last logging DENY for things
On Friday 06 April 2001 00:09, Cherubini Enrico wrote:
Ciao,
Thu, Apr 05, 2001 at 09:38:46PM +0100, Steve Ball wrote:
It is most secure to block everything and only open the ports that are
absolutely necessary.
ok, this is clear. What's the way you ppl do that throught
ipchains/iptables
We were alerted to some of these messages in the log files and found a page
where some
CERT folks described discovering a root hack on their box and these messages in
the log
files. None of their other symptoms seems present on my box, though I do have a
decent
number of these NOQUEUE messages,
On Thu, Apr 05, 2001 at 09:38:46PM +0100, Steve Ball wrote:
If you run a web server then open port 80 tcp, if you have SMTP inbound
email then open port 25 tcp, if you run your own DNS for your domain
then open port 53 udp.
You're going to be upset the first time you hit a site that has
On Thu, Apr 05, 2001 at 01:40:54PM -0700, Eric N. Valor wrote:
I work from a default-deny stance. Usual things to then allow in would be
25 (smtp), 80 (http), 22 (ssh, although be careful here), 53-UDP (DNS, if
This strickes me as odd, warning to be careful with ssd in the same
sentence
On Thu, 05 Apr 2001 13:40:54 -0700
Eric N Valor [EMAIL PROTECTED] wrote:
53-UDP (DNS, if you have bind running)
DNS will talk TCP on port 53 if the record requested is particularly
large.
--
J C Lawrence [EMAIL PROTECTED]
-(*)
Nate Duehr wrote:
On Thu, Apr 05, 2001 at 09:38:46PM +0100, Steve Ball wrote:
If you run a web server then open port 80 tcp, if you have SMTP inbound
email then open port 25 tcp, if you run your own DNS for your domain
then open port 53 udp.
You're going to be upset the first time you
58 matches
Mail list logo
