Koozali.org: home of the SME Server

Messages log file interpretation

dann

Messages log file interpretation
« on: February 01, 2005, 03:17:24 AM »
Hello folks,

I've been seeing the following entry many times in my Messages log and I don't know what it means. The server is SME 6.0.1-01 running Servergateway-private mode.

Jan 31 10:53:30 ztserver kernel: denylog:IN=eth1 OUT= MAC=00:50:2c:a5:df:59:00:00:0c:fb:41:70:08:00 SRC=65.93.137.167 DST=65.75.194.118 LEN=48 TOS=0x00 PREC=0x00 TTL=115 ID=37083 DF PROTO=TCP SPT=3182 DPT=135 WINDOW=16384 RES=0x00 SYN URGP=0

My server has also been getting in a mode where I can no longer log into it from the console or HTTP. The Admin console is set to require a login. The log file info above is dumping to the console when this happens. I have to hit the reset switch to get it back online.

All help would be appreciated very much.

jdarrough

Messages log file interpretation
« Reply #1 on: February 21, 2005, 02:58:16 AM »
Hi Dan. Please let me know if someone replies. I have hundreds of these entries as well. It looks like someone is scanning looking for open ports, but since I am on a dialup and using their DHCP address, whatever that may be, I find that difficult to believe. Here is a snippet of mine for anyone who reads this and can help.

And thanks in advance for anyone who helps us.

Regards, Jim Darrough Springfield, Oregon



Feb 20 16:50:46 home-server kernel: denylog:IN=ppp0 OUT= MAC= SRC=65.54.181.133 DST=64.28.62.31 LEN=40 TOS=0x00 PREC=0x00 TTL=119 ID=58472 DF PROTO=TCP SPT=443 DPT=1196 WINDOW=16807 RES=0x00 ACK URGP=0
Feb 20 16:50:46 home-server kernel: denylog:IN=ppp0 OUT= MAC= SRC=65.54.181.133 DST=64.28.62.31 LEN=40 TOS=0x00 PREC=0x00 TTL=119 ID=58473 DF PROTO=TCP SPT=443 DPT=1196 WINDOW=0 RES=0x00 ACK RST URGP=0
Feb 20 16:53:03 home-server kernel: denylog:IN=ppp0 OUT= MAC= SRC=66.11.128.151 DST=64.28.62.31 LEN=48 TOS=0x00 PREC=0x00 TTL=118 ID=59779 DF PROTO=TCP SPT=2303 DPT=617 WINDOW=65535 RES=0x00 SYN URGP=0
Feb 20 16:53:06 home-server kernel: denylog:IN=ppp0 OUT= MAC= SRC=66.11.128.151 DST=64.28.62.31 LEN=48 TOS=0x00 PREC=0x00 TTL=118 ID=61480 DF PROTO=TCP SPT=2303 DPT=617 WINDOW=65535 RES=0x00 SYN URGP=0

Offline pfloor

  • *****
  • 889
  • +1/-0
Messages log file interpretation
« Reply #2 on: February 21, 2005, 04:57:12 AM »
[Post erased by pfloor]
In life, you must either "Push, Pull or Get out of the way!"

Offline NickR

  • *
  • 283
  • +0/-0
    • http://www.witzendcs.co.uk/
Re: Messages log file interpretation
« Reply #3 on: February 21, 2005, 07:39:50 AM »
Quote from: "dann"

Jan 31 10:53:30 ztserver kernel: denylog:IN=eth1 OUT= MAC=00:50:2c:a5:df:59:00:00:0c:fb:41:70:08:00 SRC=65.93.137.167 DST=65.75.194.118 LEN=48 TOS=0x00 PREC=0x00 TTL=115 ID=37083 DF PROTO=TCP SPT=3182 DPT=135 WINDOW=16384 RES=0x00 SYN URGP=0


These are connection attempts from machines on the 'net.  Nothing to worry about. Briefly, SRC= gives you the originating IP address, PROTO= is the protocol (usually TCP or UDP) and DPT= is the port on your SME that it was trying to talk to.

Quote

My server has also been getting in a mode where I can no longer log into it from the console or HTTP. The Admin console is set to require a login. The log file info above is dumping to the console when this happens. I have to hit the reset switch to get it back online.


This is bad!  Never hit reset unless it is absolutely impossible to recover any other way.  Next time, try using ALT-F2 (or even ALT-F3) to get to another console to login from.  You could even just do CTRL-ALT-DEL to do a clean shutdown & reboot.

You need to find out why your machine is crapping out like this & my suspicion is firstly memory - try replacing the memory.
--
Nick......

jdarrough

Thanks for the Info
« Reply #4 on: February 21, 2005, 08:48:45 PM »
Thanks very much for the help. I think that even though e-smith (SME) is blocking these attempts, I need to find a way to prevent them. I am on dialup, and any attempts to port scan my system significantly impacts throughput. Especially when I only get 24k.

