Re: NULL Scan issues or something else?

Hi Mr Edwin Yes, I have this rule and is responsible for the established/related connections. This rule is almost at the very end of the INPUT chain. *>> (...) before the rule that logs/drops your packets?* Do you mean those strange packages mentioned in the first mail, right? Frankly, not; This

Re: NULL Scan issues or something else?

On 02/08/2013 11:16 PM, Daniel Curtis wrote: > Hi Mr Erwan > > Let's summarize: these logs are normal and are not > something... /bad/. Even if there are many IP's connections > (/INVALID/) probes. > I understand, that I should have not contact with the servers. > Okay, but if those servers are pr

Re: NULL Scan issues or something else?

Hi Mr Erwan Let's summarize: these logs are normal and are not something... *bad*. Even if there are many IP's connections (*INVALID*) probes. I understand, that I should have not contact with the servers. Okay, but if those servers are providing e.g. a website, which I visit? How to avoid them? I

Re: NULL Scan issues or something else?

On Fri, Feb 08, 2013 at 02:06:48PM CET, Daniel Curtis said: > Hi Mr Erwan > > So, everything is okay? Even these strange logs > mentioned earlier? I'm still curious about this rule; > SYN,RST, ACK,FIN, PSH,URG, SYN,RST,ACK, > FIN,PSH,URG > > What do you mean by writing, that I should not contac

Re: NULL Scan issues or something else?

Hi Mr Erwan So, everything is okay? Even these strange logs mentioned earlier? I'm still curious about this rule; *SYN,RST, ACK,FIN, PSH,URG, SYN,RST,ACK, FIN,PSH,URG* What do you mean by writing, that I should not contact servers? Best regards!

Re: NULL Scan issues or something else?

Le 07/02/2013 21:22, Daniel Curtis a écrit : Hi, >>//(...)/Nothing that should bother you. / Okay, so far so good. But what about the rest of IP addresses, which occurred in logs? You have mentioned about a /bendel.debian.org / website. I wonder why? Because that's the

Re: NULL Scan issues or something else?

connections is sufficient? In that case, what is the type of scan, that uses these flags; SYN,RST,ACK,FIN,PSH,URG SYN,RST,ACK, FIN,PSH,URG? Why this type of scan occurs when all ports are closedand none of the services are not running? Sorry for the naive question, but I'm surprised, because

RE: NULL Scan issues or something else?

Hello Daniel, As far as I understand well, an INVALID state is applied on packet that shouldn't exist according to the conntrack engine. Null scan packets should look like --tcp-flags ALL NONE. Your rule will match with packets that are invalid AND that are not full flag, which seem

Re: NULL Scan issues or something else?

That with openvpn ;-) Jay On Feb 5, 2013, at 19:33, Kees de Jong wrote: > That, or just use OpenVPN.

Re: NULL Scan issues or something else?

On Tue, Feb 05, 2013 at 10:45:39PM +, Jérémie Marguerie wrote: >You'll be scanned, many times a day, you'll also be bruteforced and >however not normal, this is just "noise". See also http://en.wikipedia.org/wiki/Internet_background_radiation signature.asc Description: Digital signa

Re: NULL Scan issues or something else?

That, or just use OpenVPN.

Re: NULL Scan issues or something else?

If you want to be extra paranoid, hide your open ports with port knocking and have your clients run from a script that knocks the proper sequence before making the connection :-) Jay On Feb 5, 2013, at 19:10, Jérémie Marguerie wrote: > Le 5 févr. 2013 23:03, "Bartek Krajnik" a écrit : > > >

Re: NULL Scan issues or something else?

