i was playing w/ a kernel driver when i noticed the following:
(machine 1)
-rw-r-1 root adm 0 Mar 25 06:49 /var/log/kern.log
-rw-r-1 root adm 2259 Mar 20 17:59 /var/log/kern.log.0
(machine 2)
-rw-r-1 root adm 0 Mar 25 06:49 /va
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
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]
-(*)
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, 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 en
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
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]
-(*)
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
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 e
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
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
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 o
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 to
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 ud
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.
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 g
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, so
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)
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
> ipchain
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 essenci
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 should
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
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 -0
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
>qu
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
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
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
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/stup
"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 anyo
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
d
Why look it up when it's more fun to ask questions on a mailing list?
Here's a useful URL I have bookmarked:
http://www.isi.edu/in-notes/iana/assignments/port-numbers
At 03:55 PM 4/5/2001 -0300, Peter Cordes wrote:
There's a file called /etc/services that has the answers to all these
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) x##
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 suc
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 wonderin
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
al
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'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
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 t
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 ud
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 [EM
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 g
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 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
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 essenc
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 shoul
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 -0
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
>q
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
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 a
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 F
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 o
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/stu
"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 any
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
Why look it up when it's more fun to ask questions on a mailing list?
Here's a useful URL I have bookmarked:
http://www.isi.edu/in-notes/iana/assignments/port-numbers
At 03:55 PM 4/5/2001 -0300, Peter Cordes wrote:
>
> There's a file called /etc/services that has the answers to all the
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) x#
unsubscribe [EMAIL PROTECTED]
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
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 wonderin
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
a
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
"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.
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 scrip
>>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
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.
jmb
>Package: ntp
>Vulnerability: remote root exploit
>Debian-specific: no
>
>Przemyslaw
unsubscribe [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
"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.
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 s
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 s
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
in some files that
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
in some files tha
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
74 matches
Mail list logo
