http://lifehacker.com/why-you-should-learn-to-run-a-server-before-you-learn-t-1497178889
This was a good read!
The reader comments were also very much full of rich details and advice.
Everyone nowadays wants to learn to program and only thinks of the glorious moments (creating the perfect, most popular app that will make you tons of money). A perfect programmer would be well-rounded and understand server management as well as coding.
Showing posts with label security. Show all posts
Showing posts with label security. Show all posts
Monday, February 03, 2014
Thursday, October 24, 2013
Google blacklist blocking php.net
Google blacklist blocking php.net
Google's safe browsing API, a security blacklist service which warns of malicious web sites, has marked the php.net site as malicious. As a result, users of Google Chrome and Mozilla Firefox get a dire warning when attempting to visit the site.
Read more here:
Note: Also, be aware of the comments section under the article. There is a bit of banter going on about 1) it was a non-news-worthy event, since Google did what it was supposed to have done -- ie, it was not a false positive, 2) a reader insists that it was a false positive and that Google has a habit of blocking small business owners, causing them financial woes, and 3) reader points out that Netcraft detected possible malware at php.net (substantiated by a Hacker News analysis), which substantiates Google's claim.
Tuesday, July 02, 2013
Inbound traffic on source port 80
I haven't checked my firewall logs in awhile, so I decided to do a very quick assessment.
I immediately noticed a pattern of inbound hosts attempting to communicate on source port 80, which is weird, as that's not typically a normal port for non-webservers to communicate on. Web clients typically communicate on destination port 80 unless it's the web server responding to a previous HTTP request (to a client). That's not the case here. These connection attempts are being initiated at source port, by IPs not normally affiliated with my server.
Here's an example:
Jul 2 08:40:18 li7-220 kernel: Clean-up Rule - BLOCKED: IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:84:78:ac:0d:79:c1:08:00 SRC=92.53.126.193 DST=abc.def.ghi.klm LEN=44 TOS=0x00 PREC=0x00 TTL=53 ID=21826 PROTO=TCP SPT=80 DPT=64689 WINDOW=16384 RES=0x00 ACK SYN URGP=0
Jul 2 11:15:50 li7-220 kernel: Clean-up Rule - BLOCKED: IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:84:78:ac:0d:79:c1:08:00 SRC=77.241.198.20 DST=abc.def.ghi.klm LEN=44 TOS=0x00 PREC=0x00 TTL=115 ID=30264 DF PROTO=TCP SPT=80 DPT=8713 WINDOW=8192 RES=0x00 ACK SYN URGP=0
Jul 2 11:15:53 li7-220 kernel: Clean-up Rule - BLOCKED: IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:84:78:ac:0d:79:c1:08:00 SRC=77.241.198.20 DST=abc.def.ghi.klm LEN=44 TOS=0x00 PREC=0x00 TTL=115 ID=323 DF PROTO=TCP SPT=80 DPT=8713 WINDOW=8192 RES=0x00 ACK SYN URGP=0
Jul 2 12:17:20 li7-220 kernel: Clean-up Rule - BLOCKED: IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:84:78:ac:0d:79:c1:08:00 SRC=172.245.4.168 DST=abc.def.ghi.klm LEN=44 TOS=0x00 PREC=0x00 TTL=56 ID=0 DF PROTO=TCP SPT=80 DPT=5359 WINDOW=5840 RES=0x00 ACK SYN URGP=0
Jul 2 14:37:01 li7-220 kernel: Clean-up Rule - BLOCKED: IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:84:78:ac:0d:79:c1:08:00 SRC=94.23.170.2 DST=abc.def.ghi.klm LEN=44 TOS=0x00 PREC=0x00 TTL=52 ID=36510 PROTO=TCP SPT=80 DPT=26429 WINDOW=16384 RES=0x00 ACK SYN URGP=0
Jul 2 14:39:33 li7-220 kernel: Clean-up Rule - BLOCKED: IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:84:78:ac:0d:79:c1:08:00 SRC=91.121.9.198 DST=abc.def.ghi.klm LEN=44 TOS=0x00 PREC=0x00 TTL=52 ID=43029 PROTO=TCP SPT=80 DPT=30638 WINDOW=16384 RES=0x00 ACK SYN URGP=0
Jul 2 15:02:45 li7-220 kernel: Clean-up Rule - BLOCKED: IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:84:78:ac:0d:79:c1:08:00 SRC=213.186.33.5 DST=abc.def.ghi.klm LEN=44 TOS=0x00 PREC=0x00 TTL=236 ID=35986 PROTO=TCP SPT=80 DPT=11082 WINDOW=536 RES=0x00 ACK SYN URGP=0
Jul 2 17:02:10 li7-220 kernel: Clean-up Rule - BLOCKED: IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:84:78:ac:0d:79:c1:08:00 SRC=91.105.235.7 DST=abc.def.ghi.klm LEN=44 TOS=0x00 PREC=0x00 TTL=52 ID=0 DF PROTO=TCP SPT=80 DPT=40217 WINDOW=14600 RES=0x00 ACK SYN URGP=0
Jul 2 17:02:10 li7-220 kernel: Clean-up Rule - BLOCKED: IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:84:78:ac:0d:79:c1:08:00 SRC=91.105.235.7 DST=abc.def.ghi.klm LEN=44 TOS=0x00 PREC=0x00 TTL=52 ID=0 DF PROTO=TCP SPT=80 DPT=40217 WINDOW=14600 RES=0x00 ACK SYN URGP=0
Jul 2 17:53:52 li7-220 kernel: Clean-up Rule - BLOCKED: IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:84:78:ac:0d:79:c1:08:00 SRC=142.4.208.23 DST=abc.def.ghi.klm LEN=44 TOS=0x00 PREC=0x00 TTL=56 ID=0 DF PROTO=TCP SPT=80 DPT=31415 WINDOW=14600 RES=0x00 ACK SYN URGP=0
Jul 2 18:15:55 li7-220 kernel: Clean-up Rule - BLOCKED: IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:84:78:ac:0d:79:c1:08:00 SRC=199.101.102.66 DST=abc.def.ghi.klm LEN=44 TOS=0x00 PREC=0x00 TTL=54 ID=0 DF PROTO=TCP SPT=80 DPT=23103 WINDOW=14600 RES=0x00 ACK SYN URGP=0
Almost half of the logged traffic is trying to communicate on source port 80 (of 486 log entries, 218 are source port 80). The traffic is being blocked by the firewall, and what I'm seeing is initiation attempts. This traffic isn't a huge issue, but I'm curious as to what's going on. I've commented on such traffic before, but the amount I'm seeing now is far more than what I'm used to seeing.
I think I'll capture some traffic to try to see what's going on.
EDIT: nothing much captured so far. After some sniffing and tinkering, I had to filter some IPs out - two IPs belong to my server and the other belongs to Ubuntu):
root@li7-220:~# tcpdump -XXvvnne -s 0 -r pcap.linode.src_port_80_2 | less
reading from file pcap.linode.src_port_80_2, link-type EN10MB (Ethernet)
20:56:43.532338 84:78:ac:0d:79:c1 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 112, id 3943, offset 0, flags [none], proto TCP (6), length 44)
190.220.25.34.80 > abc.def.ghi.klm 1234: Flags [S.], cksum 0x36e9 (correct), seq 2466963778, ack 1, win 16384, options [mss 1460], length 0
0x0000: fefd 403e e7dc 8478 ac0d 79c1 0800 4500 ..@>...x..y...E.
0x0010: 002c 0f67 0000 7006 93a8 bedc 1922 42a0 .,.g..p......"B.
0x0020: 8d1e 0050 04d2 930a e142 0000 0001 6012 ...P.....B....`.
0x0030: 4000 36e9 0000 0204 05b4 0000 @.6.........
UPDATE: I let a pcap capture run overnight and when I checked the process, I got 999 hits. In looking at the pcap, I saw that I'd missed a few Ubuntu server IPs that my sercer was polling (for OS updates). I filtered those out and got 22 hits:
21:29:53.200175 84:78:ac:0d:79:c1 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 53, id 0, offset 0, flags [DF], proto TCP (6), length 44)
206.188.198.69.80 > abc.def.ghi.jkl.31029: Flags [S.], cksum 0x6868 (correct), seq 2068810236, ack 320012289, win 14600, options [mss 1460], length 0
0x0000: fefd 403e e7dc 8478 ac0d 79c1 0800 4500 ..@>...x..y...E.
0x0010: 002c 0000 4000 3506 e10b cebc c645 42a0 .,..@.5......EB.
0x0020: 8d1e 0050 7935 7b4f 89fc 1313 0001 6012 ...Py5{O......`.
0x0030: 3908 6868 0000 0204 05b4 4001 9.hh......@.
23:44:52.151134 84:78:ac:0d:79:c1 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 50, id 0, offset 0, flags [DF], proto TCP (6), length 44)
109.236.85.70.80 > abc.def.ghi.jkl.15190: Flags [S.], cksum 0x0d4e (correct), seq 3480870608, ack 3571253249, win 14600, options [mss 1460], length 0
0x0000: fefd 403e e7dc 8478 ac0d 79c1 0800 4500 ..@>...x..y...E.
0x0010: 002c 0000 4000 3206 b5db 6dec 5546 42a0 .,..@.2...m.UFB.
0x0020: 8d1e 0050 3b56 cf79 ded0 d4dd 0001 6012 ...P;V.y......`.
0x0030: 3908 0d4e 0000 0204 05b4 0000 9..N........
23:59:19.278658 84:78:ac:0d:79:c1 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 57, id 3552, offset 0, flags [none], proto TCP (6), length 44)
168.61.144.13.80 > abc.def.ghi.jkl.56871: Flags [S.], cksum 0xeacd (correct), seq 280591713, ack 4171956225, win 16384, options [mss 1460], length 0
0x0000: fefd 403e e7dc 8478 ac0d 79c1 0800 4500 ..@>...x..y...E.
0x0010: 002c 0de0 0000 3906 6be3 a83d 900d 42a0 .,....9.k..=..B.
0x0020: 8d1e 0050 de27 10b9 7d61 f8ab 0001 6012 ...P.'..}a....`.
0x0030: 4000 eacd 0000 0204 05b4 0000 @...........
01:51:58.488229 84:78:ac:0d:79:c1 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 55, id 0, offset 0, flags [DF], proto TCP (6), length 44)
84.16.89.109.80 > abc.def.ghi.jkl.25420: Flags [S.], cksum 0x1559 (correct), seq 1800765718, ack 3394417182, win 14600, options [mss 1460], length 0
0x0000: fefd 403e e7dc 8478 ac0d 79c1 0800 4500 ..@>...x..y...E.
0x0010: 002c 0000 4000 3706 c690 5410 596d 42a0 .,..@.7...T.YmB.
0x0020: 8d1e 0050 634c 6b55 8116 ca52 b21e 6012 ...PcLkU...R..`.
0x0030: 3908 1559 0000 0204 05b4 0000 9..Y........
03:57:00.885857 84:78:ac:0d:79:c1 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 118, id 7812, offset 0, flags [DF], proto TCP (6), length 44)
188.138.86.58.80 > abc.def.ghi.jkl.3456: Flags [S.], cksum 0xec7d (correct), seq 689800127, ack 2517303297, win 8192, options [mss 1460], length 0
0x0000: fefd 403e e7dc 8478 ac0d 79c1 0800 4500 ..@>...x..y...E.
0x0010: 002c 1e84 4000 7606 ab68 bc8a 563a 403e .,..@.v..h..V:@>
0x0020: e7dc 0050 0d80 291d 83bf 960b 0001 6012 ...P..).......`.
0x0030: 2000 ec7d 0000 0204 05b4 0000 ...}........
07:56:45.059391 84:78:ac:0d:79:c1 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 244, id 31356, offset 0, flags [none], proto TCP (6), length 40)
164.177.186.182.80 > abc.def.ghi.jkl.24548: Flags [R.], cksum 0x2305 (correct), seq 1331337029, ack 1, win 5840, length 0
0x0000: fefd 403e e7dc 8478 ac0d 79c1 0800 4500 ..@>...x..y...E.
0x0010: 0028 7a7c 0000 f406 1d2d a4b1 bab6 42a0 .(z|.....-....B.
0x0020: 8d1e 0050 5fe4 4f5a 9745 0000 0001 5014 ...P_.OZ.E....P.
0x0030: 16d0 2305 0000 0000 0000 0000 ..#.........
08:29:11.344433 84:78:ac:0d:79:c1 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 234, id 38305, offset 0, flags [none], proto TCP (6), length 40)
222.231.1.55.80 > abc.def.ghi.jkl.1234: Flags [S.], cksum 0xd717 (correct), seq 3438077857, ack 1, win 5840, length 0
0x0000: fefd 403e e7dc 8478 ac0d 79c1 0800 4500 ..@>...x..y...E.
0x0010: 0028 95a1 0000 ea06 32f5 dee7 0137 403e .(......2....7@>
0x0020: e7dc 0050 04d2 ccec e7a1 0000 0001 5012 ...P..........P.
0x0030: 16d0 d717 0000 0000 0000 0000 ............
I immediately noticed a pattern of inbound hosts attempting to communicate on source port 80, which is weird, as that's not typically a normal port for non-webservers to communicate on. Web clients typically communicate on destination port 80 unless it's the web server responding to a previous HTTP request (to a client). That's not the case here. These connection attempts are being initiated at source port, by IPs not normally affiliated with my server.
Here's an example:
Jul 2 08:40:18 li7-220 kernel: Clean-up Rule - BLOCKED: IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:84:78:ac:0d:79:c1:08:00 SRC=92.53.126.193 DST=abc.def.ghi.klm LEN=44 TOS=0x00 PREC=0x00 TTL=53 ID=21826 PROTO=TCP SPT=80 DPT=64689 WINDOW=16384 RES=0x00 ACK SYN URGP=0
Jul 2 11:15:50 li7-220 kernel: Clean-up Rule - BLOCKED: IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:84:78:ac:0d:79:c1:08:00 SRC=77.241.198.20 DST=abc.def.ghi.klm LEN=44 TOS=0x00 PREC=0x00 TTL=115 ID=30264 DF PROTO=TCP SPT=80 DPT=8713 WINDOW=8192 RES=0x00 ACK SYN URGP=0
Jul 2 11:15:53 li7-220 kernel: Clean-up Rule - BLOCKED: IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:84:78:ac:0d:79:c1:08:00 SRC=77.241.198.20 DST=abc.def.ghi.klm LEN=44 TOS=0x00 PREC=0x00 TTL=115 ID=323 DF PROTO=TCP SPT=80 DPT=8713 WINDOW=8192 RES=0x00 ACK SYN URGP=0
Jul 2 12:17:20 li7-220 kernel: Clean-up Rule - BLOCKED: IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:84:78:ac:0d:79:c1:08:00 SRC=172.245.4.168 DST=abc.def.ghi.klm LEN=44 TOS=0x00 PREC=0x00 TTL=56 ID=0 DF PROTO=TCP SPT=80 DPT=5359 WINDOW=5840 RES=0x00 ACK SYN URGP=0
Jul 2 14:37:01 li7-220 kernel: Clean-up Rule - BLOCKED: IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:84:78:ac:0d:79:c1:08:00 SRC=94.23.170.2 DST=abc.def.ghi.klm LEN=44 TOS=0x00 PREC=0x00 TTL=52 ID=36510 PROTO=TCP SPT=80 DPT=26429 WINDOW=16384 RES=0x00 ACK SYN URGP=0
Jul 2 14:39:33 li7-220 kernel: Clean-up Rule - BLOCKED: IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:84:78:ac:0d:79:c1:08:00 SRC=91.121.9.198 DST=abc.def.ghi.klm LEN=44 TOS=0x00 PREC=0x00 TTL=52 ID=43029 PROTO=TCP SPT=80 DPT=30638 WINDOW=16384 RES=0x00 ACK SYN URGP=0
Jul 2 15:02:45 li7-220 kernel: Clean-up Rule - BLOCKED: IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:84:78:ac:0d:79:c1:08:00 SRC=213.186.33.5 DST=abc.def.ghi.klm LEN=44 TOS=0x00 PREC=0x00 TTL=236 ID=35986 PROTO=TCP SPT=80 DPT=11082 WINDOW=536 RES=0x00 ACK SYN URGP=0
Jul 2 17:02:10 li7-220 kernel: Clean-up Rule - BLOCKED: IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:84:78:ac:0d:79:c1:08:00 SRC=91.105.235.7 DST=abc.def.ghi.klm LEN=44 TOS=0x00 PREC=0x00 TTL=52 ID=0 DF PROTO=TCP SPT=80 DPT=40217 WINDOW=14600 RES=0x00 ACK SYN URGP=0
Jul 2 17:02:10 li7-220 kernel: Clean-up Rule - BLOCKED: IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:84:78:ac:0d:79:c1:08:00 SRC=91.105.235.7 DST=abc.def.ghi.klm LEN=44 TOS=0x00 PREC=0x00 TTL=52 ID=0 DF PROTO=TCP SPT=80 DPT=40217 WINDOW=14600 RES=0x00 ACK SYN URGP=0
Jul 2 17:53:52 li7-220 kernel: Clean-up Rule - BLOCKED: IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:84:78:ac:0d:79:c1:08:00 SRC=142.4.208.23 DST=abc.def.ghi.klm LEN=44 TOS=0x00 PREC=0x00 TTL=56 ID=0 DF PROTO=TCP SPT=80 DPT=31415 WINDOW=14600 RES=0x00 ACK SYN URGP=0
Jul 2 18:15:55 li7-220 kernel: Clean-up Rule - BLOCKED: IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:84:78:ac:0d:79:c1:08:00 SRC=199.101.102.66 DST=abc.def.ghi.klm LEN=44 TOS=0x00 PREC=0x00 TTL=54 ID=0 DF PROTO=TCP SPT=80 DPT=23103 WINDOW=14600 RES=0x00 ACK SYN URGP=0
Almost half of the logged traffic is trying to communicate on source port 80 (of 486 log entries, 218 are source port 80). The traffic is being blocked by the firewall, and what I'm seeing is initiation attempts. This traffic isn't a huge issue, but I'm curious as to what's going on. I've commented on such traffic before, but the amount I'm seeing now is far more than what I'm used to seeing.
I think I'll capture some traffic to try to see what's going on.
EDIT: nothing much captured so far. After some sniffing and tinkering, I had to filter some IPs out - two IPs belong to my server and the other belongs to Ubuntu):
root@li7-220:~# tcpdump -XXvvnne -s 0 -r pcap.linode.src_port_80_2 | less
reading from file pcap.linode.src_port_80_2, link-type EN10MB (Ethernet)
20:56:43.532338 84:78:ac:0d:79:c1 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 112, id 3943, offset 0, flags [none], proto TCP (6), length 44)
190.220.25.34.80 > abc.def.ghi.klm 1234: Flags [S.], cksum 0x36e9 (correct), seq 2466963778, ack 1, win 16384, options [mss 1460], length 0
0x0000: fefd 403e e7dc 8478 ac0d 79c1 0800 4500 ..@>...x..y...E.
0x0010: 002c 0f67 0000 7006 93a8 bedc 1922 42a0 .,.g..p......"B.
0x0020: 8d1e 0050 04d2 930a e142 0000 0001 6012 ...P.....B....`.
0x0030: 4000 36e9 0000 0204 05b4 0000 @.6.........
UPDATE: I let a pcap capture run overnight and when I checked the process, I got 999 hits. In looking at the pcap, I saw that I'd missed a few Ubuntu server IPs that my sercer was polling (for OS updates). I filtered those out and got 22 hits:
21:29:53.200175 84:78:ac:0d:79:c1 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 53, id 0, offset 0, flags [DF], proto TCP (6), length 44)
206.188.198.69.80 > abc.def.ghi.jkl.31029: Flags [S.], cksum 0x6868 (correct), seq 2068810236, ack 320012289, win 14600, options [mss 1460], length 0
0x0000: fefd 403e e7dc 8478 ac0d 79c1 0800 4500 ..@>...x..y...E.
0x0010: 002c 0000 4000 3506 e10b cebc c645 42a0 .,..@.5......EB.
0x0020: 8d1e 0050 7935 7b4f 89fc 1313 0001 6012 ...Py5{O......`.
0x0030: 3908 6868 0000 0204 05b4 4001 9.hh......@.
23:44:52.151134 84:78:ac:0d:79:c1 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 50, id 0, offset 0, flags [DF], proto TCP (6), length 44)
109.236.85.70.80 > abc.def.ghi.jkl.15190: Flags [S.], cksum 0x0d4e (correct), seq 3480870608, ack 3571253249, win 14600, options [mss 1460], length 0
0x0000: fefd 403e e7dc 8478 ac0d 79c1 0800 4500 ..@>...x..y...E.
0x0010: 002c 0000 4000 3206 b5db 6dec 5546 42a0 .,..@.2...m.UFB.
0x0020: 8d1e 0050 3b56 cf79 ded0 d4dd 0001 6012 ...P;V.y......`.
0x0030: 3908 0d4e 0000 0204 05b4 0000 9..N........
23:59:19.278658 84:78:ac:0d:79:c1 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 57, id 3552, offset 0, flags [none], proto TCP (6), length 44)
168.61.144.13.80 > abc.def.ghi.jkl.56871: Flags [S.], cksum 0xeacd (correct), seq 280591713, ack 4171956225, win 16384, options [mss 1460], length 0
0x0000: fefd 403e e7dc 8478 ac0d 79c1 0800 4500 ..@>...x..y...E.
0x0010: 002c 0de0 0000 3906 6be3 a83d 900d 42a0 .,....9.k..=..B.
0x0020: 8d1e 0050 de27 10b9 7d61 f8ab 0001 6012 ...P.'..}a....`.
0x0030: 4000 eacd 0000 0204 05b4 0000 @...........
01:51:58.488229 84:78:ac:0d:79:c1 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 55, id 0, offset 0, flags [DF], proto TCP (6), length 44)
84.16.89.109.80 > abc.def.ghi.jkl.25420: Flags [S.], cksum 0x1559 (correct), seq 1800765718, ack 3394417182, win 14600, options [mss 1460], length 0
0x0000: fefd 403e e7dc 8478 ac0d 79c1 0800 4500 ..@>...x..y...E.
0x0010: 002c 0000 4000 3706 c690 5410 596d 42a0 .,..@.7...T.YmB.
0x0020: 8d1e 0050 634c 6b55 8116 ca52 b21e 6012 ...PcLkU...R..`.
0x0030: 3908 1559 0000 0204 05b4 0000 9..Y........
03:57:00.885857 84:78:ac:0d:79:c1 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 118, id 7812, offset 0, flags [DF], proto TCP (6), length 44)
188.138.86.58.80 > abc.def.ghi.jkl.3456: Flags [S.], cksum 0xec7d (correct), seq 689800127, ack 2517303297, win 8192, options [mss 1460], length 0
0x0000: fefd 403e e7dc 8478 ac0d 79c1 0800 4500 ..@>...x..y...E.
0x0010: 002c 1e84 4000 7606 ab68 bc8a 563a 403e .,..@.v..h..V:@>
0x0020: e7dc 0050 0d80 291d 83bf 960b 0001 6012 ...P..).......`.
0x0030: 2000 ec7d 0000 0204 05b4 0000 ...}........
07:56:45.059391 84:78:ac:0d:79:c1 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 244, id 31356, offset 0, flags [none], proto TCP (6), length 40)
164.177.186.182.80 > abc.def.ghi.jkl.24548: Flags [R.], cksum 0x2305 (correct), seq 1331337029, ack 1, win 5840, length 0
0x0000: fefd 403e e7dc 8478 ac0d 79c1 0800 4500 ..@>...x..y...E.
0x0010: 0028 7a7c 0000 f406 1d2d a4b1 bab6 42a0 .(z|.....-....B.
0x0020: 8d1e 0050 5fe4 4f5a 9745 0000 0001 5014 ...P_.OZ.E....P.
0x0030: 16d0 2305 0000 0000 0000 0000 ..#.........
08:29:11.344433 84:78:ac:0d:79:c1 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 234, id 38305, offset 0, flags [none], proto TCP (6), length 40)
222.231.1.55.80 > abc.def.ghi.jkl.1234: Flags [S.], cksum 0xd717 (correct), seq 3438077857, ack 1, win 5840, length 0
0x0000: fefd 403e e7dc 8478 ac0d 79c1 0800 4500 ..@>...x..y...E.
0x0010: 0028 95a1 0000 ea06 32f5 dee7 0137 403e .(......2....7@>
0x0020: e7dc 0050 04d2 ccec e7a1 0000 0001 5012 ...P..........P.
0x0030: 16d0 d717 0000 0000 0000 0000 ............
08:47:53.958682 84:78:ac:0d:79:c1 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 221, id 14963, offset 0, flags [none], proto TCP (6), length 40)
222.231.1.55.80 > abc.def.ghi.jkl.1234: Flags [S.], cksum 0xf320 (correct), seq 2967725985, ack 1, win 5840, length 0
0x0000: fefd 403e e7dc 8478 ac0d 79c1 0800 4500 ..@>...x..y...E.
0x0010: 0028 3a73 0000 dd06 9b23 dee7 0137 403e .(:s.....#...7@>
0x0020: e7dc 0050 04d2 b0e3 e7a1 0000 0001 5012 ...P..........P.
0x0030: 16d0 f320 0000 0000 0000 0000 ............
09:08:53.303546 84:78:ac:0d:79:c1 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 116, id 26734, offset 0, flags [none], proto TCP (6), length 48)
66.161.44.199.80 > abc.def.ghi.jkl.61773: Flags [S.], cksum 0x0776 (correct), seq 3759141565, ack 2231612163, win 16384, options [mss 1460,nop,nop,sackOK], length 0
0x0000: fefd 403e e7dc 8478 ac0d 79c1 0800 4500 ..@>...x..y...E.
0x0010: 0030 686e 0000 7406 9f33 42a1 2cc7 42a0 .0hn..t..3B.,.B.
0x0020: 8d1e 0050 f14d e00f f2bd 8503 b303 7012 ...P.M........p.
0x0030: 4000 0776 0000 0204 05b4 0101 0402 @..v..........
11:57:44.978045 84:78:ac:0d:79:c1 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 114, id 0, offset 0, flags [DF], proto TCP (6), length 40)
223.4.117.159.80 > abc.def.ghi.jkl.54404: Flags [S.], cksum 0x2882 (correct), seq 2018622826, ack 1, win 0, length 0
0x0000: fefd 403e e7dc 8478 ac0d 79c1 0800 4500 ..@>...x..y...E.
0x0010: 0028 0000 4000 7206 8c11 df04 759f 403e .(..@.r.....u.@>
0x0020: e7dc 0050 d484 7851 bd6a 0000 0001 5012 ...P..xQ.j....P.
0x0030: 0000 2882 0000 aaaa 0000 2882 ..(.......(.
11:59:10.842293 84:78:ac:0d:79:c1 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 114, id 0, offset 0, flags [DF], proto TCP (6), length 40)
223.4.117.159.80 > abc.def.ghi.jkl.41266: Flags [S.], cksum 0xa070 (correct), seq 2354167082, ack 1, win 0, length 0
0x0000: fefd 403e e7dc 8478 ac0d 79c1 0800 4500 ..@>...x..y...E.
0x0010: 0028 0000 4000 7206 e46d df04 759f 42a0 .(..@.r..m..u.B.
0x0020: 8d1e 0050 a132 8c51 bd2a 0000 0001 5012 ...P.2.Q.*....P.
0x0030: 0000 a070 0000 aaaa 0000 a070 ...p.......p
12:02:08.880498 84:78:ac:0d:79:c1 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 60: (tos 0x2,ECT(0), ttl 114, id 0, offset 0, flags [DF], proto TCP (6), length 40)
223.4.117.159.80 > abc.def.ghi.jkl.54404: Flags [S.], cksum 0x28c2 (correct), seq 2018622762, ack 1, win 0, length 0
0x0000: fefd 403e e7dc 8478 ac0d 79c1 0800 4502 ..@>...x..y...E.
0x0010: 0028 0000 4000 7206 8c0f df04 759f 403e .(..@.r.....u.@>
0x0020: e7dc 0050 d484 7851 bd2a 0000 0001 5012 ...P..xQ.*....P.
0x0030: 0000 28c2 0000 aaaa 0000 28c2 ..(.......(.
12:53:54.286082 84:78:ac:0d:79:c1 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 114, id 0, offset 0, flags [DF], proto TCP (6), length 40)
223.4.117.159.80 > abc.def.ghi.jkl.54404: Flags [S.], cksum 0x2594 (correct), seq 2067774826, ack 1, win 0, length 0
0x0000: fefd 403e e7dc 8478 ac0d 79c1 0800 4500 ..@>...x..y...E.
0x0010: 0028 0000 4000 7206 8c11 df04 759f 403e .(..@.r.....u.@>
0x0020: e7dc 0050 d484 7b3f bd6a 0000 0001 5012 ...P..{?.j....P.
0x0030: 0000 2594 0000 aaaa 0000 2594 ..%.......%.
12:55:19.762030 84:78:ac:0d:79:c1 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 114, id 0, offset 0, flags [DF], proto TCP (6), length 40)
223.4.117.159.80 > abc.def.ghi.jkl.41266: Flags [S.], cksum 0x5cec (correct), seq 3486891306, ack 1, win 0, length 0
0x0000: fefd 403e e7dc 8478 ac0d 79c1 0800 4500 ..@>...x..y...E.
0x0010: 0028 0000 4000 7206 e46d df04 759f 42a0 .(..@.r..m..u.B.
0x0020: 8d1e 0050 a132 cfd5 bd2a 0000 0001 5012 ...P.2...*....P.
0x0030: 0000 5cec 0000 aaaa 0000 5cec ..\.......\.
13:00:54.393330 84:78:ac:0d:79:c1 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 114, id 0, offset 0, flags [DF], proto TCP (6), length 40)
223.4.117.159.80 > abc.def.ghi.jkl.54404: Flags [S.], cksum 0xa4fd (correct), seq 4225088874, ack 1, win 0, length 0
0x0000: fefd 403e e7dc 8478 ac0d 79c1 0800 4500 ..@>...x..y...E.
0x0010: 0028 0000 4000 7206 8c11 df04 759f 403e .(..@.r.....u.@>
0x0020: e7dc 0050 d484 fbd5 bd6a 0000 0001 5012 ...P.....j....P.
0x0030: 0000 a4fd 0000 aaaa 0000 a4fd ............
13:05:42.419546 84:78:ac:0d:79:c1 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 240, id 18537, offset 0, flags [none], proto TCP (6), length 40)
195.244.222.208.80 > abc.def.ghi.jkl.3409: Flags [S.], cksum 0xa210 (correct), seq 302051360, ack 857669633, win 0, length 0
0x0000: fefd 403e e7dc 8478 ac0d 79c1 0800 4500 ..@>...x..y...E.
0x0010: 0028 4869 0000 f006 b786 c3f4 ded0 403e .(Hi..........@>
0x0020: e7dc 0050 0d51 1200 f020 331f 0001 5012 ...P.Q....3...P.
0x0030: 0000 a210 0000 0000 0000 0000 ............
13:16:03.791551 84:78:ac:0d:79:c1 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 52, id 16141, offset 0, flags [none], proto TCP (6), length 44)
94.23.225.114.80 > abc.def.ghi.jkl.24664: Flags [S.], cksum 0x369d (correct), seq 323364370, ack 533921793, win 16384, options [mss 1460], length 0
0x0000: fefd 403e e7dc 8478 ac0d 79c1 0800 4500 ..@>...x..y...E.
0x0010: 002c 3f0d 0000 3406 e01a 5e17 e172 403e .,?...4...^..r@>
0x0020: e7dc 0050 6058 1346 2612 1fd3 0001 6012 ...P`X.F&.....`.
0x0030: 4000 369d 0000 0204 05b4 2626 @.6.......&&
13:26:19.398167 84:78:ac:0d:79:c1 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 116, id 33033, offset 0, flags [none], proto TCP (6), length 40)
121.10.105.5.80 > abc.def.ghi.jkl.1234: Flags [.], cksum 0x1c3f (correct), seq 2951871426, ack 788062144, win 8760, length 0
0x0000: fefd 403e e7dc 8478 ac0d 79c1 0800 4500 ..@>...x..y...E.
0x0010: 0028 8109 0000 7406 13f9 790a 6905 42a0 .(....t...y.i.B.
0x0020: 8d1e 0050 04d2 aff1 fbc2 2ef8 dfc0 5010 ...P..........P.
0x0030: 2238 1c3f 0000 aaaa 2238 1c3f "8.?...."8.?
13:35:52.715311 84:78:ac:0d:79:c1 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 114, id 0, offset 0, flags [DF], proto TCP (6), length 40)
223.4.117.159.80 > abc.def.ghi.jkl.54404: Flags [S.], cksum 0xa2a5 (correct), seq 4264410474, ack 1, win 0, length 0
0x0000: fefd 403e e7dc 8478 ac0d 79c1 0800 4500 ..@>...x..y...E.
0x0010: 0028 0000 4000 7206 8c11 df04 759f 403e .(..@.r.....u.@>
0x0020: e7dc 0050 d484 fe2d bd6a 0000 0001 5012 ...P...-.j....P.
0x0030: 0000 a2a5 0000 aaaa 0000 a2a5 ............
13:37:20.082116 84:78:ac:0d:79:c1 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 114, id 0, offset 0, flags [DF], proto TCP (6), length 40)
223.4.117.159.80 > abc.def.ghi.jkl.41266: Flags [S.], cksum 0x2295 (correct), seq 170769706, ack 1, win 0, length 0
0x0000: fefd 403e e7dc 8478 ac0d 79c1 0800 4500 ..@>...x..y...E.
0x0010: 0028 0000 4000 7206 e46d df04 759f 42a0 .(..@.r..m..u.B.
0x0020: 8d1e 0050 a132 0a2d bd2a 0000 0001 5012 ...P.2.-.*....P.
0x0030: 0000 2295 0000 aaaa 0000 2295 ..".......".
14:03:05.415420 84:78:ac:0d:79:c1 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 55, id 9949, offset 0, flags [none], proto TCP (6), length 44)
69.20.56.19.80 > abc.def.ghi.jkl.48972: Flags [S.], cksum 0x1c7d (correct), seq 1191661700, ack 1191661700, win 16384, options [mss 1460], length 0
0x0000: fefd 403e e7dc 8478 ac0d 79c1 0800 4500 ..@>...x..y...E.
0x0010: 002c 26dd 0000 3706 100a 4514 3813 42a0 .,&...7...E.8.B.
0x0020: 8d1e 0050 bf4c 4707 5084 4707 5084 6012 ...P.LG.P.G.P.`.
0x0030: 4000 1c7d 0000 0204 05b4 0000 @..}........
14:35:45.494119 84:78:ac:0d:79:c1 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 232, id 40546, offset 0, flags [none], proto TCP (6), length 40)
222.231.1.199.80 > abc.def.ghi.jkl.1234: Flags [S.], cksum 0xaea0 (correct), seq 1770244942, ack 1, win 5840, length 0
0x0000: fefd 403e e7dc 8478 ac0d 79c1 0800 4500 ..@>...x..y...E.
0x0010: 0028 9e62 0000 e806 8400 dee7 01c7 42a0 .(.b..........B.
0x0020: 8d1e 0050 04d2 6983 cb4e 0000 0001 5012 ...P..i..N....P.
0x0030: 16d0 aea0 0000 0000 0000 0000 ............
Each are SYN packets...the firewall is blocking any further activity (at the catch-all/deny-all rule).
I did notice a pattern, though:
root@li7-220:~# cat test3.txt | grep "1234"
222.231.1.55.80 > abc.def.ghi.jkl.1234: Flags [S.], cksum 0xd717 (correct), seq 3438077857, ack 1, win 5840, length 0
222.231.1.55.80 > abc.def.ghi.jkl.1234: Flags [S.], cksum 0xf320 (correct), seq 2967725985, ack 1, win 5840, length 0
121.10.105.5.80 > abc.def.ghi.jkl.1234: Flags [.], cksum 0x1c3f (correct), seq 2951871426, ack 788062144, win 8760, length 0
222.231.1.199.80 > abc.def.ghi.jkl.1234: Flags [S.], cksum 0xaea0 (correct), seq 1770244942, ack 1, win 5840, length 0
root@li7-220:~# cat test3.txt | grep "41266"
223.4.117.159.80 > abc.def.ghi.jkl.41266: Flags [S.], cksum 0xa070 (correct), seq 2354167082, ack 1, win 0, length 0
223.4.117.159.80 > abc.def.ghi.jkl.41266: Flags [S.], cksum 0x5cec (correct), seq 3486891306, ack 1, win 0, length 0
223.4.117.159.80 > abc.def.ghi.jkl.41266: Flags [S.], cksum 0x2295 (correct), seq 170769706, ack 1, win 0, length 0
root@li7-220:~# cat test3.txt | grep "54404"
223.4.117.159.80 > abc.def.ghi.jkl.54404: Flags [S.], cksum 0x2882 (correct), seq 2018622826, ack 1, win 0, length 0
223.4.117.159.80 > abc.def.ghi.jkl.54404: Flags [S.], cksum 0x28c2 (correct), seq 2018622762, ack 1, win 0, length 0
223.4.117.159.80 > abc.def.ghi.jkl.54404: Flags [S.], cksum 0x2594 (correct), seq 2067774826, ack 1, win 0, length 0
223.4.117.159.80 > abc.def.ghi.jkl.54404: Flags [S.], cksum 0xa4fd (correct), seq 4225088874, ack 1, win 0, length 0
223.4.117.159.80 > abc.def.ghi.jkl.54404: Flags [S.], cksum 0xa2a5 (correct), seq 4264410474, ack 1, win 0, length 0
As well, in the below instances, the source host is the same. The packets are maybe 2 min apart (this is a sequential set of packets). The destination ports are different:
13:35:52.715311 84:78:ac:0d:79:c1 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 114, id 0, offset 0, flags [DF], proto TCP (6), length 40)
223.4.117.159.80 > abc.def.ghi.jkl.54404: Flags [S.], cksum 0xa2a5 (correct), seq 4264410474, ack 1, win 0, length 0
0x0000: fefd 403e e7dc 8478 ac0d 79c1 0800 4500 ..@>...x..y...E.
0x0010: 0028 0000 4000 7206 8c11 df04 759f 403e .(..@.r.....u.@>
0x0020: e7dc 0050 d484 fe2d bd6a 0000 0001 5012 ...P...-.j....P.
0x0030: 0000 a2a5 0000 aaaa 0000 a2a5 ............
13:37:20.082116 84:78:ac:0d:79:c1 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 114, id 0, offset 0, flags [DF], proto TCP (6), length 40)
223.4.117.159.80 > abc.def.ghi.jkl.41266: Flags [S.], cksum 0x2295 (correct), seq 170769706, ack 1, win 0, length 0
0x0000: fefd 403e e7dc 8478 ac0d 79c1 0800 4500 ..@>...x..y...E.
0x0010: 0028 0000 4000 7206 e46d df04 759f 42a0 .(..@.r..m..u.B.
0x0020: 8d1e 0050 a132 0a2d bd2a 0000 0001 5012 ...P.2.-.*....P.
0x0030: 0000 2295 0000 aaaa 0000 2295 ..".......".
Someone is scanning my server and purposely using source port 80 when attempting deliberate (and distributed) scans. If I had the balls to run a honeypot, I could probably gain a better understanding of what type of scans are being conducted.
Wednesday, April 17, 2013
ACLU files complaint with FTC over older Android software
ACLU files complaint with FTC over older Android software
http://tinyurl.com/cqj67ds
The ACLU has a point. As a person who has been an Android user the last 2+ years, I believe I've seen *maybe* 3 (more than likely 2) OS updates on my Thunderbolt (and NONE for my SGN2, so far). One was to disable free hotspots. I find it hard to believe that there were little to no Android updates in that time span (especially security-related updates). Verizon is my carrier and I hold them responsible. Yes, they pushed out ICS to my thunderbolt right before it went out-of-contract, but that push actually made the phone run worse, and I was forced into the update (I wasn't asked)...being forced into an untested update broke my phone.
The carriers need to do a better job of handling updates. They also need to ensure they're periodically pushing security updates, because Android's security posture is horrendous. Google sells its own devices and pushes updates to them without issue, but the carriers never act in a timely fashion when Google pushes those updates to them...it's like they vanish into a black hole. :/
http://tinyurl.com/cqj67ds
The American Civil Liberties Union filed a federal complaint Tuesday accusing the nation’s largest wireless carriers of “deceptive” business practices for failing to keep the software on tens of millions of Android smartphones updated — a shortcoming that can make the devices vulnerable to hackers.
The ACLU has a point. As a person who has been an Android user the last 2+ years, I believe I've seen *maybe* 3 (more than likely 2) OS updates on my Thunderbolt (and NONE for my SGN2, so far). One was to disable free hotspots. I find it hard to believe that there were little to no Android updates in that time span (especially security-related updates). Verizon is my carrier and I hold them responsible. Yes, they pushed out ICS to my thunderbolt right before it went out-of-contract, but that push actually made the phone run worse, and I was forced into the update (I wasn't asked)...being forced into an untested update broke my phone.
The carriers need to do a better job of handling updates. They also need to ensure they're periodically pushing security updates, because Android's security posture is horrendous. Google sells its own devices and pushes updates to them without issue, but the carriers never act in a timely fashion when Google pushes those updates to them...it's like they vanish into a black hole. :/
Monday, March 21, 2011
GUIs for Snort
GUIs for Snort --
http://blog.snort.org/2011/01/guis-for-snort.html
Some of these might appeal to you, the network/security administrator, depending on your organization's needs. Note: there is NO best in breed tool...it totally depends on your organization's needs, which will vary when comparing org X to org Y.
http://blog.snort.org/2011/01/guis-for-snort.html
Some of these might appeal to you, the network/security administrator, depending on your organization's needs. Note: there is NO best in breed tool...it totally depends on your organization's needs, which will vary when comparing org X to org Y.
Tuesday, August 24, 2010
Wednesday, March 03, 2010
I passed my Security+ certification Exam!
I passed my Security+ exam! This certification is needed for a work client (a requirement to access their systems). This is a big deal to me, as I'd been studying awhile for it and the deadline for completion was next week.
I don't believe in certifications (I feel strongly that they aren't needed), but this is a first for me.
I'm so glad it is over! Now its reimbursement time! :)
Saturday, June 06, 2009
Researching and found an old flamefest spark
Reference:
http://mythtv.beirdo.ca/ircLog/channel/1/2008-07-14
Summary: At LQ.org, there was a discussion on the security forums on how vulnerable Linux was to attacks/malware. Someone didn't like what was being discussed because of typical Linux zealotry. What happened on LQ's forums spilled over into ##slackware on IRC. Dagmar, the instigator of a LOT of bad things that used to happen in ##slackware got perm banned by me. Later, documented in the link above, he is his typical self, not even attempting to objectively explain what the whole thing was about, pretty much slandering me about how flawed my thoughts are on the whole thing and is worrying that I'll propagate bad information.
Let me explain some things about myself. I'm an IT security engineer. I don't just mess with routers and I'm not some glorified network engineer. I'm a senior consultant. I not only consult, I'm able to find "needle-in-the-haystack"-type info using packet-level analysis. Most of what I do requires that I be a jack-of-all-trades in network engineering, but my specialty is security. I'm proficient in utilizing many industry-leading security tools, both freeware and commercial software. I work at a very large ISP/telecom within a large managed security services team. I am THE lead of a government security operations center. We manage well over 100 customers' security posture via firewalls, NIDS, HIDS, and IPS appliances, using ArcSight, an aggregation and correlation tool that is fast becoming the standard in security event monitoring.
Every day, we see machines being compromised...this is nothing new. The compromises span every mainstream OS. This includes Linux. Whether it is kernel level or application level is not the argument. The argument is that Linux is not as rock-solid as everyone makes it out to be. Sure, it has more safeguards than Windows-based systems, but it is still susceptible to application-level exploits. Whether this is a coder issue or PEBKAC/user/admin issue is besides the point.
People need to stop thinking that just because they are running Linux, they are safe. That is NOT the case. This is not paranoia speaking. It is from seeing such things happen on a daily basis during security event monitoring. Due to applications such as PHP-Nuke, it is becoming more difficult to secure back end applications. It is much harder to stop SQL injection than it is to stop SSH brute-forcing, for instance. This isn't the only issue, though. The issue is the perception that because Linux code is open and free, the code base is free of vulnerabilities. That is NOT the case. Also, many people think that a majority of the cracker focus is on Win32 because MS has a majority of the market share. That also is NOT the case. That is a big assumption. milw0rm and other such sites document many *nix-based vulnerabilities, along with Bugtraq at Securityfocus track all vulnerabilities. Sometimes, people justify Linux because its security model is better focused than Win32 systems. It is, but that does not mean that Linux is rock-solid. It has its own faults, whether it is the user, the admin, or the software developer (or even kernel developer).
Dagmar has a habit of blocking out people's opinions and sometimes beating people down with his own. Dagmar thinks he knows security more than anyone else when he's just a developer. I see attacks every day on all types of machines. Some of the attacks are successful. I doubt that Dagmar sees those. Dagmar need not worry about me "propagating" untruth, because what I say IS the truth. All you have to do to see the truth is to research and not be blind to other opinions.
Dagmar also stalked. After the IRC discussion, he began to frequent the LQ security forums and respond to every thread I posted to. He was hardly ever in those forums before then. I noticed this immediately (and also checked). I didn't mind this, but when it spilled back over into IRC, I tired of it and wanted it ended...it really had no place in ##slackware and I was fed up with his attitude about the whole thing. I don't suffer drama very well.
Now, Dagmar has been banned several times before for the lack of tact in the way he 'helped' people in ##slackware. He was walking a thin line to begin with. Those with operator status in ##slackware acknowledge that he is knowledgeable, but that is not grounds for him to be dismissed as an abusive ##slackware visitor. Sure enough, he did the same thing with a channel operator (me) and I banned him. I also discussed it with the other operators. The consensus was that he stay banned since his history of being banned was substantial.
That was why he got banned...not because his views went against my own, but because he started regressing back to his former self and became abusive. He did the same in the LQ.org forums, but I was able to filter his posts from my normal views. As an operator at Freenode.net, I can't and shouldn't filter any visitor from my views in ##slackware, so my only option was to ban him, and like I said before, he'd his own infamous nature that was going against him.
As a security consultant, I'm certainly not going to keep my thoughts quiet about what I think is a disservice to my favorite operating system. I certainly know more than someone who is not a security consultant about IT security...its what I get paid to do and its what I've been doing for years. It's the same as a person who has built his own car, vs. someone who works as a senior Mercedes mechanic.
As much as I can, I tell people that there is NO secure OS. It is only as secure as the admin makes it, and even if the admin puts 100% resources into hardening the box, it will never be 100% secure. The LQ security forums is itself proof that Linux systems get compromised more than most people think. 2-3 times a week, someone reports they've been compromised. There's even 4 threads on Linux-based vulnerabilities:
Kernel Vulns
Mozilla Firefox Vulns
The Problem with PHP Application Security
Failed SSH Login Attempts
I can post a ton of other links but why do this when there is Google?
http://mythtv.beirdo.ca/ircLog/channel/1/2008-07-14
Summary: At LQ.org, there was a discussion on the security forums on how vulnerable Linux was to attacks/malware. Someone didn't like what was being discussed because of typical Linux zealotry. What happened on LQ's forums spilled over into ##slackware on IRC. Dagmar, the instigator of a LOT of bad things that used to happen in ##slackware got perm banned by me. Later, documented in the link above, he is his typical self, not even attempting to objectively explain what the whole thing was about, pretty much slandering me about how flawed my thoughts are on the whole thing and is worrying that I'll propagate bad information.
Let me explain some things about myself. I'm an IT security engineer. I don't just mess with routers and I'm not some glorified network engineer. I'm a senior consultant. I not only consult, I'm able to find "needle-in-the-haystack"-type info using packet-level analysis. Most of what I do requires that I be a jack-of-all-trades in network engineering, but my specialty is security. I'm proficient in utilizing many industry-leading security tools, both freeware and commercial software. I work at a very large ISP/telecom within a large managed security services team. I am THE lead of a government security operations center. We manage well over 100 customers' security posture via firewalls, NIDS, HIDS, and IPS appliances, using ArcSight, an aggregation and correlation tool that is fast becoming the standard in security event monitoring.
Every day, we see machines being compromised...this is nothing new. The compromises span every mainstream OS. This includes Linux. Whether it is kernel level or application level is not the argument. The argument is that Linux is not as rock-solid as everyone makes it out to be. Sure, it has more safeguards than Windows-based systems, but it is still susceptible to application-level exploits. Whether this is a coder issue or PEBKAC/user/admin issue is besides the point.
People need to stop thinking that just because they are running Linux, they are safe. That is NOT the case. This is not paranoia speaking. It is from seeing such things happen on a daily basis during security event monitoring. Due to applications such as PHP-Nuke, it is becoming more difficult to secure back end applications. It is much harder to stop SQL injection than it is to stop SSH brute-forcing, for instance. This isn't the only issue, though. The issue is the perception that because Linux code is open and free, the code base is free of vulnerabilities. That is NOT the case. Also, many people think that a majority of the cracker focus is on Win32 because MS has a majority of the market share. That also is NOT the case. That is a big assumption. milw0rm and other such sites document many *nix-based vulnerabilities, along with Bugtraq at Securityfocus track all vulnerabilities. Sometimes, people justify Linux because its security model is better focused than Win32 systems. It is, but that does not mean that Linux is rock-solid. It has its own faults, whether it is the user, the admin, or the software developer (or even kernel developer).
Dagmar has a habit of blocking out people's opinions and sometimes beating people down with his own. Dagmar thinks he knows security more than anyone else when he's just a developer. I see attacks every day on all types of machines. Some of the attacks are successful. I doubt that Dagmar sees those. Dagmar need not worry about me "propagating" untruth, because what I say IS the truth. All you have to do to see the truth is to research and not be blind to other opinions.
Dagmar also stalked. After the IRC discussion, he began to frequent the LQ security forums and respond to every thread I posted to. He was hardly ever in those forums before then. I noticed this immediately (and also checked). I didn't mind this, but when it spilled back over into IRC, I tired of it and wanted it ended...it really had no place in ##slackware and I was fed up with his attitude about the whole thing. I don't suffer drama very well.
Now, Dagmar has been banned several times before for the lack of tact in the way he 'helped' people in ##slackware. He was walking a thin line to begin with. Those with operator status in ##slackware acknowledge that he is knowledgeable, but that is not grounds for him to be dismissed as an abusive ##slackware visitor. Sure enough, he did the same thing with a channel operator (me) and I banned him. I also discussed it with the other operators. The consensus was that he stay banned since his history of being banned was substantial.
That was why he got banned...not because his views went against my own, but because he started regressing back to his former self and became abusive. He did the same in the LQ.org forums, but I was able to filter his posts from my normal views. As an operator at Freenode.net, I can't and shouldn't filter any visitor from my views in ##slackware, so my only option was to ban him, and like I said before, he'd his own infamous nature that was going against him.
As a security consultant, I'm certainly not going to keep my thoughts quiet about what I think is a disservice to my favorite operating system. I certainly know more than someone who is not a security consultant about IT security...its what I get paid to do and its what I've been doing for years. It's the same as a person who has built his own car, vs. someone who works as a senior Mercedes mechanic.
As much as I can, I tell people that there is NO secure OS. It is only as secure as the admin makes it, and even if the admin puts 100% resources into hardening the box, it will never be 100% secure. The LQ security forums is itself proof that Linux systems get compromised more than most people think. 2-3 times a week, someone reports they've been compromised. There's even 4 threads on Linux-based vulnerabilities:
Kernel Vulns
Mozilla Firefox Vulns
The Problem with PHP Application Security
Failed SSH Login Attempts
I can post a ton of other links but why do this when there is Google?
Subscribe to:
Posts (Atom)