Re: logging request
To log syslog messages to another server just edit /etc/syslog.conf and direct kern.=info to @hostname_of_logging_machine. You also have to go to the logging machine and setup it up to recieive logs from other computers by using the -r argument on syslogd. (see man page) I would like to make another comment that's not exactly directed to your post but might help in the future. There are hackers that search through mailing list and newsgroup archives looking for posts similar to yours in that you include alot of information about yourself in your sig file. This allows a hacker to know the name of the firewall manager at your company as well as some other important details. I could call your main office number now and perform social engineering. Hi this is Jon Miller from the Systems Department, i have to reset your password, what was your old one again? Of course nobody needs to know a previous password in order to reset one.. but i'm willing to bet there's at least one user i could get on the phone that would tell me. Of course this type of engineering goes on all the time, dropping the name of the director of systems sure makes it sound more legit. Also in the future if you post specific questions about your firewall that include any details about its configuration, a hacker could read that posting and instead of helping you plug the hole... comprimise your system. Hope this helps out in some way. Clint/schwack On Sat, 2 Jun 2001, Jon Miller wrote: After setting up the IPChains policies and rules, I want to be able to have a log file of any DENY packets sent to me. We use GroupWise as a email package. I also want those log files to exist on another Debian server that sits behind the firewall. TIA Jon L. Miller, MCNE Director/Sr Systems Consultant MMT Networks Pty Ltd http://www.mmtnetworks.com.au PH: +61 8 9242 8600 FX: +61 8 9242 8611 I don't know the key to success, but the key to failure is trying to please everybody. -Bill Cosby -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: logging request
To log syslog messages to another server just edit /etc/syslog.conf and direct kern.=info to @hostname_of_logging_machine. You also have to go to the logging machine and setup it up to recieive logs from other computers by using the -r argument on syslogd. (see man page) I would like to make another comment that's not exactly directed to your post but might help in the future. There are hackers that search through mailing list and newsgroup archives looking for posts similar to yours in that you include alot of information about yourself in your sig file. This allows a hacker to know the name of the firewall manager at your company as well as some other important details. I could call your main office number now and perform social engineering. Hi this is Jon Miller from the Systems Department, i have to reset your password, what was your old one again? Of course nobody needs to know a previous password in order to reset one.. but i'm willing to bet there's at least one user i could get on the phone that would tell me. Of course this type of engineering goes on all the time, dropping the name of the director of systems sure makes it sound more legit. Also in the future if you post specific questions about your firewall that include any details about its configuration, a hacker could read that posting and instead of helping you plug the hole... comprimise your system. Hope this helps out in some way. Clint/schwack On Sat, 2 Jun 2001, Jon Miller wrote: After setting up the IPChains policies and rules, I want to be able to have a log file of any DENY packets sent to me. We use GroupWise as a email package. I also want those log files to exist on another Debian server that sits behind the firewall. TIA Jon L. Miller, MCNE Director/Sr Systems Consultant MMT Networks Pty Ltd http://www.mmtnetworks.com.au PH: +61 8 9242 8600 FX: +61 8 9242 8611 I don't know the key to success, but the key to failure is trying to please everybody. -Bill Cosby
Re: Wrong DNS configuration. Which?
To me that doesn't look like misconfigured DNS at all. To me it looks like sombodies trying to find mailservers that will allow them to relay mail, or they are trying to relay mail from a bogus domain (which is why you can't do a reverse lookup nor 'DIG' info on the remote machine). Its a common practice for spammers to use bogus source domains. I think it gives them some sense that their "spoofing" their identity. In any event, i'd just ignore these errors. If your installation is setup correctly to DENY relaying from unauthorized domains, which i think sendmail is setup like that by default now, then you should be fine. Just my 2 cents. Clint/Schwack On Thu, 1 Mar 2001, Ducrot Bruno wrote: On Wed, Feb 28, 2001 at 10:14:05PM -0800, Jamie Heilman wrote: Romanenko M.A. wrote: Am I right, that sendmail's check_mail rejects connection because there are no A-record for tgngu.tyumen.ru in other side DNS configuration? Yes, now if you believe this is a desirable configuration or not is another matter, but that is probably what is happening. It might be spam, it might be a misconfiguration on their end. It's seem there is a misconfiguration on the other side: ducrot@poup:~$ dig tgngu.tyumen.ru mx ; DiG 8.2 tgngu.tyumen.ru mx ;; res options: init recurs defnam dnsrch ;; got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 4 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 3 ;; QUERY SECTION: ;; tgngu.tyumen.ru, type = MX, class = IN ;; ANSWER SECTION: tgngu.tyumen.ru.10h13m7s IN MX 10 mail.tgngu.tyumen.ru. tgngu.tyumen.ru.10h13m7s IN MX 20 mail.tyumen.ru. ;; AUTHORITY SECTION: tgngu.tyumen.ru.1D IN NSpride.tgngu.tyumen.ru. ;; ADDITIONAL SECTION: mail.tyumen.ru. 1D IN A 194.67.48.7 mail.tyumen.ru. 1D IN A 213.24.146.7 pride.tgngu.tyumen.ru. 1D IN A 194.67.48.65 ;; Total query time: 3875 msec ;; FROM: poup.poupinou.org to SERVER: default -- 127.0.0.1 ;; WHEN: Thu Mar 1 09:51:20 2001 ;; MSG SIZE sent: 33 rcvd: 143 Thus, the "main" priority for the mx is mail.tgngu.tyumen.ru. But: ducrot@poup:~$ nslookup mail.tgngu.tyumen.ru Server: localhost.localdomain Address: 127.0.0.1 Non-authoritative answer: Name:server.tgngu.tyumen.ru Address: 194.67.48.89 Aliases: mail.tgngu.tyumen.ru and also their mailer is a cname to server.tgngu.tyumen.ru. You can check anywhere that this is a bad thing. (see rfc 821, sec. 3.7 for example). -- Ducrot Bruno http://www.poupinou.orgPage profaissionelle http://toto.tu-me-saoules.com Haume page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Wrong DNS configuration. Which?
To me that doesn't look like misconfigured DNS at all. To me it looks like sombodies trying to find mailservers that will allow them to relay mail, or they are trying to relay mail from a bogus domain (which is why you can't do a reverse lookup nor 'DIG' info on the remote machine). Its a common practice for spammers to use bogus source domains. I think it gives them some sense that their spoofing their identity. In any event, i'd just ignore these errors. If your installation is setup correctly to DENY relaying from unauthorized domains, which i think sendmail is setup like that by default now, then you should be fine. Just my 2 cents. Clint/Schwack On Thu, 1 Mar 2001, Ducrot Bruno wrote: On Wed, Feb 28, 2001 at 10:14:05PM -0800, Jamie Heilman wrote: Romanenko M.A. wrote: Am I right, that sendmail's check_mail rejects connection because there are no A-record for tgngu.tyumen.ru in other side DNS configuration? Yes, now if you believe this is a desirable configuration or not is another matter, but that is probably what is happening. It might be spam, it might be a misconfiguration on their end. It's seem there is a misconfiguration on the other side: [EMAIL PROTECTED]:~$ dig tgngu.tyumen.ru mx ; DiG 8.2 tgngu.tyumen.ru mx ;; res options: init recurs defnam dnsrch ;; got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 4 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 3 ;; QUERY SECTION: ;; tgngu.tyumen.ru, type = MX, class = IN ;; ANSWER SECTION: tgngu.tyumen.ru.10h13m7s IN MX 10 mail.tgngu.tyumen.ru. tgngu.tyumen.ru.10h13m7s IN MX 20 mail.tyumen.ru. ;; AUTHORITY SECTION: tgngu.tyumen.ru.1D IN NSpride.tgngu.tyumen.ru. ;; ADDITIONAL SECTION: mail.tyumen.ru. 1D IN A 194.67.48.7 mail.tyumen.ru. 1D IN A 213.24.146.7 pride.tgngu.tyumen.ru. 1D IN A 194.67.48.65 ;; Total query time: 3875 msec ;; FROM: poup.poupinou.org to SERVER: default -- 127.0.0.1 ;; WHEN: Thu Mar 1 09:51:20 2001 ;; MSG SIZE sent: 33 rcvd: 143 Thus, the main priority for the mx is mail.tgngu.tyumen.ru. But: [EMAIL PROTECTED]:~$ nslookup mail.tgngu.tyumen.ru Server: localhost.localdomain Address: 127.0.0.1 Non-authoritative answer: Name:server.tgngu.tyumen.ru Address: 194.67.48.89 Aliases: mail.tgngu.tyumen.ru and also their mailer is a cname to server.tgngu.tyumen.ru. You can check anywhere that this is a bad thing. (see rfc 821, sec. 3.7 for example). -- Ducrot Bruno http://www.poupinou.orgPage profaissionelle http://toto.tu-me-saoules.com Haume page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Apt-get package verification
Anybody know if apt will do any sort of verification of checksums or anything to validate the package is from debian? I'm using apt to automate priority security updates on several of my customers firewalls and i'm curious that is somebody poisons some routes and/or dns caches, we could have serious trouble. Thanks for your comments (new to debian) Schwack clint sand -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Apt-get package verification
Anybody know if apt will do any sort of verification of checksums or anything to validate the package is from debian? I'm using apt to automate priority security updates on several of my customers firewalls and i'm curious that is somebody poisons some routes and/or dns caches, we could have serious trouble. Thanks for your comments (new to debian) Schwack clint sand