On Tue, 2013-02-05 at 23:10 +, Jérémie Marguerie wrote: > Le 5 févr. 2013 23:03, "Bartek Krajnik" a écrit : > > > > Hi, > > For ssh login attempts you can use program authfail (after 4 wrong > login attempts it adds proper IP to netfilter with DROP rule sending > notification to IP class owner

Re: NULL Scan issues or something else?

>: >> I've added a rule to my iptables script, which is responsible for >> filtering --tcp-flags and INVALID state. After addition of this rule, >> I've noticed , that many IP addresses are trying to scan(?) my >> computer, but it is not so obvious, becaus

Re: NULL Scan issues or something else?

Le 5 févr. 2013 23:03, "Bartek Krajnik" a écrit : > > Hi, > For ssh login attempts you can use program authfail (after 4 wrong login attempts it adds proper IP to netfilter with DROP rule sending notification to IP class owner from whois database). It sounds a bit overkill. Am I the only one some

Re: NULL Scan issues or something else?

Le 5 févr. 2013 17:52, "Daniel Curtis" a écrit : > I've added a rule to my iptables script, which is responsible for > filtering --tcp-flags and INVALID state. After addition of this rule, > I've noticed , that many IP addresses are trying to scan(?) my > co

Re: NULL Scan issues or something else?

51, Daniel Curtis wrote: > Hi > > I've added a rule to my iptables script, which is responsible for > filtering /--tcp-flags/ and /INVALID/ state. After addition of this rule, > I've noticed , that many IP addresses are trying to scan(?) my > computer, but it is not so o

Re: Are these scan logs dangerous ?

a dehqan wrote: In The Name Of God Thanks alot for your attentions ; Yes ,service is inetd .How can port 113 be closed ? You can example close all services with command update-inetd and when all services were disabled restart openbsd-inetd. Service isn't start if all services are diasbled. R

Re: Are these scan logs dangerous ?

In The Name Of God Thanks alot for your attentions ; Yes ,service is inetd .How can port 113 be closed ? #netstat -lnop|grep ":113" > tcp0 0 0.0.0.0:113 0.0.0.0:* > LISTEN 3550/inetd off (0.00/0/0) > lsof -i :113 > COMMAND PID USER FD TYPE DEVICE SIZE NO

Re: Are these scan logs dangerous ?

On Sun, 5 Jul 2009 23:56:36 +0430 a dehqan wrote: > In The Name Of God > > Thanks alot for your attentions ; > Yes , after rkhunter --propupd ,unhide has been ok . > > But about ident service ,see > > > # chkconfig --level 23 identd off > > identd: unknown service > > > > But port 113 auth is

Re: Are these scan logs dangerous ?

On Jul 5, 2009, at 3:26 PM, a dehqan wrote: ... But about ident service ,see > # chkconfig --level 23 identd off identd: unknown service But port 113 auth is open ! So which service has opened port 113 ? Remember your initial warning messages from rhunter: >>> [11:19:59] Checking for e

Re: Are these scan logs dangerous ?

a dehqan wrote: please quote :-) # chkconfig --level 23 identd off identd: unknown service probably you have mistaken inetd with identd But port 113 auth is open ! So which service has opened port 113 ? from root # netstat -putan to see all the service listening to see only 113 port: #

Re: Are these scan logs dangerous ?

In The Name Of God Thanks alot for your attentions ; Yes , after rkhunter --propupd ,unhide has been ok . But about ident service ,see > # chkconfig --level 23 identd off > identd: unknown service > But port 113 auth is open ! So which service has opened port 113 ? On Sun, Jul 5, 2009 at 10:3

Re: Are these scan logs dangerous ?

a dehqan wrote: [11:19:43] Warning: The file '/usr/sbin/unhide-linux26' exists on the system, but it is not present in the rkhunter.dat file. $ apt-file search /usr/sbin/unhide-linux26 unhide: /usr/sbin/unhide-linux26 probably you have installed unhide as suggested by rkhunter and you have i

Are these scan logs dangerous ?

In The Name Of God I'll be thankfull if you guide ; This is rkhunter result > http://pastebin.com/f6558ccd3 There is two warnings in The log ,is system Infected ? What are these warnings for ? [11:19:43] /usr/sbin/unhide-linux26 [ Warning ] > [11:19:43] Warning: The fil

Re: PCI vulnerability scan - PHP4 on Sarge

software are not backported. Whomever is doing your scan needs to provide which CVEs that are the problem and then you can show they have false positives by looking at the CVEs that have been fixed in the version you are running. You need to show them that you have policies in place to do routine

Re: PCI vulnerability scan - PHP4 on Sarge

William Chipman wrote: > We had a scan of our systems for PCI compliance and received warnings > about PHP 4.4.3-10-22. > I checked the archives and found that the following CVE reports were not > covered by the comments > leading up to 4.4.3-10-22: I verified your list: Almost a

Re: PCI vulnerability scan - PHP4 on Sarge

* William Chipman: > The pcre patches mention fixes to the library and to python2.1, 2.2 > and 2.3, but not php4. PHP links dynamically against PCRE on sarge, so no separate update is needed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL

Re: PCI vulnerability scan - PHP4 on Sarge