Anyone have any ideas how I can prevent the scans from getting through my modem to my box?

Thanks again,

Jim Darrough  :-)

Offline NickR

  • *
  • 283
  • +0/-0
    • http://www.witzendcs.co.uk/
Re: Thanks for the Info
« Reply #5 on: February 21, 2005, 08:56:55 PM »
Quote from: "jdarrough"
Anyone have any ideas how I can prevent the scans from getting through my modem to my box?


You can't.  If you think about it, the modem is simply providing a circuit by which packets come to you from the big, bad internet.  The only realistic way of stopping them before they impact your bandwidth is for your ISP to block them.
--
Nick......

jdarrough

Messages log file interpretation
« Reply #6 on: February 21, 2005, 09:14:08 PM »
Quote
You can't. If you think about it, the modem is simply providing a circuit by which packets come to you from the big, bad internet. The only realistic way of stopping them before they impact your bandwidth is for your ISP to block them.


I appreciate that you took time to reply, I would appreciate it even MORE if you had some ideas that would be helpful. Such as, how can my isp block scans when they don't directly provide dialup connectivity?

My isp uses a service called USPOPS that provides dialtone to us lowly modem users. Their interface to the isp is probably via T3 or maybe even DS3 however, it would seem to me that USPOPS is the one "allowing" port scans. From the "big bad internet"   ;-)

Does that make sense to you, Nick?

BTW: Thanks for the information on what the various abbreviations were. Looks like the hackers  were looking at known vulnerabilities in Windows to me. Also, I read somewhere that more and more dialup systems are being hacked to implant denial-of-service robots etc.

Thanks again, Jim Darrough[/quote]

Offline NickR

  • *
  • 283
  • +0/-0
    • http://www.witzendcs.co.uk/
Messages log file interpretation
« Reply #7 on: February 22, 2005, 01:25:25 AM »
The only thing I can suggest is that you talk to your ISP &/or USPOPS and see if they can do anything for you.

However, I think you are overstating the hit to bandwith - each packet is tiny ( a few tens of bytes at most) and they don't appear to be coming in all that fast.
--
Nick......

jdarrough

Messages log file interpretation
« Reply #8 on: February 22, 2005, 06:39:19 PM »
THanks again. I was afraid of that. I did speak with my isp who is going to talk to USPOPS about it. Not sure if there is anything that can be done either.

As for overstating, some days I get hundreds of scans. Even though the packet is small, there is still time involved to ackknowledge the packet and log it. Adds up. And believe me, my speeds are already atrocious since I live out in the country. Seems like every time someone in our neighborhood picks up a telephone to make a call, the bandwidth is reduced.

We are hoping that the telco here will see clear to install DSL equipment nearby but it's an uphill battle.

Thanks, Jim Darrough

buknoy

Messages log file interpretation
« Reply #9 on: March 05, 2005, 12:22:03 PM »
Hi everybody, I have the same problem with you. I also see this "...<computer name> kernel : denylog ..." when I view my /var/log/messages file. Worst is that my 10GB hard disk will be full in 12 hours. I already capped my log files to 500k, flush my cache and deleted compressed log files but still my free blocks kept on shrinking until I could no longer access my SME box. I had already re-installed my server (plus updates) 3 times this week.

I read somewhere about the vulnerabilities of qmail but could not understand its technicalities. Nevertheless I temporarily "killed" all my smtpfront-qmail, qmail and popd services and the "shrinking" stopped. Surprisingly, browsing at my 14 workstations became faster.

Would somebody explain what happened and how can I use the mail services without sacrificing my server's performance? What other updates should I use besides those included in http://sme.braunstein.de/update/smeplus.sh ?

I never had this problem since 8 months ago using the 6.0.1-01 version. My server is Pentium III-500 with 512MB RAM and 10GB hard disk.

Don :-(

Offline raem

  • *
  • 3,972
  • +4/-0
Messages log file interpretation
« Reply #10 on: March 07, 2005, 09:15:18 AM »
buknoy

> ...how can I use the mail services without sacrificing my server's performance?
> I never had this problem since 8 months ago using the 6.0.1-01 version.

If you did a good search you would have found these.
If your issue is mail related then this may help.
These settings are OK for a slow connection (and/or a slow server), you can experiment with them to find what suits your situation the best.

/sbin/e-smith/db configuration setprop qmail ConcurrencyRemote 3
/sbin/e-smith/signal-event email-update
/etc/init.d/qmail restart

You may also need to change:

/sbin/e-smith/db configuration setprop qmail ConcurrencyLocal 5
/sbin/e-smith/signal-event email-update
/etc/init.d/qmail restart

To check the settings do:

/sbin/e-smith/config show qmail

qmail=service
    ConcurrencyLocal=5
    ConcurrencyRemote=3
    status=enabled


This may also help, depending what other services you have running eg clamav and spamassassin.
A search would have found it also.

http://forums.contribs.org/index.php?topic=22535.0
Spamassassin clogs minimum configurations
pretty fast once it starts chewing on more than
2 email messages at a time.
You could try changing /etc/sysconfig/spamd
to contain the following (and restart /etc/init.d/spamc):

OPTIONS="-d -m2"

it will prevent the spamd daemon from running
more than 2 processes at a time although
it will also severely limit email
throughput.


Another tip from Charlie Brady, also found by a search.

http://forums.contribs.org/index.php?topic=26253.msg106763#msg106763

But it's not the qmail setting you need to tweak (that's for local and remote deliveries *from* qmail, not into qmail) - you need to change the number of concurrent smtpfront-qmail processes. That's not currently controlled by a database setting, but you can tweak it by creating a custom template fragment