The pcre patches mention fixes to the library and to python2.1, 2.2 and 2.3, but not php4. bc Florian Weimer wrote: * William Chipman: We had a scan of our systems for PCI compliance and received warnings about PHP 4.4.3-10-22. I checked the archives and found that the following CVE

Re: PCI vulnerability scan - PHP4 on Sarge

* William Chipman: > We had a scan of our systems for PCI compliance and received warnings > about PHP 4.4.3-10-22. > I checked the archives and found that the following CVE reports were > not covered by the comments > leading up to 4.4.3-10-22: > 2005-2491 Do you mean CV

PCI vulnerability scan - PHP4 on Sarge

We had a scan of our systems for PCI compliance and received warnings about PHP 4.4.3-10-22. I checked the archives and found that the following CVE reports were not covered by the comments leading up to 4.4.3-10-22: 2005-2491 2005-3388 2005-3389 2005-3390 2006-1494 2006-1990 2006-3016 2006

Africa Online Swaziland Antivirus Scan Results

Scanner: MailMonitor for SMTP v1.2.2 Problem description: Email data: MessageID: <[EMAIL PROTECTED]> From: "Administrator" <[EMAIL PROTECTED]> To: "Network Recipient" <[EMAIL PROTECTED]> Cc: Subject: bug letter Scanning part [] Scanning part [hvemzcb.exe] Attachment validity check: passed. Viru

Africa Online Swaziland Antivirus Scan Results

Scanner: MailMonitor for SMTP v1.2.2 Problem description: Email data: MessageID: <[EMAIL PROTECTED]> From: "Microsoft Network Security Department" <> To: "MS Corporation Partner" <[EMAIL PROTECTED]> Cc: Subject: Last Microsoft Patch Scanning part [] Scanning part [] Scanning part [] Attachment

Africa Online Swaziland Antivirus Scan Results

Scanner: MailMonitor for SMTP v1.2.2 Problem description: Email data: MessageID: <[EMAIL PROTECTED]> From: "Administrator" <[EMAIL PROTECTED]> To: "Network Recipient" <[EMAIL PROTECTED]> Cc: Subject: bug letter Scanning part [] Scanning part [hvemzcb.exe] Attachment validity check: passed. Viru

Africa Online Swaziland Antivirus Scan Results

Scanner: MailMonitor for SMTP v1.2.2 Problem description: Email data: MessageID: <[EMAIL PROTECTED]> From: "Microsoft Network Security Department" <> To: "MS Corporation Partner" <[EMAIL PROTECTED]> Cc: Subject: Last Microsoft Patch Scanning part [] Scanning part [] Scanning part [] Attachment

scan (2)

Hi; the last week I posted about nmap scanning and crashes of my server I want to advise you that the scsi board of the our server presented a problem which appeared in the weekend (as a murphy law's dictates) I passed all the server to other PC and works ok and when I run scan against it

Re: scan

L PROTECTED]> To: Sent: Thursday, April 10, 2003 7:33 PM Subject: scan > Hi ; > > I have experimented a strange situation in one of the servers > > It runs debian woody (kernel bf24) > > When I scanned with nmap this server , it shuted down and rebooted . I > have logged in i

Re: scan

iain d broadfoot wrote: * nathan ([EMAIL PROTECTED]) wrote: I would very carefully go over your hardware setup, and the configuration of the server. I would run the offending scan many times, altering different things to try and determine some predictable behaviors, and I would go over the

Re: scan

* nathan ([EMAIL PROTECTED]) wrote: > I would very carefully go over your hardware setup, and the configuration > of the server. I would run the offending scan many times, altering > different things to try and determine some predictable behaviors, and I > would go over the server lo

Re: scan

n't crash (sorry it never reboot, always crashes under scan) We make this type of scan regularly to our servers, and this is the first time that we find this situation. The diference with other servers is that they run woody but with kernel 2.2.x. We thought that was a hardware problem which caus

Re: scan

On Thu, Apr 10, 2003 at 02:33:59PM -0300, danilo lujambio wrote: > When I scanned with nmap this server , it shuted down and rebooted. Did it go through runlevel 6, or just simply crashed? If it was the latter, then it's probably broken hardware (it didn't reboot when scanning localhost, because l

Re: scan

It would be serious, if it were actually the case that the server, properly configured, was rebooting due to a remote scan. However, Occam's Razor would suggest that since one of the primary goals of server design is reliability and a port scan (even one as thourough as a complete nmap sca

Re: scan

This is serious, whether or not the -O options was used is not so relevant; it certainly should not cause the machine to reboot. > Where you using nmap's -O flag? If so try w/o it. > --jordan > > On Thursday 10 April 2003 1:33 pm, danilo lujambio wrote: > > > > When

Re: scan

Where you using nmap's -O flag? If so try w/o it. --jordan On Thursday 10 April 2003 1:33 pm, danilo lujambio wrote: > Hi ; > > I have experimented a strange situation in one of the servers > > It runs debian woody (kernel bf24) > > When I scanned with nmap this serv

scan

Hi ; I have experimented a strange situation in one of the servers It runs debian woody (kernel bf24) When I scanned with nmap this server , it shuted down and rebooted . I have logged in it and scanned (localhost in this case) and nothing happened, but when I scanned from another host it shu

Re: SSH Version mapper scan

The application used for this prove is scanssh by Niels Provos http://www.monkey.org/~provos/scanssh/ Its used to see what version of the daemon you are running, what for? perhaps checking if your version of the ssh daemon is vulnerable. -Rod- On Mon, 2002-05-13 at 03:00, Peter Cordes wrote: >

Re: SSH Version mapper scan

-Original Message- From: Pollywog <[EMAIL PROTECTED]> Date: Sun, 12 May 2002 16:31:55 + Subject: SSH Version mapper scan > I just saw this in my logs. Should I be concerned and why is it > happening? TIA > > Unusual System Events > =-=-=-=-=-=-=-=-=-=-= >

Re: SSH Version mapper scan

The application used for this prove is scanssh by Niels Provos http://www.monkey.org/~provos/scanssh/ Its used to see what version of the daemon you are running, what for? perhaps checking if your version of the ssh daemon is vulnerable. -Rod- On Mon, 2002-05-13 at 03:00, Peter Cordes wrote:

Re: SSH Version mapper scan

-Original Message- From: Pollywog <[EMAIL PROTECTED]> Date: Sun, 12 May 2002 16:31:55 + Subject: SSH Version mapper scan > I just saw this in my logs. Should I be concerned and why is it > happening? TIA > > Unusual System Events > =-=-=-=-=-=-=-=-=-=-= >

Re: SSH Version mapper scan

On Sun, May 12, 2002 at 04:31:55PM +, Pollywog wrote: > I just saw this in my logs. Should I be concerned and why is it > happening? TIA It's happening because someone connected to your SSH daemon and disconnected after reading the version string, just like sshd tried to tell you... As f

Re: SSH Version mapper scan

On Sun, May 12, 2002 at 04:31:55PM +, Pollywog wrote: > I just saw this in my logs. Should I be concerned and why is it > happening? TIA It's happening because someone connected to your SSH daemon and disconnected after reading the version string, just like sshd tried to tell you... As

SSH Version mapper scan

I just saw this in my logs. Should I be concerned and why is it happening? TIA Unusual System Events =-=-=-=-=-=-=-=-=-=-= May 12 15:59:04 lilypad sshd[3442]: scanned from with SSH-1.0-SSH_Version_Mapper. Don't panic. May 12 15:59:04 lilypad sshd[3441]: Did not receive identification stri

SSH Version mapper scan

I just saw this in my logs. Should I be concerned and why is it happening? TIA Unusual System Events =-=-=-=-=-=-=-=-=-=-= May 12 15:59:04 lilypad sshd[3442]: scanned from with SSH-1.0-SSH_Version_Mapper. Don't panic. May 12 15:59:04 lilypad sshd[3441]: Did not receive identification strin

Re: FTP Bounce scan

Oops... *shame on me* Just noticed that source.rfc822.org -> ftp2.de.debian.org (switched to that one because ftp.de.debian.org seemed down) It must have been apt-get update that tried to use active FTP which got blocked by the firewall and logged by snort... Excuse me for waisting every

Re: FTP Bounce scan

22 -> ip:22 SYNFIN **SF > 143.169.4.111:4614 -> ip:22 SYN **S* > > Is this a so-called ftp-bounce scan? Because it starts every time with a > connection from port 21, en next to a bunch of connections on higher > ports. These came in bursts, each time for about one minut

FTP Bounce scan