/etc/e-smith/template-custom\
/var/service/smtpfront-qmail/runenv/Concurrency

containing:

CONCURRENCYREMOTE=4

then do:

/sbin/e-smith/signal-event email-update


Let us know how these changes help your situation(s). Feedback is always good to see if the tips help out or not.
...

jdarrough

Some Help from ISP
« Reply #11 on: March 07, 2005, 07:50:48 PM »
I spent some time going through my denylogs and after discussing it with my isp, a number os IP addresses were blocked on their end. This resulted in only about 800 portscans per day vice the several thousand I was seeing earlier.

Next is to find a DNS/REVERSE DNS utility that will allow me to input a list of IP addresses and get contact information (if available) for them.

Regards, Jim Darrough

Tino

Messages log file interpretation
« Reply #12 on: March 10, 2005, 12:29:19 AM »
Deny log entries comes with any telecom "dailup" connection (analogue, ISDN, xDSL, etc.) The problem with analogue dailups is that while you are getting polled by any external IP (this could even include your ISP mail server) your server remains active and will not disconnect.

What make this even worse is that you will find a pattern in most of the IP addresses. Most of the originating IP addresses comes from the same IP range. Generally these IP's will be within the same IP range as your server. This is an indication that your dailup ISP uses "modem racks" which will give you the perception that remote users are trying to get access to your server.

If you inspect the Destination Port, you will find that there are a lot of polling done on port where you will normally find Microsoft product listening.

There is not much you can do, if you are concerned about costs, try xDSL or something better that gives you permanent connection at a fixed rate.

If you are concerned about security, implement a 2x NIC routing firewall. SME does give you the option of configurating 2x NIC for internal routing over the 2 NIC's. You can further fortify security by using a router. This will realy give most hacker something to think about.

Within this configuration you have the following:
1. Router WAN IP address
2. Router LAN IP address going into NIC 1 of SME (10.0.0.2)
3. SME NIC 1 LAN IP address  (10.0.0.1)
4. SME NIC 2 LAN IP address (192.168.1.1)
5. The rest of your LAN w/Station will have IP address within the 192.168.1.xx address range

Besides that, there is not much more you could do.

To resolve the IP to a domain name try using TRACEROUTE / TRACERT on MS systems. It differs from MS Win 9x to 2000/XP



TIP OF THE DAY:

When assigning IP addresses manually, try and use the following method on the D-class of your IP address:

1-10     : Servers
11 - 240 : Workstation, Print Servers, etc.
241 - 254: Any high-end Network Device e.g.: Routers

This will give you scallability in terms of your IP selection and the devices receiving those IP's.

Should you pickup that an IP address that is generating a lot of traffic, maybe from a Virus Infection, you can identify what type of device that is and isolate it until you have resolved the problem.


Regards,

Tino

Offline CharlieBrady

  • *
  • 6,918
  • +3/-0
Messages log file interpretation
« Reply #13 on: March 10, 2005, 05:05:37 PM »
Quote from: "Tino"
Deny log entries comes with any telecom "dailup" connection ...


No, deny log entries come with *any* internet connection. All hosts connected to the Internet are hit with packets which aren't destined to valid services. Some of those packets are port scans, some are exploit attempts, and some are just misaddressed.

If you don't want any such log entries, then do:

/sbin/e-smith/config setprop masq Logging none
/sbin/e-smith/signal-event remoteaccess-update

jdarrough

Messages log file interpretation
« Reply #14 on: March 10, 2005, 06:32:01 PM »
Tino, thanks for your input. I understand what you are saying however, in my case, the scans are external. My isp does NOT use modem racks, but uses a service that does that work for them. We have determined that a large percentage of these scans are coming from Asian countries; the isp blocked an entire range and my scans have dropped from 1 - 2k per day to less than 500.

There IS something I can do about them, and with my isp's help, it seems to work. The scans from individuals who seem to have trojans on their boxen will be more tedious unless I can come up with some way to input a long list of ip addresses and get information in bulk as to their domain administrator. Ones that don't bother to provide dns will be summarily ignored.

Thanks to all of you folks for helping me get educated.

Regards, Jim