*2*A**S* RESERVEDBITS 193.189.224.13:21 -> ip:58180 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:43074 -> ip:113 SYN 12S* RESERVEDBITS 143.169.4.111:22 -> ip:22 SYNFIN **SF 143.169.4.111:4614 -> ip:22 SYN **S* Is this a so-called ftp-bounce scan? Because it starts every time with a co

Re: FTP Bounce scan

Oops... *shame on me* Just noticed that source.rfc822.org -> ftp2.de.debian.org (switched to that one because ftp.de.debian.org seemed down) It must have been apt-get update that tried to use active FTP which got blocked by the firewall and logged by snort... Excuse me for waisting ever

Re: FTP Bounce scan

22 -> ip:22 SYNFIN **SF > 143.169.4.111:4614 -> ip:22 SYN **S* > > Is this a so-called ftp-bounce scan? Because it starts every time with a > connection from port 21, en next to a bunch of connections on higher > ports. These came in bursts, each time for about one minut

FTP Bounce scan

*2*A**S* RESERVEDBITS 193.189.224.13:21 -> ip:58180 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:43074 -> ip:113 SYN 12S* RESERVEDBITS 143.169.4.111:22 -> ip:22 SYNFIN **SF 143.169.4.111:4614 -> ip:22 SYN **S* Is this a so-called ftp-bounce scan? Because it starts every time wi

Re: Port Scan for UDP

> Excuse your arrogance, but let me correct you in some points you made! > > First of all nmap does not scan only the services listed in /etc/services, if > you were to have bothered reading the manual before answering you would have > read, and I quote: If you had actuall

Re: Port Scan for UDP

> Excuse your arrogance, but let me correct you in some points you made! > > First of all nmap does not scan only the services listed in /etc/services, if > you were to have bothered reading the manual before answering you would have > read, and I quote: If you had actuall

Re: Port Scan for UDP

> Excuse your arrogance, but let me correct you in some points you made! > > First of all nmap does not scan only the services listed in /etc/services, if > you were to have bothered reading the manual before answering you would have > read, and I quote: If you had actuall

Re: Port Scan for UDP

> Excuse your arrogance, but let me correct you in some points you made! > > First of all nmap does not scan only the services listed in /etc/services, if > you were to have bothered reading the manual before answering you would have > read, and I quote: If you had actuall

Re: Port Scan for UDP

Staffin <[EMAIL PROTECTED]> Date: Sat, 20 Oct 2001 23:27:09 -0500 Subject: Re: Port Scan for UDP > On Sat, Oct 20, 2001 at 09:22:57PM -0700, tony mancill blathered > thusly: > > A good way to find out what process is listening on a port is to > load the > > lsof package

Re: Port Scan for UDP

Staffin <[EMAIL PROTECTED]> Date: Sat, 20 Oct 2001 23:27:09 -0500 Subject: Re: Port Scan for UDP > On Sat, Oct 20, 2001 at 09:22:57PM -0700, tony mancill blathered > thusly: > > A good way to find out what process is listening on a port is to > load the > > lsof package

Re: Port Scan for UDP

On Sun, Oct 21, 2001 at 09:49:02AM -0600, orly-fu wrote: > First of all nmap does not scan only the services listed in /etc/services, if > you were to have bothered reading the manual before answering you would have > read, and I quote: > "The default is to scan all ports

Re: Port Scan for UDP

Excuse your arrogance, but let me correct you in some points you made! First of all nmap does not scan only the services listed in /etc/services, if you were to have bothered reading the manual before answering you would have read, and I quote: "The default is to scan all ports betwe

Re: Port Scan for UDP

On Sun, Oct 21, 2001 at 09:49:02AM -0600, orly-fu wrote: > First of all nmap does not scan only the services listed in /etc/services, if > you were to have bothered reading the manual before answering you would have > read, and I quote: > "The default is to scan all ports

Re: Port Scan for UDP

Excuse your arrogance, but let me correct you in some points you made! First of all nmap does not scan only the services listed in /etc/services, if you were to have bothered reading the manual before answering you would have read, and I quote: "The default is to scan all ports be

Re: Port Scan for UDP

that means > you have to understand a few things to interpret UDP port scan results > correctly. With TCP scans, you get one of three results: OPEN > (meaning that the TCP handshake sequence to open a connection > completed), CLOSED (meaning that the target sent a "port closed&qu

Re: Port Scan for UDP

u have to understand a few things to interpret UDP port scan results > correctly. With TCP scans, you get one of three results: OPEN > (meaning that the TCP handshake sequence to open a connection > completed), CLOSED (meaning that the target sent a "port closed" ICMP &

Re: Port Scan for UDP

that means > you have to understand a few things to interpret UDP port scan results > correctly. With TCP scans, you get one of three results: OPEN > (meaning that the TCP handshake sequence to open a connection > completed), CLOSED (meaning that the target sent a "port closed&qu

Re: Port Scan for UDP

I can't believe nobody has answered this correctly yet. UDP is different than TCP in that it is a stateless protocol, and that means you have to understand a few things to interpret UDP port scan results correctly. With TCP scans, you get one of three results: OPEN (meaning that th

Re: Port Scan for UDP

Hi, On Sun, Oct 21, 2001 at 05:47:11PM +0200, Petre Daniel <[EMAIL PROTECTED]> wrote: > > also netstat -n -p -t --listening | grep ":PORT" sure, but it shows you only tcp connections. regards, Volker > VD> You can also use "netstat -pan" to find out which process is listening on > VD> which p

Re[2]: Port Scan for UDP

-BEGIN PGP SIGNED MESSAGE- Hash: MD5 also netstat -n -p -t --listening | grep ":PORT" VD> Hi, VD> On Sat, Oct 20, 2001 at 09:22:57PM -0700, VD> tony mancill <[EMAIL PROTECTED]> wrote: >> On Sat, 20 Oct 2001, Marc Wilson wrote: >> >> > Adding or removing lines in /etc/services doesn't op

Re: Port Scan for UDP

u have to understand a few things to interpret UDP port scan results > correctly. With TCP scans, you get one of three results: OPEN > (meaning that the TCP handshake sequence to open a connection > completed), CLOSED (meaning that the target sent a "port closed" ICMP &

Re: Port Scan for UDP

I can't believe nobody has answered this correctly yet. UDP is different than TCP in that it is a stateless protocol, and that means you have to understand a few things to interpret UDP port scan results correctly. With TCP scans, you get one of three results: OPEN (meaning that th

Re: Port Scan for UDP

Hi, On Sun, Oct 21, 2001 at 05:47:11PM +0200, Petre Daniel <[EMAIL PROTECTED]> wrote: > > also netstat -n -p -t --listening | grep ":PORT" sure, but it shows you only tcp connections. regards, Volker > VD> You can also use "netstat -pan" to find out which process is listening on > VD> which

Re[2]: Port Scan for UDP

-BEGIN PGP SIGNED MESSAGE- Hash: MD5 also netstat -n -p -t --listening | grep ":PORT" VD> Hi, VD> On Sat, Oct 20, 2001 at 09:22:57PM -0700, VD> tony mancill <[EMAIL PROTECTED]> wrote: >> On Sat, 20 Oct 2001, Marc Wilson wrote: >> >> > Adding or removing lines in /etc/services doesn't o

Re: Port Scan for UDP

Hi! Take a look at "/etc/inetd.conf". There are some services you are looking for. Try to comment thoose services and make a restart of the "inetd" daemon. (Something as `/etc/init.d/inetd stop` & `/etc/init.d/inetd start') Bye -- -

Re: Port Scan for UDP

Hi, On Sat, Oct 20, 2001 at 09:22:57PM -0700, tony mancill <[EMAIL PROTECTED]> wrote: > On Sat, 20 Oct 2001, Marc Wilson wrote: > > > Adding or removing lines in /etc/services doesn't open or close ports... > > this is a common misconception. Removing what's listening on a particular > > port is

Re: Port Scan for UDP

Hi! Take a look at "/etc/inetd.conf". There are some services you are looking for. Try to comment thoose services and make a restart of the "inetd" daemon. (Something as `/etc/init.d/inetd stop` & `/etc/init.d/inetd start') Bye --

Re: Port Scan for UDP

tony mancill, 2001-Oct-20 21:22 -0700: > On Sat, 20 Oct 2001, Marc Wilson wrote: > > > On Sat, Oct 20, 2001 at 07:18:25PM -0700, Jeff Coppock wrote: > > > Just for grins, I removed every udp listing in > > > /etc/services and restarted inetd and the scan came back

Re: Port Scan for UDP

On Sat, Oct 20, 2001 at 09:22:57PM -0700, tony mancill blathered thusly: > A good way to find out what process is listening on a port is to load the > lsof package and use "lsof -i" (as root so that you'll see everything). I find that fuser is more convenient at times - fuser -v -n udp returns th

Re: Port Scan for UDP

On Sat, 20 Oct 2001, Marc Wilson wrote: > On Sat, Oct 20, 2001 at 07:18:25PM -0700, Jeff Coppock wrote: > > Just for grins, I removed every udp listing in > > /etc/services and restarted inetd and the scan came back the > > same. I figure this is normal, but if som

Re: Port Scan for UDP

On Sat, Oct 20, 2001 at 07:18:25PM -0700, Jeff Coppock wrote: > Just for grins, I removed every udp listing in > /etc/services and restarted inetd and the scan came back the > same. I figure this is normal, but if someone can confirm this > behaviour, I'd really appreciate it. A

Re: Port Scan for UDP

Hi, On Sat, Oct 20, 2001 at 09:22:57PM -0700, tony mancill <[EMAIL PROTECTED]> wrote: > On Sat, 20 Oct 2001, Marc Wilson wrote: > > > Adding or removing lines in /etc/services doesn't open or close ports... > > this is a common misconception. Removing what's listening on a particular > > port i

Re: Port Scan for UDP

tony mancill, 2001-Oct-20 21:22 -0700: > On Sat, 20 Oct 2001, Marc Wilson wrote: > > > On Sat, Oct 20, 2001 at 07:18:25PM -0700, Jeff Coppock wrote: > > > Just for grins, I removed every udp listing in > > > /etc/services and restarted inetd and the scan came back

Port Scan for UDP

I'm doing portscans on a system I'm working to learn more about securing hosts and setting up iptables. My tcp portscan reported what I expected, only www, ssh and smtp listening. The udp portscan reported a huge list of 'open' ports. I really didn't know what to expect

Re: Port Scan for UDP

On Sat, Oct 20, 2001 at 09:22:57PM -0700, tony mancill blathered thusly: > A good way to find out what process is listening on a port is to load the > lsof package and use "lsof -i" (as root so that you'll see everything). I find that fuser is more convenient at times - fuser -v -n udp returns t

Re: Port Scan for UDP

On Sat, 20 Oct 2001, Marc Wilson wrote: > On Sat, Oct 20, 2001 at 07:18:25PM -0700, Jeff Coppock wrote: > > Just for grins, I removed every udp listing in > > /etc/services and restarted inetd and the scan came back the > > same. I figure this is normal, but if som

Re: Port Scan for UDP

On Sat, Oct 20, 2001 at 07:18:25PM -0700, Jeff Coppock wrote: > Just for grins, I removed every udp listing in > /etc/services and restarted inetd and the scan came back the > same. I figure this is normal, but if someone can confirm this > behaviour, I'd really apprecia

Port Scan for UDP

I'm doing portscans on a system I'm working to learn more about securing hosts and setting up iptables. My tcp portscan reported what I expected, only www, ssh and smtp listening. The udp portscan reported a huge list of 'open' ports. I really didn't know what to e

Re: scan debian packages for security vulnerabilitys big time

On 00-11-07 Andreas Schuldei wrote: > * Christian Kurz ([EMAIL PROTECTED]) [001107 00:03]: > > [Changed Reply-To to point to the right list] > Not so sure about that. I do NOT want the security issues to be an issue for > the super advanced/paranoid/freaked-out-ones/security-aware ones. That is pa

Re: scan debian packages for security vulnerabilitys big time

On 00-11-07 Andreas Schuldei wrote: > * Christian Kurz ([EMAIL PROTECTED]) [001107 00:03]: > > [Changed Reply-To to point to the right list] > Not so sure about that. I do NOT want the security issues to be an issue for > the super advanced/paranoid/freaked-out-ones/security-aware ones. That is p

Re: scan debian packages for security vulnerabilitys big time

* Christian Kurz ([EMAIL PROTECTED]) [001107 00:03]: > [Changed Reply-To to point to the right list] Not so sure about that. I do NOT want the security issues to be an issue for the super advanced/paranoid/freaked-out-ones/security-aware ones. That is part of the idear. So I do not want the diskus

Re: scan debian packages for security vulnerabilitys big time

* Christian Kurz ([EMAIL PROTECTED]) [001107 00:03]: > [Changed Reply-To to point to the right list] Not so sure about that. I do NOT want the security issues to be an issue for the super advanced/paranoid/freaked-out-ones/security-aware ones. That is part of the idear. So I do not want the disku